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