如果你熟悉 Java 的 23 种设计模式，看到“Reactor 模式”可能就会一脸懵逼，这是什么鬼。Reactor 是一种应用在服务器端的开发模式（也有说法称 Reactor 是一种 IO 模式），目的是提高服务端程序的并发能力。

Reactor 模式

它要解决什么问题呢？传统的 thread per connection 用法中，线程在真正处理请求之前首先需要从 socket 中读取网络请求，而在读取完成之前，线程本身被阻塞，不能做任何事，这就导致线程资源被占用，而线程资源本身是很珍贵的，尤其是在处理高并发请求时。

而 Reactor 模式指出，在等待 IO 时，线程可以先退出，这样就不会因为有线程在等待 IO 而占用资源。但是这样原先的执行流程就没法还原了，因此，我们可以利用事件驱动的方式，要求线程在退出之前向 event loop 注册回调函数，这样 IO 完成时 event loop 就可以调用回调函数完成剩余的操作。

所以说，Reactor 模式通过减少服务器的资源消耗，提高了并发的能力。当然，从实现角度上，事件驱动编程会更难写，难 debug 一些。

餐厅里的 Reactor 模式

我们用“餐厅”类比的话，就像下图：

对于每个新来的顾客，前台都需要找到一个服务员和厨师来服务这个顾客。

  1. 服务员给出菜单，并等待点菜
  2. 顾客查看菜单，并点菜
  3. 服务员把菜单交给厨师，厨师照着做菜
  4. 厨师做好菜后端到餐桌上

这就是传统的多线程服务器。每个顾客都有自己的服务团队（线程），在人少的情况下是可以良好的运作的。现在餐厅的口碑好，顾客人数不断增加，这时服务员就有点处理不过来了。

这时老板发现，每个服务员在服务完客人后，都要去休息一下，因此老板就说，“你们都别休息了，在旁边待命”。这样可能 10 个服务员也来得及服务 20 个顾客了。这也是“线程池”的方式，通过重用线程来减少线程的创建和销毁时间，从而提高性能。

但是客人又进一步增加了，仅仅靠剥削服务员的休息时间也没有办法服务这么多客人。老板仔细观察，发现其实服务员并不是一直在干活的，大部分时间他们只是站在餐桌旁边等客人点菜。

于是老板就对服务员说，客人点菜的时候你们就别傻站着了，先去服务其它客人，有客人点好的时候喊你们再过去。对应于下图：

最后，老板发现根本不需要那么多的服务员，于是裁了一波员，最终甚至可以只有一个服务员。

这就是 Reactor 模式的核心思想：减少等待。当遇到需要等待 IO 时，先释放资源，而在 IO 完成时，再通过事件驱动 (event driven) 的方式，继续接下来的处理。从整体上减少了资源的消耗。

参考