概述
在使用Java NIO和多执行绪来进行高并发Java服务端应用程序设计时，通常是基于Reactor执行绪模型来设计的。Reactor，即包含一个Java NIO的多路复用选择器Selector的反应堆，当有反应时，即该Selector所管理的某个客户端连线有IO事件过来时，则在当前执行绪或者分配到其他执行绪来处理该IO事件。Reactor执行绪模型通常由接收客户端连线请求的acceptor执行绪和处理客户端的IO请求的IO执行绪两部分组成，而acceptor执行绪和IO处理执行绪可以是同一个执行绪，也可以是不同的执行绪或者是各自对应一个执行绪池。单执行绪Reactor模型
单执行绪Reactor模型是指由一个执行绪系结一个Java NIO的多路复用选择器Selector，由该执行绪来处理该Selector的所有IO事件，包括新客户端连线建立请求，即监听套接字的IO事件，和已经建立连线的客户端套接字的所有IO事件请求，如资料读写。在单执行绪Reactor模型中，Reactor模型中的新客户端连线建立的acceptor执行绪和已经建立连线的客户端套接字的IO请求处理的IO执行绪是同一个执行绪。具体工作模式如图：服务端使用一个执行绪来处理新客户端的连线请求和已建立连线的客户端的读写IO事件。
由于该Selector所管理的所有客户端连线和服务端的监听套接字的IO请求都是由该执行绪来处理，所以如果当前执行绪正在处理某个客户端的资料读写IO请求，则无法处理当前的新建立连线的客户端请求，导致客户端无法建立连线或者连线超时。同时由于只使用一个执行绪所有也没有充分利用多核CPU。所以虽然通过使用单执行绪，规避了执行绪竞争和执行绪上下文切换，但是由于单个执行绪处理能力有限，所以单执行绪Reactor模型也无法支撑高并发客户端请求的场景，Java服务端应用程序设计很少使用到该模型。单Acceptor执行绪多IO执行绪的Reactor模型
多执行绪Reactor模型与单执行绪Reactor模型的主要区别是已经建立连线的客户端套接字的IO事件是在另外一个执行绪或者另外一个执行绪池来处理的，这种执行绪也称为IO执行绪，而处理监听套接字的新客户端连线请求的执行绪则还是一个独立的Acceptor执行绪。具体工作过程如图所示：使用在一个独立Acceptor执行绪通过监听套接字监听客户端的连线请求，当有新的客户端连线到来时，建立该客户端对应的channel并注册到其他一个IO执行绪的Selector，由该Selector监视和获取该客户端channel后续的读写IO事件并进行处理。
以上示意图是针对一个已建立连线的客户端套接字的所有IO请求可以是始终在IO执行绪池中的一个IO执行绪中处理。不过也可以是使用一个专门的IO执行绪来负责监视所有客户端的channels，当某个客户端有IO事件到来时，将该客户端的此次IO事件封装为一个Runnable的任务，交给另外的执行绪池处理，即某个客户端的所有IO事件会在不同中执行绪处理。不过推荐是始终在一个IO执行绪中处理，这样就不存在多个执行绪对该客户端套接字进行并发操作的场景，即不需要通过加锁之类的操作来对该客户端套接字对应的channel物件引用进行执行绪同步。这种已建立连线的客户端的所有IO事件都是在同一个IO执行绪中处理的方式也是netty4的IO执行绪模型，通过客户端channel与执行绪的系结来避免执行绪竞争来提高效能。多Acceptor执行绪多IO执行绪Reactor模型
多Acceptor执行绪多IO执行绪Reactor模型实际与单Acceptor执行绪多IO执行绪Reactor模型差不多，主要一个区别就是用于接收客户端的连线请求的执行绪不再是只使用一个acceptor执行绪，而是使用一个包含多个acceptor执行绪的执行绪池，从而解决单个acceptor执行绪在处理多个不同的埠的高并发客户端连线建立请求时的效能瓶颈，即当服务端需要同时监听多个埠时，可以使用一个包含多个Acceptor执行绪的执行绪池。该模型的工作过程如图所示：使用多个Acceptor执行绪来处理客户端的连线请求。
