既然Reactor反应器和Handler处理器，挤在-一个线程会造成非常严重的性能缺陷。那么，可以使用多线程，对基础的反应器模式进行改造和演进。

多线程池Reactor反应器演进

多线程池Reactor反应器的演进，分为两个方面:

(1)首先是升级Handler处理器。既要使用多线程，又要尽可能的高效率，则可以考虑使用线程池。

(2)其次是升级Reactor反应器。可以考虑引入多个Selector选择器，提升选择大量通道的能力。

总体来说，多线程池反应器的模式，大致如下:

(1)将负责输入输出处理的IOHandler处理器的执行，放入独立的线程池中。这样，业务处理线程与负责服务监听和IO事件查询的反应器线程相隔离，避免服务器的连接监听受到阻塞。

(2)如果服务器为多核的CPU，可以将反应器线程拆分为多个子反应器(SubReactor)线程;同时，引入多个选择器，每一个SubReactor 子线程负责-一个选择器。这样，充分释放了系统资源的能力;也提高了反应器管理大量连接，提升选择大量通道的能力。

多线程Reactor反应器的实践案例

在前面的“回显服务器”(EchoServer)的基础上，完成多线程Reactor反应器的升级。多线程反应器的实践案例设计如下:

(1)引入多个选择器。

(2)设计一个新的子反应器( SubReactor)类，一个子反应器负责查询一个选.择器。

(3)开启多个反应器的处理线程，一个线程负责执行一个子反应器( SubReactor)。

为了提升效率，建议SubReactor的数量和选择器的数量一致。避免多个线程负责一个选择器，导致需要进行线程同步，引起的效率降低。这个实践案例的代码如下:

多线程Handler处理器的实践案例

基于前面的单线程反应器的EchoHandler回显处理器的程序代码，予以改进，新的回显处理器为: MultiThreadEchoHandler。 主要的升级是引入了一个线程池(ThreadPool)，业务处理的代码执行在自己的线程池中，彻底地做到业务处理线程和反应器IO事件线程的完全隔离。这个实践案例的代码如下:

代码中设计了一个内部类AsyncTask,是-一个简单的异步任务的提交类。它使得异步业务asyncRun方法，可以独立地提交到线程池中。另外，既然业务处理异步执行，需要在asyncRun方法的前面加.上synchronized同步修饰符。

至此，多线程版本的反应器模式，实践案例的代码就演示完了。执行新版本的多线程MultiThreadEchoServerReactor服务器，可以使用之前的EchoClient客户端与之配置，完成整个回显(echo) 的通信演示。

演示的输出和之前单线程版本的EchoServer回显服务器示例，是一模一样的。

Reactor反应器模式小结

在总结反应器模式前，首先看看和其他模式的对比，加强- - 下对它的理解。

1.反应器模式和生产者消费者模式对比相似之处:在一定程度上，反应器模式有点类似生产者消费者模式。在生产者消费者模式中，一个或多个生产者将事件加入到一个队列中，一个或多个消费者主动地从这个队列中提取(Pull) 事件来处理。

不同之处在于:反应器模式是基于查询的，没有专门的队列去缓冲存储IO事件，查询到IO事件之后，反应器会根据不同I0选择键(事件)将其分发给对应的Handler处理器来处理。

2.反应器模式和观察者模式(Observer Pattern)对比

相似之处在于:在反应器模式中，当查询到IO事件后，服务处理程序使用单路/多路分发(Dispatch) 策略，同步地分发这些I0事件。观察者模式(ObserverPattern)也被称作发布/订阅模式，它定义了一种依赖关系，让多个观察者同时监听某一个主题(Topic) 。这个主题对象在状态发生变化时，会通知所有观察者，他们能够执行相应的处理。

不同之处在于:在反应器模式中，Handler处理 器实例和IO事件(选择键)的订阅关系，基本上是一个事件绑定到一个Handler处理器;每-一个I0事件 (选择键)被查询后，反应器会将事件分发给所绑定的Handler处理器;而在观察者模式中，同一个时刻，同一个主题可以被订阅过的多个观察者处理。

最后，总结一下反应器模式的优点和缺点。作为高性能的IO模式，反应器模式的优点如下:

响应快，虽然同一反应器线程本身是同步的，但不会被单个连接的同步I0所阻.塞;编程相对简单， 最大程度避免了复杂的多线程同步，也避免了多线程的各个进程之间切换的开销;可扩展，可以方便地通过增加反应器线程的个数来充分利用CPU资源。反应器模式的缺点如下:

反应器模式增加了一定的复杂性，因而有一定的门槛，并且不易于调试。

反应器模式需要操作系统底层的I0多路复用的支持，如Linux中 的epoll。如果操作系统的底层不支持I0多路复用，反应器模式不会有那么高效。

同一个Handler业务线程中，如果出现一个长时间的数据读写，会影响这个反应器中其他通道的IO处理。例如在大文件传输时，IO操作就会影响其他客户端(Client)的响应时间。因而对于这种操作，还需要进一步对 反应器模式进行改进。