引言
好久没有写博客了，近期准备把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