java NIO 之 mina 和 netty
Mina 和 Netty 同属于nio框架，但是Mina较早，而Netty更新，同时Netty的更新频率和社区活跃度都比Mina高，所以如果选择项目开发的话，Netty会比较稳妥。
两者的主要区别：
- Netty 文档更完整，版本更新更快
- Mina 则依赖Apache，Netty 依赖JBoss，和jboss的结合度非常高，netty有对google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)；
- netty比mina使用起来更简单，netty里你可以自定义的处理upstream events 或/和 downstream events，可以使用decoder和encoder来解码和编码发送内容；
- netty和mina在处理UDP时有一些不同，netty将UDP无连接的特性暴露出来；而mina对UDP进行了高级层次的抽象，可以把UDP当成"面向连接"的协议，而要netty做到这一点比较困难。mina把TCP和UDP一样当"有连接"的处理，一个UDP请求会按照address产生一个新的 IoSession，过期时间是1分钟，这样做的好处是显然的，但是对于有性能要求的项目就不好了，对一个无连接的东西cache 1分钟，大多数时候可能是白cache了，做无用功。
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中只靠内核调度，没有任何通信且互不打扰。
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大小等。
参考
http://ifeve.com/netty-mina-in-depth-1/