JAVA 培训(四) NIO框架对比

Mina、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中只靠内核调度，没有任何通信且互不打扰。

Thread per Connection: 在没有nio之前，这是传统的java网络编程方案所采用的线程模型。即有一个主循环，socket.accept阻塞等待，当建立连接后，创建新的线程/从线程池中取一个，把该socket连接交由新线程全权处理。这种方案优缺点都很明显，优点即实现简单，缺点则是方案的伸缩性受到线程数的限制。
Reactor in Single Thread: 有了nio后，可以采用IO多路复用机制了。我们抽取出一个单线程版的reactor模型，时序图见下文，该方案只有一个线程，所有的socket连接均注册在了该reactor上，由一个线程全权负责所有的任务。它实现简单，且不受线程数的限制。这种方案受限于使用场景，仅适合于IO密集的应用，不太适合CPU密集的应用，且适合于CPU资源紧张的应用上。

2. mina、netty的任务调度粒度

mina、netty在线程模型上并没有太大的差异性，主要的差异还是在任务调度的粒度的不同。任务从逻辑上我给它分为成三种类型：连接相关的任务（bind、connect等）、写任务（write、flush）、调度任务（延迟、定时等），读任务则由selector加循环时间控制了。mina、netty任务调度的趋势是逐渐变小，从session级别的调度 -> 类型级别任务的调度 -> 任务的调度。

3. ByteBuffer设计的差异

需要说明的是，只有mina1、2才有自己的buffer类，mina3内部只用nio的原生ByteBuffer类（提供了一个组合buffer的代理类-IoBuffer）

4. Netty的优点可以总结如下

1、API使用简单，开发门槛低；

2、功能强大，预置了多种编解码功能，支持多种主流协议；

3、定制能力强，可以通过ChannelHandler对通信框架进行灵活地扩展；

4、性能高，通过与其他业界主流的NIO框架对比，Netty的综合性能最优；

5、成熟、稳定，Netty修复了已经发现的所有JDK NIO BUG，业务开发人员不需要再为NIO的BUG而烦恼；

6、社区活跃，版本迭代周期短，发现的BUG可以被及时修复，同时，更多的新功能会加入；

7、经历了大规模的商业应用考验，质量得到验证。在互联网、大数据、网络游戏、企业应用、电信软件等众多行业得到成功商用，证明了它已经完全能够满足不同行业的商业应用了。

与Mina相比有什么优势？

1、都是Trustin Lee的作品，Netty更晚；

2、Mina将内核和一些特性的联系过于紧密，使得用户在不需要这些特性的时候无法脱离，相比下性能会有所下降，Netty解决了这个设计问题；

3、Netty的文档更清晰，很多Mina的特性在Netty里都有；

4、Netty更新周期更短，新版本的发布比较快；

5、它们的架构差别不大，Mina靠apache生存，而Netty靠jboss，和jboss的结合度非常高，Netty有对google protocal buf的支持，有更完整的ioc容器支持(spring,guice,jbossmc和osgi)；

6、Netty比Mina使用起来更简单，Netty里你可以自定义的处理upstream events或/和downstream events，可以使用decoder和encoder来解码和编码发送内容；

7、Netty和Mina在处理UDP时有一些不同，Netty将UDP无连接的特性暴露出来；而Mina对UDP进行了高级层次的抽象，可以把UDP当成"面向连接"的协议，而要Netty做到这一点比较困难。

5. 架构

概况来讲，基于 MINA 的应用划分为三个层次：

I/O Service (I/O 服务) - 具体 I/O 操作
I/O Filter Chain (I/O 过滤器链) - 将字节过滤/转换为想要的数据结构。反之亦然
I/O Handler (I/O 处理器) - 这里实现实际的业务逻辑