Netty之EventLoop和EventLoopGroup(七)

淩亂°似流年 2022-11-26 15:52 160阅读 0赞

### 文章目录 ###

*   *   *  Netty的线程模型
         *   *  Reactor单线程模型
         *  Reactor 多线程模型
         *  主从Reactor多线程模型
         *  Netty 的线程模型
     *  NioEventLoop 源码分析

### Netty的线程模型 ###

#### Reactor单线程模型 ####

Reactor单线程模型，是指所有的IO操作都在同一个NIO线程上面完成。NIO线程的职责如下：

*  作为NIO服务端，接收客户端的TCP连接；
 *  作为NIO客户端，向服务端发起TCP连接；
 *  读取通信对端的请求或者应答消息；
 *  向通信对端发送消息请求或者应答消息。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center]

由于 Reactor模式使用的是异步非阻塞I/O，所有的IO操作都不会导致阻塞，理论上一个线程可以独立处理所有IO相关的操作。从架构层面看，一个NIO线程确实可以完成其承担的职责。例如，通过 Acceptor类接收客户端的TCP连接请求消息，当链路建立成功之后，通过 Dispatch将对应的 Bytebuffer派发到指定的 Handler上，进行消息解码。用户线程消息编码后通过NIO线程将消息发送给客户端。

在一些小容量应用场景下，可以使用单线程模型。但是这对于高负载、大并发的应用场景却不合适，主要原因如下:

*  一个NIO线程同时处理成百上千的链路，性能上无法支撑，即便N1O线程的CPU负荷达到100%,也无法满足海量消息的编码、解码、读取和发送;
 *  当NIO线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了NO线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈;
 *  可靠性问題：一且NIO线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。

为了解决这些问题，演进出了 Reactor多线程模型。下面我们一起学习下 Reactor多线程模型。

### Reactor 多线程模型 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 1]

Reactor多线程模型的特点如下:

*  有专门一个NIO线程一一 Acceptor线程用于监听服务端，接收客户端的TCP连接请求;
 *  网络IO操作一一读、写等由一个NIO线程池负责，线程池可以采用标准的JDK线程池实现，它包含一个任务队列和N个可用的线程，由这些NIO线程负责消息的读取、解码、编码和发送;
 *  一个NIO线程可以同时处理N条链路，但是一个链路只对应一个NIO线程，防止发生并发操作问题。

在绝大多数场景下， Reactor多线程模型可以满足性能需求。但是，在个别特殊场景中，一个NIO线程负责监听和处理所有的客户端连接可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能在这类场景下，单独一个 Acceptor线程可能会存在性能不足的问题，为了解决性能问题，产生了第三种 Reactor线程模型一主从 Reactor多线程模型。

### 主从Reactor多线程模型 ###

主从 Reactor线程模型的特点是：服务端用于接收客户端连接的不再是一个单独的NIO线程，而是一个独立的NIO线程池。 Acceptor接收到客户端TCP连接请求并处理完成后（可能包含接入认证等），将新创建的 Socket Channel注册到I/O线程池（ sub reactor线程池）的某个I/O线程上，由它负责 Socket Channel的读写和编解码工作。 Acceptor线程池仅仅用于客户端的登录、握手和安全认证，一旦链路建立成功，就将链路注册到后端 subreactor线程池的I/0线程上，由I/O线程负责后续的I/O操作。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 2]  
利用主从NIO线程模型，可以解决一个服务端监听线程无法有效处理所有客户端连接的性能不足问题。因此，在Nety的官方demo中，推荐使用该线程模型。

### Netty 的线程模型 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 3]  
从之前的代码可以看到：  
服务端启动的时候，创建了两个 Nioeventloopgroup，它们实际是两个独立的 Reactor线程池。一个用于接收客户端的TCP连接，另ー个用于处理I/O相关的读写操作，或者执行系统Task、定时任务Task等。

Nety用于接收客户端请求的线程池职责如下:

*  接收客户端TCP连接，初始化 Channel参数；
 *  将链路状态变更事件通知给 Channelpipeline.

Nety处理I/O操作的 Reactor线程池职责如下:

*  异步读取通信对端的数据报，发送读事件到 Channelpipeline;
 *  异步发送消息到通信对端，调用 Channelpipeline的消息发送接口;
 *  执行系统调用Task;
 *  执行定时任务Task，例如链路空闲状态监测定时任务.

通过调整线程池的线程个数、是否共享线程池等方式，Nety的 Reactor线程模型可以在单线程、多线程和主从多线程间切换，这种灵活的配置方式可以最大程度地满足不同用户的个性化定制.

为了尽可能地提升性能， Netty在很多地方进行了无锁化的设计，例如在I/O线程内部进行串行操作，避免多线程竞争导致的性能下降问题。表面上看，串行化设计似乎CPU利用率不高，并发程度不够。但是，通过调整NIO线程池的线程参数，可以同时启动多个串行化的线程并行运行，这种局部无锁化的串行线程设计相比一个队列一多个工作线程的模型性能更优。

## NioEventLoop 源码分析 ##

