Netty源码死磕一（netty线程模型及EventLoop机制）

引言

好久没有写博客了，近期准备把Netty源码啃一遍。在这之前本想直接看源码，但是看到后面发现其实效率不高，
有些概念还是有必要回头再细啃的，特别是其线程模型以及EventLoop的概念。

当然在开始之前还是有务必要对IO模型要有清晰准确的认识。 传送门

事件循环机制(EventLoop)

Netty线程模型中一个非常重要的概念: 事件循环机制(EventLoop)
这个概念在JS上体现的也非常淋漓尽致，下面在开始介绍netty的线程模型之前，允许我简单的介绍下事件循环机
制在JS中的体现

JS的语言性质: 单线程非阻塞，单线程意味着，js代码在执行的任何时候，都只有一个主线程来处理所有的任务>。非阻塞则意味着，在进行异步IO任务时不会阻塞主线程，主线程会挂起这个任务，等待异步任务完成再执行对应>的回调。

那么JS是如何实现单线程非阻塞的呢？JS引擎遇到一个异步事件后并不会一直等待其返回结果，而是会将此事件>挂起（例如交给浏览器去执行请求），主线程会继续执行方法栈中的其他任务。之后当异步任务返回结果后，（可>能是浏览器？）会将回调函数加入到事件队列(Task Queue)中，那么什么时候会从事件队列中取出回调函数执行>呢？当前执行栈中的所有任务都执行完毕，主线程处于闲置状态时会去查找事件队列是否有任务待执行，如果有则>将回调函数加入到主线程的方法执行栈中执行，如此反复，我们就把这个循环过程称为事件循环机制(EventLoop)。

不知道介绍了JS的件循环机制，大家有没有对Event Loop有了一个初步的认识，下面我将会着重介绍我们主角Netty的线程模型及其与Event Loop的联系。

Netty线程模型

Netty的线程模型基于Reactor，Reactor的核心在于事件分发，它有三种经典的线程模型(单线程模型，多线程>模型，主从多线程模型)，下面我们会结合Netty的EventLoop机制一一介绍

Reactor单线程模型

单线程模型全局只有一个线程在工作，也就意味着请求的接收，分发，IO读取写入等操作都在一个线程中完成，该>模型算得上是最经典的线程模型了，例如redis也是采用的此种单线程模型了。

可以看到上图中，我们把一个Reactor线程可以认为是一个EventLoop IO线程，一个事件循环机制。

由于其线程中的IO读写都是基于NIO，理论上所有的IO读写操作都不会阻塞EventLoop线程。所以即使是该单线程>模型，也是足以应付绝大多数的场景。

那么为什么又会延伸出Reactor多线程模型呢？
当应用并发量非常大时，例如一个Reactor NIO 线程需要同时处理成百上千的连接时，虽然IO读写是非阻塞的，>但是消息的编码解码都是需要同步阻塞的，这就导致NIO线程处理速度变慢，最终导致消息积压，出现性能瓶颈。

基于以上原因也就演进出了第二种模型Reactor多线程模型

Reactor多线程模型

Reactor多线程模型与Reactor单线程模型最大的区别就是，有一组Reactor NIO线程（也就是一组 EventLoop）来处理IO操作

通过上图，可以比较清晰的看到，IO的读写操作都由一个Reactor NIO线程池(对应到EventLoop也就是EventLoopGroup)来完成的，而请求的监听和Accept则是由另一个单独的Reactor线程来完成。
注意Reactor NIO线程池中的每一个线程都是处理N条链路，但是一个链路只能有一个线程来处理
多线程的Reactor模型可以满足绝大部分的应用场景，通常情况下，我们使用Netty使用这种线程模型就OK（创建>两个NioEventLoopGroup，bossGroup大小为1，workGroup大小为CPU*2）。但是有可能会存在某些极少数的情况，一
个Reactor线程处理请求的Accept可能会产生性能瓶颈，例如上百万的并发连接请求。这时候我们可能就需要采
用第三种模型Reactor主从多线程模型

Reactor主从多线程模型

Reactor主从多线程模型和Reactor多线程模型的区别在于原本是一个Reactor线程处理请求的Accept，变成了
一组Reactor线程。

对于Reactor主从多线程模型，其实大多数情况下我们并不需要。即使我们给BossGroup指定了多个线程，最终也>只会选择其中的一个作为Accepor的NIO线程，除非在服务端绑定了多个端口的情况下才会启用BossGroup的多个线
程。

尾言

把Netty的线程模型以及EventLoop理解清楚，个人觉得最好的方法还是顺着Netty的源码一步一步看，看多了
也就理解了这几种线程模型分别对应了哪几种情况，后面的文章我应该会根据源码来进一步理解netty