本文是Netty系列第6篇

上一篇文章咱们从一个Netty的使用Demo，了解了用Netty构建一个Server服务端应用的基本方式。而且从这个Demo出发，简述了Netty的逻辑架构。web

今天主要是深刻学习下逻辑架构中的EventLoop 和 EventLoopGroup，掌握Netty的线程模型，这是Netty最精髓的知识点之一。安全

本文预计阅读时间约「15分钟」，将重点围绕如下几个问题展开：微信

什么是Reactor线程模型？网络
EventLoopGroup、EventLoop 怎么实现Reactor线程模型？数据结构
深刻Netty的线程模型优化多线程

Netty3和Netty4的线程模型变化架构
什么是Netty4线程模型的无锁串行化并发

从线程模型看最佳实践app

先简单回顾下上一篇的逻辑架构图，看看EventLoop 和 EventLoopGroup是在什么位置。socket

1.什么是Reactor线程模型？

先来回顾下咱们在Netty系列的第2篇介绍的I/O线程模型，包括BIO、NIO、I/O多路复用、信号驱动IO、AIO。IO多路复用在Java中有专门的NIO包封装了相关的方法。

前面的文章也说过，使用Netty而不是直接使用Java NIO包，就是由于Netty帮咱们封装了许多对NIO包的使用细节，作了许多优化。

其中很是著名的，就是Netty的「Reactor线程模型」。

前置知识若是还不太清楚，能够回头看看前面几篇文章：

《没搞清楚网络I/O模型？那怎么入门Netty》
《从网络I/O模型到Netty，先深刻了解下I/O多路复用》
《从I/O多路复用到Netty，还要跨过Java NIO包》

Reactor模式是一种「事件驱动」模式。

「Reactor线程模型」就是经过单个线程使用Java NIO包中的Selector的select()方法，进行监听。当获取到事件（如accept、read等）后，就会分配（dispatch)事件进行相应的事件处理（handle）。

若是要给 Reactor线程模型下一个更明确的定义，应该是：

Reactor线程模式 = Reactor（I/O多路复用）+ 线程池

其中Reactor负责监听和分配事件，线程池负责处理事件。

而后，根据Reactor的数量和线程池的数量，又能够将Reactor分为三种模型

单Reactor单线程模型 (固定大小为1的线程池)
单Reactor多线程模型
多Reactor多线程模型 (通常是主从2个Reactor)

1.1 单Reactor单线程模型

Reactor内部经过 selector 监听链接事件，收到事件后经过dispatch进行分发。

若是是链接创建的事件，经过accept接受链接，并建立一个Handler来处理链接后续的各类事件。
若是是读写事件，直接调用链接对应的Handler来处理，Handler完成 read => (decode => compute => encode) => send 的所有流程

这个过程当中，不管是事件监听、事件分发、仍是事件处理，都始终只有一个线程执行全部的事情。

缺点：
在请求过多时，会没法支撑。由于只有一个线程，没法发挥多核CPU性能。
并且一旦某个Handler发生阻塞，服务端就彻底没法处理其余链接事件。

1.2 单Reactor多线程模型

为了提升性能，咱们能够把复杂的事件处理handler交给线程池，那就能够演进为「单Reactor多线程模型」。

这种模型和第一种模型的主要区别是把业务处理从以前的单一线程脱离出来，换成线程池处理。

1）Reactor线程

经过select监听客户请求，若是是链接创建的事件，经过accept接受链接，并建立一个Handler来处理链接后续的读写事件。这里的Handler只负责响应事件、read和write事件，会将具体的业务处理交由Worker线程池处理。

只处理链接事件、读写事件。

2）Worker线程池

处理全部业务事件，包括(decode => compute => encode) 过程。

充分利用多核机器的资源，提升性能。

缺点：
在极个别特殊场景中，一个Reactor线程负责监听和处理全部的客户端链接可能会存在性能问题。例如并发百万客户端链接（双11、春运抢票）

1.3 多Reactor多线程模型

为了充分利用多核能力，能够构建两个 Reactor，这就演进为「主从Reactor线程模型」。

1）主Reactor

主 Reactor 单独监听server socket，accept新链接，而后将创建的 SocketChannel 注册给指定的从Reactor，

2）从Reactor

从Reactor 将链接加入到链接队列进行监听，并建立handler进行事件处理。执行事件的读写、分发，把业务处理就扔给worker线程池完成。

3）Worker线程池
处理全部业务事件，充分利用多核机器的资源，提升性能。

轻松处理百万并发。

缺点：
实现比较复杂。

不过有了Netty，一切都变得简单了。

Netty帮咱们封装好了一切，能够快速使用主从Reactor线程模型（Netty4的实现上增长了无锁串行化设计），具体代码这里就不贴了，能够看看上一篇的Demo。

2. EventLoop、EventLoopGroup 怎么实现Reactor线程模型？

上面咱们已经了解了Reactor线程模型，了解了它的核心就是：