首先看Selector是如何开启的：  
Selector的初始化非常简单，直接调用 Selector.open(0方法就能创建并打开一个新的Selector.Nety对 Selector的 selectedkeys进行了优化，用户可以通过io. netty. nokeysetOptimization开关决定是否启用该优化项。默认不打开 selectedkeys优化功能。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 4]  
如果没有开启 selectedkeys优化开关，通过 provider. open Selector创建并打开多路复用器之后就立即返回。如果开启了优化开关，需要通过反射的方式从 Selector实例中获取 selectedkeys和publicselectedkeys，将上述两个成员变量设置为可写，通过反射的方式使用Ncty构造的selectedkeys包装类 selectedkeyset将原JDK的 selectedkeys替换掉。

接着看run方法的实现：

所有的逻辑操作都在for循环体内进行，只有当 Nioeventloop接收到退出指令的时候，才退出循环，否则一直执行下去，这也是通用的NIO线程实现方式首先需要将 wakeup还原为 false，并将之前的 wake up状态保存到 old Wakeup变量中。通过 has Taskso方法判断当前的消息队列中是否有消息尚未处理，如果有则调用selectnowo方法立即进行一次 select操作，看是否有准备就绪的 Channel需要处理。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 6]  
Selector的 selectnowo方法会立即触发 Selector的选择操作，如果有准备就绪的annel，则返回就绪 Channel的集合，否则返回0.选择完成之后，再次判断用户是否调用了 Selector的 wakeup方法，如果调用，则执行 selector. wakeup()操作。

下面我们返回到run方法，继续分析代码。如果消息队列中没有消息需要处理，则执行 selecto方法，由 Selector多路复用器轮询，看是否有准备就绪的 Channel。

取当前系统的纳秒时间，调用 delaynanos()方法计算获得 Nioeventloop中定时任务的触发时间。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 7]  
计算下一个将要触发的定时任务的剩余超时时间，将它转换成毫秒，为超时时间增加0.5毫秒的调整值。对剩余的超时时间进行判断，如果需要立即执行或者已经超时，则调用 selector. selectnowo进行轮询操作，将 selecton设置为1,并退出当前循环。

将定时任务剩余的超时时间作为参数进行 select操作，每完成一次 select操作，对 select计数器 selecton加1.

Select操作完成之后，需要对结果进行判断，如果存在下列任意一种情况，则退出当前循环。

*  有 Channel处于就绪状态， selectedkeys不为0,说明有读写事件需要处理z；
 *  old Wakenup为 true:
 *  系统或者用户调用了 wakeup操作，唤醒当前的多路复用器；
 *  消息队列中有新的任务需要处理。

如果本次 Selector的轮询结果为空，也没有 wakeup操作或是新的消息需要处理，则说明是个空轮询，有可能触发了JDK的 epoll bug，它会导致 Selector的空轮询，使I/O线程一直处于100%状态。截止到当前最新的JDK7版本，该bug仍然没有被完全修复。所以Nety需要对该bug进行规避和修正。

测到 Selector处于死循环后，需要通过重建 Selector的方式让系统恢复正常，代码如下:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 8]  
首先通过 ineventloop（方法判断是否是其他线程发起的 rebuildselector，如果由其他线程发起，为了避免多线程并发操作 Selector和其他资源，需要将 rebuildselector封装成Task，放到 Nioeventloop的消息队列中，由 Nioeventloop线程负责调用，这样就避免了多线程并发操作导致的线程安全问题。

调用 openselector方法创建并打开新的 Selector，通过循环，将原 Selector上注册的Socket Channel从旧的 Selector上去注册，重新注册到新的 Selector上，并将老的 Selector关闭。代码如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 9]  
通过销毁旧的、有问题的多路复用器，使用新建的 Selector，就可以解决空轮询 Selector导致的IO线程CPU占用100%的问题。

如果轮询到了处于就绪状态的 Socket Channel，则需要处理网络I/O事件，相关代码如下所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 10]  
由于默认未开启 selectedkeys 1优化功能，所以会进入 processselectedkeysplain分支执行。下面继续分析 processselectedkeysplain I的代码实现，如下图所示：

对 Selectionkey进行保护性判断，如果为空则返回。获取 Selection Key的迭代器进行循环操作，通过迭代器获取 Selection Key和 Socket Channel的附件对象，将已选择的选择键从迭代器中刑除，防止下次被重复选择和处理，代码如下图所示：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 11]

对 Socket Channel的附件类型进行判读，如果是 Abstractnio Channel类型，说明它是Nio Serversocketchannel或者 Niosocket Channel，需要进行I/O读写相关的操作；如果它是Nio Task，则对其进行类型转换，调用 processselectedkey进行处理。由于Nety自身没实现 Nio Task接口，所以通常情况下系统不会执行该分支，除非用户自行注册该Task到多路复用器。

下面我们继续分析I/O事件的处理，代码如下图所示：

首先从 Nioserversocket Channel或者 Nio Socketchannel中获取其内部类 Unsafe，判断当前选择键是否可用，如果不可用，则调用 Unsafe的 close方法，释放连接资源。

