书接上篇：
既然Reactor反应器和Handler处理器，挤在一个线程中会造成非常严重的性能缺陷。那么，可以使用多线程，对基础的反应器模式进行改造和演进。
多线程池Reactor 反应器演进
多线程池Reactor反应器的演进，分为两个方面：
（1）首先是升级Handler处理器。即要使用多线程，又要尽可能的高效率，则可以考虑使用线程池。
（2）其次是升级Reactor反应器。可以考虑引入多个Selector选择器，提升选择大量通道的能力。
总体来说，多线程池反应器的模式，大致如下：
（1）将负责输入输出处理的IOHandler处理器的执行，放入独立的线程池中。这样，业务处理线程与负责监听的和IO事件查询的反应器线程相隔离，避免服务器的链接监听收到阻塞。
（2）如果服务器为多核的CPU，可以将反应器线程拆分为多个子反应器（SubReactor）线程同时，引入多个选择器，每一个SubReactor子线程负责一个选择器。这样，充分释放了系统资源的能力；也提高了反应器管理大量链接，提升选择大量通道的能力。
总结：
1.反应器模式和生产者消费者模式对比
相似之处：在一定程度上，反应器模式有点类似生产者消费者模式。在生产者消费者模式中，一个或多个生产者将事件加入到一个队列中，一个或者多个消费者主动从这个队列中提取（Pull）事件来处理。
不同之处在于：反应器模式是基于查询的，没有专门的队列去缓冲存储IO事件，查询到IO事件后，反应器会根据不同IO选择键（事件）将其分发给对应的Handler处理器来处理。
2.反应器模式和观察者模式对比
相似之处在于：在反应器模式中，当查询到IO事件后，服务处理程序使用单路/多路分发（Dispatch）策略，同步的分发这些IO事件。观察者模式（Observ Pattern）也被称作发布/订阅模式，它定义了一种依赖关系，让多个观察者同时监听某一个主体（Topic）.这个主体对象在状态发生变化时，会通知所有观察者，他们能够执行相应的处理。
不同之处在于：在反应器模式中，Handler处理器实例和IO事件（选择键）的订阅关系，基本上是一个是事件绑定到一个Handler处理器；每个IO事件（选择键）被查询后，反应器会将事件分发给所绑定的Handler处理器；在观察者模式中，同一个时刻，同一个主体可以被订阅过的多个观察者处理。
最后，总结一下反应器模式的优点和缺点。作为高性能的IO模式，反应器模式的优点如下：
1.响应快，虽然同一反应器线程本身是同步的，但不为被单个链接的同步IO所阻塞。
2.编程相对简单，最大程度上避免了复杂的多线程同步，也避免了多线程的各个进程之间的切换开销。
3.可扩展，可以方便的通过增加反应器线程的个数来充分利用CPU
最主要的可以参考：
http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf
学习知识最好的办法是看最早的论文。并发编程大师的论文简单易懂
反应器模式的缺点：
1.反应器模式增加了一定的复杂性，因而有一定的门槛，并且不易于调试。
2.反应器模式需要操作系统底层的IO多路复用的支持，如Linux中的epolll如果操作系统的底层不支持IO多路复用，反应器模式就不会有那么高效了。
3.同一个Handler业务线程中，如果出现一个长时间的数据读写，会影响整个反应器中的其他通道的IO处理。例如在大文件传输时，IO操作就会影响到其他客户端（Client）的响应时间。因为对于这种操作，还需要进一步对反应器模式进行改进。