Reactor线程模式 = Reactor（I/O多路复用）+ 线程池

它的运行模式包括四个步骤：

链接注册：创建链接后，将channel注册到selector上
事件轮询：selcetor上轮询（select()函数）获取已经注册的channel的全部I/O事件（多路复用）
事件分发：把准备就绪的I/O事件分配到对应线程进行处理
事件处理：每一个worker线程执行事件任务

那这样的模型在Netty中具体怎么实现呢？

这就须要咱们了解下EventLoop和EventLoopGroup了。

2.1 EventLoop是什么

EventLoop 不是Netty独有的，它自己是一个通用的事件等待和处理的程序模型。主要用来解决多线程资源消耗高的问题。例如 Node.js 就采用了 EventLoop 的运行机制。

那么，在Netty中，EventLoop是什么呢？

一个Reactor模型的事件处理器。
单独一个线程。
一个EventLoop内部会维护一个selector和一个「taskQueue任务队列」，分别负责处理「I/O事件」和「任务」。

「taskQueue任务队列」是多生产者单消费者队列，在多线程并发添加任务时，能够保证线程安全。

「I/O事件」即selectionKey中的事件，如accept、connect、read、write等；

「任务」包括普通任务、定时任务等。

普通任务：经过 NioEventLoop 的 execute() 方法向任务队列 taskQueue 中添加任务。例如 Netty 在写数据时会封装 WriteAndFlushTask 提交给 taskQueue。
定时任务：经过调用 NioEventLoop 的 schedule() 方法向定时任务队列 scheduledTaskQueue 添加一个定时任务，用于周期性执行该任务（如心跳消息发送等）。定时任务队列的任务到了执行时间后，会合并到普通任务队列中进行真正执行。

一图胜千言:

EventLoop单线程运行，循环往复执行三个动做：

selector事件轮询
I/O事件处理
任务处理

2.2 EventLoopGroup是什么

EventLoopGroup比较简单，能够简单理解为一个“EventLoop线程池”。

Tips：

监听一个端口，只会绑定到 BossEventLoopGroup 中的一个 Eventloop，因此， BossEventLoopGroup 配置多个线程也无用，除非你同时监听多个端口。

2.3 具体实现

Netty能够经过简单配置，支持单Reactor单线程模型、单Reactor多线程模型、多Reactor多线程模型。

咱们以「多Reactor多线程模型」为例，来看看Netty是如何经过EventLoop来实现的。

仍是一图胜千言：

咱们结合Reactor线程模型的四个步骤来梳理一下：

1）链接注册

master EventLoopGroup中有一个EventLoop，绑定某个特定端口进行监听。

一旦有新的链接进来触发accept类型事件，就会在当前EventLoop的I/O事件处理阶段，将这个链接分配给slave EventLoopGroup中的某一个EventLoop，进行后续事件的监听。

2）事件轮询

slave EventLoopGroup中的EventLoop，会经过selcetor对绑定到自身的channel进行轮询，获取已经注册的channel的全部I/O事件（多路复用）。

固然，EventLoopGroup中会有多个EventLoop 运行，各自循环处理。具体EventLoop数量是由用户指定的线程数或者默认为核数的2倍。

3）事件分发

当slave EventLoopGroup中的EventLoop获取到I/O事件后，会在EventLoop的 I/O事件处理（processSelectedKeys）阶段分发给对应ChannelPipeline进行处理。

注意，仍然在当前线程进行串行处理

4）事件处理

在ChannelPipeline中对I/O事件进行处理。

I/O事件处理完后，EventLoop在任务处理（runAllTasks）阶段，对队列中的任务进行消费处理。

至此，咱们就能彻底梳理清楚EventLoopGroup/EventLoop 和 Reactor线程模型的关系了。

咦，好像有什么地方不对劲？

没错，细心的朋友可能会发现，slave EventLoopGroup中并非

一个selector + 线程池

而是有多个EventLoop组成的

多selector + 多个单线程

这是为何呢？

那就得继续深刻了解下Netty4的线程模型优化了。

3. 深刻Netty的线程模型优化

上文说过，对每一个EventLoop来讲，都是单线程运行，并循环往复执行三个动做：

selector事件轮询
I/O事件处理
任务处理

在slave EventLoopGroup中，并非 “一个selector + 线程池”模式，而是有多个EventLoop组成的 “多selector + 多个单线程“ 模型，这是为何呢？

这主要是由于咱们分析的是Netty4的线程模型，跟Netty3的传统Reactor模型相比有了不一样之处。

3.1 Netty3和Netty4的线程模型变化

在Netty3的线程模型中，分为读事件处理模型和写事件处理模型。

read事件的ChannelHandler都是由Netty的 I/O 线程（对应Netty 4 中的 EventLoop）中负责执行。
I/O线程调度执行ChannelPipeline中Handler链的对应方法，直到业务实现的End Handler。
End Handler将消息封装成Runnable，放入到业务线程池中执行，I/O线程返回，继续读/写等I/O操做。

