分类：
感谢支付宝同事[易鸿伟]在本站发布此文。java
这博文的系列主要是为了更好的了解一个完整的nio框架的编程细节以及演进过程，我选了同父（Trustin Lee）的两个框架netty与mina作对比。版本涉及了netty3.x、netty4.x、mina1.x、mina2.x、mina3.x。这里 并无写netty5.x的细节，看了netty5的修改文档，彷佛有一些比较有意思的改动，准备单独写一篇netty4.x与netty5.x的不一样。
react
netty从twitter发布的这篇《Netty 4 at Twitter: Reduced GC Overhead》 文章让国内Java界为之一振，也小火了一把，同时netty的社区发展也不错，版本迭代很是快，半年不关注大、小版本就发了好几轮了。可是mina就有 点淡了，github上面它最后大多数代码最后的修改日期均在2013年，不过我从我的情感上仍是挺喜欢mina3的代码，没有太多的用不上的功能（支持 各类协议啥的），跑自带的benchmark性能也比netty4好一些。可是若是是生产用的话，就偏向netty多一些了，毕竟社区活跃，版本迭代也 快。git
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中只靠内核调度，没有任何通讯且互不打扰。github
在我本身的博客里面[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大小等。
以上图片及总结参考：《Linux多线程服务端编程》网络
2. mina、netty的任务调度粒度
mina、netty在线程模型上并无太大的差别性，主要的差别仍是在任务调度的粒度的不一样。任务从逻辑上我给它分为成三种类型：链接相关的任务 （bind、connect等）、写任务（write、flush）、调度任务（延迟、定时等），读任务则由selector加循环时间控制了。 mina、netty任务调度的趋势是逐渐变小，从session级别的调度 -> 类型级别任务的调度 -> 任务的调度。session
代码
- mina-1.1.7: SocketIoProcessor$Worker.run
- mina-2.0.4: AbstractPollingIoProcessor$Processor.run
- mina-3.0.0.M3-SNAPSHOT: AbstractNioSession.processWrite
- netty-3.5.8.Final: AbstractNioSelector.run
- netty-4.0.6.Final: NioEventLoop.run
分析
mina一、2的任务调度粒度为session。mina会将有IO任务的的session写入队列中，当循环执行任务时，则会轮询全部的session，并依次把session中的全部任务取出来运行。这样粗粒度的调度是不公平调度，会致使某些请求的延迟很高。多线程
mina3的模型改动比较大，代码相对就比较难看了，我仅是随便扫了一下，它仅提炼出了writeQueue。框架
而netty3的调度粒度则是按照IO操做，分红了registerTaskQueue、writeTaskQueue、eventQueue三个队列， 当有IO任务时，依次processRegisterTaskQueue、processEventQueue、 processWriteTaskQueue、processSelectedKeys(selector.selectedKeys)。
netty4可能以为netty3的粒度仍是比较粗，将队列细分红了taskQueue和delayedTaskQueue，全部的任务均放在 taskQueue中，delayedTaskQueue则是定时调度任务，且netty4能够灵活配置task与selectedKey处理的时间比 例。
BTW: netty3.6.0以后，全部的队列均合并成了一个taskQueue
有意思的是，netty4会优先处理selectedKeys，而后再处理任务，netty3则相反。mina一、2则是先处理新建的session，再处理selectedKeys，再处理任务。
难道selectedKeys处理顺序有讲究么？
（全文完）若是您喜欢此文请点赞，分享，评论。