如果是读或者连接操作，则调用 Unsafe的read方法。此处 Unsafe的实现是个多态，对于 Nioserversocketchannel，它的读操作就是接收客户端的TCP连接。

如果网络操作位为写，则说明有半包消息尚未发送完成，需要继续调用flush方法进行发送

如果网络操作位为连接状态，则需要对连接结果进行判读

需要注意的是，在进行 finish Connect 3判断之前，需要将网络操作位进行修改，注销掉SelectionKey OP\_CONNECT。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 12]

处理完IO事件之后， Nioevent Loop需要执行非I/O操作的系统Task和定时任务:  
![在这里插入图片描述][20200812174603212.png_pic_center]  
由于 Nioevent Loop需要同时处理1/O事件和非IO任务，为了保证两者都能得到足够的CPU时间被执行，Nety提供了I/O比例供用户定制。如果1/O操作多于定时任务和Task则可以将I/O比例调大，反之则调小，默认值为50%。

Task的执行时间根据本次1O操作的执行时间计算得来。下面我们具体看 runalitask方法的实现，如下：  
![在这里插入图片描述][20200812174913316.png_pic_center]

首先从定时任务消息队列中弹出消息进行处理，如果消息队列为空，则退出循环。根据当前的时间戳进行判断，如果该定时任务已经或者正处于超时状态，则将其加入到执行Task Queue中，同时从延时队列中删除。定时任务如果没有超时，说明本轮循环不需要处理，直接退出即可，代码实现如下：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 13]  
执行 Task Queue中原有的任务和从延时队列中复制的已经超时或者正处于超时状态的定时任务，代码如下图：

由于获取系统纳秒时间是个耗时的操作，每次循环都获取当前系统纳秒时间进行超时判断会降低性能。为了提升性能，每执行60次循环判断一次，如果当前系统时间已经到了分配给非I/O操作的超时时间，则退出循环。这是为了防止由于非I/O任务过多导致IO操作被长时间阻塞。

最后，判断系统是否进入优雅停机状态，如果处于关闭状态，则需要调用 closer方法，释放资源，并让 Nioeventloop线程退出循环，结束运行。资源关闭的代码实现如下图：

遍历获取所有的 Channel，调用它的 Unsafe. close()方法关闭所有链路，释放线程池Channelpipeline和 Channelhandler等资源。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 14]

以上。

> [Netty之Java I/O演进之路（一）][Netty_Java I_O]  
> [Netty之NIO入门（二）][Netty_NIO]  
> [Netty之Netty入门应用（三）][Netty_Netty]  
> [Netty之TCP粘包/拆包问题（四）][Netty_TCP]  
> [Netty之编解码开发（五）][Netty]  
> [Netty之ChannelPipeline(六)][Netty_ChannelPipeline]  
> [Netty之EventLoop和EventLoopGroup(七)][Netty_EventLoop_EventLoopGroup]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center]: /images/20221124/0bb9ea12023f42df81334b60adec32c4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221124/c117ca8b58ba469ab69f440617a7145b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221124/293da4cb6cc045bdbfa17e3465b6916b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 3]: /images/20221124/038cb62099c54e6581f178c44dce2214.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 4]: /images/20221124/b25449e556984a1f9283b5a41dc5860a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 5]: /images/20221124/e27d591ca03a441cbb0ee438a9c7bc34.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 6]: /images/20221124/33a7ebf74181461493e9e1ef721ed1da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 7]: /images/20221124/8a282fe10075488390a8b46038fcbd50.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 8]: /images/20221124/911280906c9243a5afe6a2faceb0bfa5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 9]: /images/20221124/d1f144036a03442aaa30e071385b1a32.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 10]: /images/20221124/cae798c03d294438805375bf5fc2e222.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 11]: /images/20221124/ff8aa1e35bf34a33941d8a06c3213b53.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 12]: /images/20221124/1640bf7342a34607a1d03e185a9d05da.png
[20200812174603212.png_pic_center]: /images/20221124/26c1958d25814185933a32da38520f89.png
[20200812174913316.png_pic_center]: /images/20221124/0d0f2465348b43f99dbd27ed19a8763c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 13]: /images/20221124/6b95c28c0e664374821d58c171d4c8cc.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYW5qdW5fZmVp_size_16_color_FFFFFF_t_70_pic_center 14]: /images/20221124/4f79df1ef3bd444e915913fe77693f3e.png
[Netty_Java I_O]: https://blog.csdn.net/jianjun_fei/article/details/107505729
[Netty_NIO]: https://blog.csdn.net/jianjun_fei/article/details/107513219
[Netty_Netty]: https://blog.csdn.net/jianjun_fei/article/details/107555647
[Netty_TCP]: https://blog.csdn.net/jianjun_fei/article/details/107563110
[Netty]: https://blog.csdn.net/jianjun_fei/article/details/107772642
[Netty_ChannelPipeline]: https://blog.csdn.net/jianjun_fei/article/details/107787864
[Netty_EventLoop_EventLoopGroup]: https://blog.csdn.net/jianjun_fei/article/details/107956949