write事件是由调用线程处理，多是 I/O 线程，也多是业务线程。
若是是业务线程，那么业务线程会执行ChannelPipeline中的Channel Handler。
执行到系统最后一个ChannelHandler，将编码后的消息Push到发送队列中，业务线程返回。
Netty的I/O线程从发送消息队列中取出消息，调用SocketChannel的write方法进行消息发送。

由上文能够看到，在Netty3的线程模型中，是采用“selector + 业务线程池”的模型。

注意，在这种模型下，读写模型不一致。尤为是读事件、写事件的「执行线程」是不同的。

可是在Netty4的线程模型中，采用了“多selector + 多个单线程”模型。

读事件：

I/O线程NioEventLoop从SocketChannel中读取数据，将ByteBuf投递到ChannelPipeline，触发ChannelRead事件；
I/O线程NioEventLoop调用ChannelHandler链，直到将消息投递到业务线程，而后I/O线程返回，继续后续的操做。

写事件：

业务线程调用ChannelHandlerContext.write(Object msg)方法进行消息发送。
ChannelHandlerInvoker将发送消息封装成任务，放入到EventLoop的Mpsc任务队列中，业务线程返回。后续由EventLoop在循环中统一调度和执行。
I/O线程EventLoop在进行任务处理时，从Mpsc任务队列中获取任务，调用ChannelPipeline进行处理，处理Outbound事件，直到将消息放入发送队列，而后唤醒Selector，执行写操做。

Netty4中，不管读写，都是经过I/O线程(也就是EventLoop)来统一处理。

为何Netty4的线程模型作了这样的变化？答案就是无锁串行化设计。

3.2 什么是Netty4线程模型的无锁串行化

咱们先看看Netty3的线程模型存在什么问题：

读/写线程模型不一致，带来额外的开发心智负担。
写操做由业务线程发起时，一般业务会使用线程池多线程并发执行某个业务流程，因此某一个时刻会有多个业务线程同时操做ChannelHandler，咱们须要对ChannelHandler进行并发保护，大大下降了开发效率。
频繁的线程上下文切换，会带来额外的性能损耗。

而Netty4线程模型的「无锁串行化」设计，就很好地解决了这些问题。

一图胜千言：

从事件轮询、消息的读取、编码以及后续Handler的执行，始终都由I/O线程NioEventLoop内部进行串行操做，这就意味着整个流程不会进行线程上下文的切换，避免多线程竞争致使的性能降低，数据也不会面临被并发修改的风险。

表面上看，串行化设计彷佛CPU利用率不高，并发程度不够。可是，经过调整slave EventLoopGroup的线程参数，能够同时启动多个NioEventLoop，串行化的线程并行运行，这种局部无锁化的串行线程设计相比「一个队列-多个工做线程模型」性能更优。

总结下Netty4无锁串行化设计的优势：

一个EventLoop会处理一个channel全生命周期的全部事件。从消息的读取、编码以及后续Handler的执行，始终都由I/O线程NioEventLoop负责。
每一个EventLoop会有本身独立的任务队列。
整个流程不会进行线程上下文的切换，数据也不会面临被并发修改的风险。
对于用户而言，统一的读写线程模型，也下降了使用的心智负担。

4. 从线程模型看最佳实践

NioEventLoop 无锁串行化的设计这么好，它就天衣无缝了吗？

不是的！

在特定的场景下，Netty3的线程模型可能性能更高。好比编码和其它写操做很是耗时，由多个业务线程并发执行，性能确定高于单个EventLoop线程串行执行。

所以，虽然单线程执行避免了线程切换，可是它的缺陷就是不能执行时间过长的 I/O 操做，一旦某个 I/O 事件发生阻塞，那么后续的全部 I/O 事件都没法执行，甚至形成事件积压。

因此，Netty4的线程模型的最佳实践须要注意如下两点：

不管读/写，不在自定义ChannelHandler中作耗时操做。
不把耗时操做放进任务队列。

本文从Reactor线程模型开始提及，到Netty如何用EventLoop实现Reactor线程模型。

而后对Netty4的线程模型优化作了详细介绍，尤为是「无锁串行化设计」。

最后从EventLoop线程模型出发，说明了平常开发中使用Netty4开发的最佳实践。

但愿你们能对EventLoop有全面的认识。

另外，限于篇幅，EventLoop中有两个很是重要的数据结构没有展开介绍，大家知道是什么吗？

后面会单独写两篇进行分析，敬请期待。

若是有任何疑问或者建议，欢迎 写留言或者微信和我联系哦～

参考书目：
《Netty in Action》

往期热门笔记合集推荐：

原创：阿丸笔记（微信公众号：aone_note），欢迎分享，转载请保留出处。

扫描下方二维码能够关注我哦～

以为不错，就点个再看吧👇