Netty的NIO框架模型。在以前的文章中，为解决Jetty的问题，分析过Java NIO基于多路事件分离器的异步IO框架模型。一直都没有系统分析Netty和Jetty的网络模型，这两天将二者的网络框架部分的代码仔细读了一下，整理了二者的网络模型，画出了Netty的模型图：

   在图中，每个侦听都会创建一个Acceptor Reactor，由Boss线程来监控多路分离器，这里只关注连接事件，当有新的建立连接请求达到时，该线程会第一时间响应，将接收到的请求注册到事件多路分离器中，事件多路分离器有多个，默认情况下其个数为CPU核心数的两倍，应该是CPU超线程的数目。这里会给每一个达到的连接编一个序号，将序号对分离器个数取模(hash到0～3的一维空间)，根据模值分配给相应的分离器。事件分离器开始监听新的连接上面的读写事件。检查线程为NioWorker。读写数据会通过回调用户注册的handler的相应接口来实现。因此，处理耗时数据的情况下，需要用户将其提交给后台线程，而不应该阻塞事件分离器，否则会导致新的连接无法建立，其他并发请求无法处理。

   Jetty在代码风格上面跟Netty差别很大，看jetty代码感觉更清晰一点，可能是因为以前处理问题已经看得非常多了。前面的文章也说过，Jetty是在一个线程中调用一个同步的accept()方法来等待新的连接请求，等到新的连接到来时，就生成新的change事件放到多路分离器中，同样也是有多个多路分离器，选取原则与Netty完全一样。简单的轮询实现负载均衡。这是典型的半同步半异步(Half-Sync/Half-Async)的模式。在只使用1个事件分离器时，会发现分发线程通常会引入很多问题。前面两篇文章中提到的问题分析都跟这个有关。

   不知道Jetty与Netty为什么在接受新请求这里有差别，难道Netty的方式更利于处理短连接，而Jetty则更利于处理长连接，比如Http连接？优待进一步的并发测试才能说明问题。如果netty的方式很好，那么Jetty应该也早就改成了该方式。

建议继续学习：

1. Apache + Jetty 架设 CAS 单点登录    (阅读：4178)
2. Jetty线程“互锁”导致数据传输性能降低问题分析    (阅读：2796)
3. 关于 Jetty Continuation    (阅读：2458)
4. Jetty 8长连接上的又一个坑    (阅读：1318)