netty从twitter发布的这篇《Netty 4 at Twitter: Reduced GC Overhead》文章让国内Java界为之一振，也小火了一把，同时netty的社区发展也不错，版本迭代非常快，半年不关注大、小版本就发了好几轮了。但是mina就有点淡了，github上面它最后大多数代码最后的修改日期均在2013年，不过我从个人情感上还是挺喜欢mina3的代码，没有太多的用不上的功能（支持各种协议啥的），跑自带的benchmark性能也比netty4好一些。但是如果是生产用的话，就偏向netty多一些了，毕竟社区活跃，版本迭代也快。
1. mina、netty的线程模型
mina与netty都是Trustin Lee的作品，所以在很多方面都十分相似，他们线程模型也是基本一致，采用了Reactors in threads模型，即Main Reactor + Sub Reactors的模式。由main reactor处理连接相关的任务：accept、connect等，当连接处理完毕并建立一个socket连接（称之为session）后，给每个session分配一个sub reactor，之后该session的所有IO、业务逻辑处理均交给了该sub reactor。每个reactor均是一个线程，sub reactor中只靠内核调度，没有任何通信且互不打扰。
在我自己的博客里面[Netty 4.x学习笔记 – 线程模型]也对netty的线程模型有一定的介绍。现在来讲讲我对线程模型演进的一些理解：
- Thread per Connection: 在没有nio之前，这是传统的java网络编程方案所采用的线程模型。即有一个主循环，socket.accept阻塞等待，当建立连接后，创建新的线程/从线程池中取一个，把该socket连接交由新线程全权处理。这种方案优缺点都很明显，优点即实现简单，缺点则是方案的伸缩性受到线程数的限制。
- Reactor in Single Thread: 有了nio后，可以采用IO多路复用机制了。我们抽取出一个单线程版的reactor模型，时序图见下文，该方案只有一个线程，所有的socket连接均注册在了该reactor上，由一个线程全权负责所有的任务。它实现简单，且不受线程数的限制。这种方案受限于使用场景，仅适合于IO密集的应用，不太适合CPU密集的应用，且适合于CPU资源紧张的应用上。
- Reactor + Thread Pool: 方案2由于受限于使用场景，但为了可以更充分的使用CPU资源，抽取出一个逻辑处理线程池。reactor仅负责IO任务，线程池负责所有其它逻辑的处理。虽然该方案可以充分利用CPU资源，但是这个方案多了进出thread pool的两次上下文切换。
- Reactors in threads: 基于方案3缺点的考虑，将reactor分成两个部分。main reactor负责连接任务（accept、connect等），sub reactor负责IO、逻辑任务，即mina与netty的线程模型。该方案适应性十分强，可以调整sub reactor的数量适应CPU资源紧张的应用；同时CPU密集型任务时，又可以在业务处理逻辑中将任务交由线程池处理，如方案5。该方案有一个不太明显的缺点，即session没有分优先级，所有session平等对待均分到所有的线程中，这样可能会导致优先级低耗资源的session堵塞高优先级的session，但似乎netty与mina并没有针对这个做优化。
- Reactors in threads + Threads pool: 这也是我所在公司应用框架采用的模型，可以更为灵活的适应所有的应用场景：调整reactor数量、调整thread pool大小等。