文中所讲基本都是以非阻塞IO、异步IO为基础。对于阻塞式IO，下面的编程模型几乎都不适用
Reactor三种线程模型 单线程模型单个线程以非阻塞IO或事件IO处理所有IO事件，包括连接、读、写、异常、关闭等等。单线程Reactor模型基于同步事件分离器来分发事件，这个同步事件分离器，可以看做是一个单线程的while循环。下图描述了单线程模型的处理过程，看起来与网上大部分资料的图片不同，但本质是相同的。
注意上面的Selector之所以会有OP_ACEEPT事件，是因为在单线程模型中，Selector轮询的是监听套接字与已连接客户端套接字的所有IO事件。
单线程处理所有IO事件的弊端很明显。没能利用计算机CPU多核的特性，一个线程某个时刻只能处理单个IO事件，此时如果有其他描述符有IO事件就绪（如来了一个新的连接），这些IO事件将暂时得不到处理。
C++框架libevent中，基于event_base_loop做消息轮询，使用event_base_dispatch来分发IO消息，本质上是对上述模型的封装。如果不使用evthread_use_pthreads，则其默认就是单线程模型处理请求。
多线程模型一个线程/进程接收连接、一组线程/进程处理IO读写事件。也就是将accept的线程与处理读、写等IO事件的线程分离，并且使用m多个线程、使用非阻塞IO或者事件IO来处理n个套接字的IO事件，这里的n一般远大于m，m一般取CPU逻辑核心数的1-3倍，而套接字数n则取决于请求数和进程可以打开的最大描述符个数。下图是多线程模型
可以看到，这里把客户端的已连接套接字，转交给某个IO线程之后，由此线程轮询处理其之后的所有IO事件，这实际参考了netty4的线程模型设计。实际reactor的多线程模型，并不需要将已连接套接字绑定在某个线程上，也可以统一放在连接池中，由多个IOWork线程从池中取连接进行轮询并处理，但这样会复杂很多，而且容易出问题，比如说不同线程从同一个channel收到了write事件，这就类似惊群问题了；并且多线程并发操作同一个channel，后续很可能需要你讲IO事件进行同步，与其如此，不如直接将channel绑定到一个线程，让channel上触发与处理IO事件逻辑上同步。netty3中channel（已连接套接字）入站事件由固定线程处理，出站事件由触发的线程处理，netty4中修改了设计，将channel绑定到固定的eventloop（线程）。
另外一点，每个已连接套接字的IO事件由固定线程处理，不代表事件也一定由此线程触发，恰恰相反，实际业务中，读（入站）事件来自于客户端写数据触发，而写（出站）事件往往由别的线程触发，例如在发起一个异步mysql操作完成之后，在异步回调线程中写结果数据来触发套接字的出站。
从多线程模型一组线程/进程接收连接、一组线程/进程处理IO读写事件。它与多线程模型的主要区别在于其使用一组线程或进程在一个共享的监听套接字上accept连接。这么做的原因是为了应付单个线程/进程不足以快速处理内核中监听套接字的已连接套接字队列（并发量极大）的情况。如下
主从多线程模型，有可能引起惊群效应。不过这个问题已经渐渐被规避，内核可以保证连接只被唯一一个accept调用所获取，其余对此连接的accept调用将失败。
Netty支持的线程模型Netty支持单线程、多线程模型、主从多线程模型。但经本人多次测试、调试发现，ServerBootstrap默认不会使用主从多线程模型。虽然server支持设置EventLoopGroup（多个EventLoop）。但实际对于一个本地地址（IP+端口）进行accept，netty只会绑定到一个EventLoop上，故只会创建一个线程处理。
按本人的理解，Boss EventLoopGroup（Master EventLoopGroup，参数nThreads不为1）的作用主要用在对共享的监听套接字或者多个本地地址监听，对多个本地地址进行监听一般表示一个JVM中有多个server，即有多个ServerBootStrap，这时，Boss EventLoopGroup可以通过共享给这多个ServerBootStrap起到作用（创建多个boss/master Thread）。
以下面的代码为例MASTER_THREAD_CNT为4，但netty实际只会使用第一个EventLoop，只会给第一个EventLoop创建线程。
调试跟踪源码，可以明白netty的逻辑。