介绍一下 Reactor 线程模型？

回答重点

Reactor 是服务端在网络编程时的一个编程模式，主要由一个基于 Selector （底层是 select/poll/epoll）的死循环线程，也称为 Reactor 线程。

基于事件驱动，将 I/O 操作抽象成不同的事件，每个事件都配置对应的回调函数，由 Selector 监听连接上事件的发生，再进行分发调用相应的回调函数进行事件的处理。

Reactor 线程模型分为三种，分别为单 Reactor 单线程模型、单 Reactor 多线程模型、主从 Reactor 多线程模型。

1）单 Reactor 单线程模型：所有的操作都是由一个 I/O 线程处理。

• 优点：对系统资源消耗较少。
• 缺点：没办法支持高并发场景。

2）单 Reactor 多线程模型：一个线程负责接收建连事件和后续的连接 I/O 处理（read、send等），线程池处理具体业务逻辑。

• 优点：可以很好地应对大部分的场景 ，也提高了事件的处理效率。
• 缺点：并发量大的时候，一个线程可能没办法接收所有的事件请求，可能导致性能瓶颈。

3）主从 Reactor 多线程模型：主 Reactor 线程负责接收建连事件，从 Reactor 线程负责处理建连后的后续连接 I/O 处理（read、send等），线程池处理具体业务逻辑。

• 优点：解决海量并发请求。
• 缺点：相对而言，实现复杂度较高，对系统资源的管理要求会高一点。

扩展知识

理解 Reactor

Reactor 它算是一个编程模式或者说一个架构模式，常用在服务端网络通信相关的模块。

Reactor 直译到中文是反应堆，虽然直译不贴切，但确实跟“反应”有关。

反应什么呢？对触发的事件进行反应。

在大学的时候，我相信很多人都做过图书管理系统等类似的大作业，这种都是基于 Java GUI 做的，当然具体如何实现的不重要，重要的是你完成之后的成品是不是点击一个按钮就会弹出一个对应的弹框？

点击按钮就会弹框，不同的按钮弹不同的框，这就是反应。

咱们计算机不就讲究抽象嘛，所以把这上面说的这些抽象一下，就是针对不同的事件需要有不同的处理逻辑（方法调用）。

到这，我们得到了两个概念：事件（点击按钮）和处理逻辑（弹对应的框）。

再回到弹框这个场景，思考下，到底是谁在监听着按钮被点击的动作来弹出不同的框呢？

这里，我们很容易想到两种情况：

1. 一个按钮派一个线程在守着，只要按钮被点击了，这个线程就执行弹框
2. 一个线程轮询所有按钮的情况，死循环查看只要有一个按钮被点击了，就找出按钮绑定的框，然后弹

如果按钮很少，其实多派几个线程守着影响不大，假设有一千个、一万个按钮呢？这种场景下第二种实现更优，毕竟按钮也不是一直会被点击着，对吧。

我们把“人”、“点击按钮”、“弹框”对应到网络编程中，就是线程、事件、处理。

第一种情况翻译过来就是一个线程接待一个连接，每当连接上有事件产生，则线程会对应事件作出响应。

这对应着很早之前的网络编程模型，那时候网上没那么多用户，并且也就只有阻塞 I/O，如果连接没有反应，那么线程就得阻塞等待着 I/O 事件的发生。

第二种情况翻译过来就是，由一个线程接待多个连接，不论哪个连接上有事件产生，这个线程都会根据事件找到对应的处理逻辑来作出响应。

这就是对应现在流行的基于非阻塞 I/O 的 I/O 多路复用，这种场景就适合海量用户的情况，服务端可用很少线程来处理数量庞大的连接，就像我上面说的，毕竟连接（按钮）也不是一直会有请求过来（被点击）。

至于我前头提到的事件，基础的 I/O 上的事件也就这三种：连接事件、读事件、写事件。

现在回到网络 I/O 上，我们再来看 Reactor：也就是有一个 selector（select/poll/epoll） 线程，它管理着很多连接，只要某个连接上有事件产生，就会唤醒 selector 线程，这个线程就会根据发生的事件类型做不同的处理。

这就是 Reactor，对应的线程也叫 Reactor 线程（就靠它起反应啦）。

那没 Reactor 的场景是怎样的？

就是上面提的第一种情况，一个线程接待一条连接。不像第二种情况这样，由一个线程来接待许多连接，由一个“负责人”来接待多个客户，这种什么事都找一个人，是不是感受起来那个人就像一个 Reactor？

能一对多的根据不同请求做出不同响应实现，是我个人认为的 Reactor 核心。至于事件、调度器、Acceptor等玩意，我觉得是为了写论文或者文章必须要搞的一些概念，反正理解了之后，也就这么回事儿，因为要从流程上走通必须得有这么些个东西。

就像我们所知的 SpringMVC，要想一个请求能找到对应的 Controller，那不就得有个统一入口判断路由嘛，所以必须要有这么个东西，不然请求到不了 Controller 了啊，那这个玩意叫啥？不就是 DispatcherServlet 吗， 中文名不就是前置控制器吗。

所以，不是说 SpringMVC 需要有 DispatcherServlet 这么个玩意，而是 SpringMVC 需要有个统一入口判断路由，所以就弄了个实现类，这个实现类呢就叫 DispatcherServlet。

你懂我的意思吧。

同样看 Reactor 也是一样的。不是说 Reactor 需要有个叫 Demultiplexer、 Dispatcher、Handle、Event Handler 这么些组合起来才叫 Reactor 。

而是在网络 I/O 中基于非阻塞 I/O ，且需要少量的线程接待大量的连接，这样一场景下，就必须要个”东西“作为一个监听者，监听底层这么多连接是否有请求，然后根据请求的类型（抽象的事件），指派调用不同的处理逻辑，才对应衍生出上面这么些个名词。

在具体的实现上， Demultiplexer 和 Dispatcher 当然可以是同一个线程，同在一个死循环里面，这都是 ok 的，不要看着名词就理解着，代码里必须分这么两个玩意，不是的哈。

基于上面的理解，然后再看看来自 Reactor 论文的这张图把，是不是好理解了。

Reactor 模式的核心意义

Reactor 的核心在于“对事件作出反应”。用一个线程（或少量线程）来监听多个连接上的事件，根据事件类型分发调用相应的处理逻辑，从而避免为每个连接都分配一个线程。

与传统模型对比，传统阻塞 I/O 是一个线程对应一个连接，资源浪费严重；而 Reactor 模式能实现一对多的映射，更适合高并发场景。