时间回到十几年前，那时主流的cpu都还是单核（除了商用高性能的小机），cpu的核心频率是机器最重要的指标之一。
在java领域当时比较流行的是单线程编程，对于cpu密集型的应用程序而言，频繁的通过多线程进行协作和抢占时间片反而会降低性能。
随着硬件性能的提升，cpu的核数越来越越多，很多服务器标配已经达到32或64核。通过多线程并发编程，可以充分利用多核cpu的处理能力，提升系统的处理效率和并发性能。
从2005年开始，随着多核处理器的逐步普及，java的多线程并发编程也逐渐流行起来，当时商用主流的jdk版本是1.4，用户可以通过 new thread（）的方式创建新的线程。
由于jdk1.4并没有提供类似线程池这样的线程管理容器，多线程之间的同步、协作、创建和销毁等工作都需要用户自己实现。由于创建和销毁线程是个相对比较重量级的操作，因此，这种原始的多线程编程效率和性能都不高。
为了提升java多线程编程的效率和性能，降低用户开发难度。jdk1.5推出了java.util.concurrent并发编程包。在并发编程类库中，提供了线程池、线程安全容器、原子类等新的类库，极大的提升了java多线程编程的效率，降低了开发难度。
从jdk1.5开始，基于线程池的并发编程已经成为java多核编程的主流。
无论是c++还是java编写的网络框架，大多数都是基于reactor模式进行设计和开发，reactor模式基于事件驱动，特别适合处理海量的i/o事件。
reactor单线程模型，指的是所有的io操作都在同一个nio线程上面完成，nio线程的职责如下：
1）作为nio服务端，接收客户端的tcp连接；
2）作为nio客户端，向服务端发起tcp连接；
3）读取通信对端的请求或者应答消息；
4）向通信对端发送消息请求或者应答消息。
reactor单线程模型示意图如下所示：
图1-1 reactor单线程模型
由于reactor模式使用的是异步非阻塞io，所有的io操作都不会导致阻塞，理论上一个线程可以独立处理所有io相关的操作。从架构层面看，一个nio线程确实可以完成其承担的职责。例如，通过acceptor类接收客户端的tcp连接请求消息，链路建立成功之后，通过dispatch将对应的bytebuffer派发到指定的handler上进行消息解码。用户线程可以通过消息编码通过nio线程将消息发送给客户端。
对于一些小容量应用场景，可以使用单线程模型。但是对于高负载、大并发的应用场景却不合适，主要原因如下：
1）一个nio线程同时处理成百上千的链路，性能上无法支撑，即便nio线程的cpu负荷达到100%，也无法满足海量消息的编码、解码、读取和发送；
2）当nio线程负载过重之后，处理速度将变慢，这会导致大量客户端连接超时，超时之后往往会进行重发，这更加重了nio线程的负载，最终会导致大量消息积压和处理超时，成为系统的性能瓶颈；
3）可靠性问题：一旦nio线程意外跑飞，或者进入死循环，会导致整个系统通信模块不可用，不能接收和处理外部消息，造成节点故障。
为了解决这些问题，演进出了reactor多线程模型，下面我们一起学习下reactor多线程模型。
rector多线程模型与单线程模型最大的区别就是有一组nio线程处理io操作，它的原理图如下：
图1-2 reactor多线程模型
reactor多线程模型的特点：
1）有专门一个nio线程-acceptor线程用于监听服务端，接收客户端的tcp连接请求；
2）网络io操作-读、写等由一个nio线程池负责，线程池可以采用标准的jdk线程池实现，它包含一个任务队列和n个可用的线程，由这些nio线程负责消息的读取、解码、编码和发送；
3）1个nio线程可以同时处理n条链路，但是1个链路只对应1个nio线程，防止发生并发操作问题。
在绝大多数场景下，reactor多线程模型都可以满足性能需求；但是，在极个别特殊场景中，一个nio线程负责监听和处理所有的客户端连接可能会存在性能问题。例如并发百万客户端连接，或者服务端需要对客户端握手进行安全认证，但是认证本身非常损耗性能。在这类场景下，单独一个acceptor线程可能会存在性能不足问题，为了解决性能问题，产生了第三种reactor线程模型-主从reactor多线程模型。
主从reactor线程模型的特点是：服务端用于接收客户端连接的不再是个1个单独的nio线程，而是一个独立的nio线程池。acceptor接收到客户端tcp连接请求处理完成后（可能包含接入认证等），将新创建的socketchannel注册到io线程池（sub
reactor线程池）的某个io线程上，由它负责socketchannel的读写和编解码工作。acceptor线程池仅仅只用于客户端的登陆、握手和安全认证，一旦链路建立成功，就将链路注册到后端subreactor线程池的io线程上，由io线程负责后续的io操作。
它的线程模型如下图所示：
图1-3 主从reactor多线程模型
利用主从nio线程模型，可以解决1个服务端监听线程无法有效处理所有客户端连接的性能不足问题。
它的工作流程总结如下：
从主线程池中随机选择一个reactor线程作为acceptor线程，用于绑定监听端口，接收客户端连接；
acceptor线程接收客户端连接请求之后创建新的socketchannel，将其注册到主线程池的其它reactor线程上，由其负责接入认证、ip黑白名单过滤、握手等操作；
步骤2完成之后，业务层的链路正式建立，将socketchannel从主线程池的reactor线程的多路复用器上摘除，重新注册到sub线程池的线程上，用于处理i/o的读写操作。
事实上，netty的线程模型与1.2章节中介绍的三种reactor线程模型相似，下面章节我们通过netty服务端和客户端的线程处理流程图来介绍netty的线程模型。
一种比较流行的做法是服务端监听线程和io线程分离，类似于reactor的多线程模型，它的工作原理图如下：
图2-1 netty服务端线程工作流程
下面我们结合netty的源码，对服务端创建线程工作流程进行介绍：
第一步，从用户线程发起创建服务端操作，代码如下：
图2-2 用户线程创建服务端代码示例
通常情况下，服务端的创建是在用户进程启动的时候进行，因此一般由main函数或者启动类负责创建，服务端的创建由业务线程负责完成。在创建服务端的时候实例化了2个eventloopgroup，1个eventloopgroup实际就是一个eventloop线程组，负责管理eventloop的申请和释放。
eventloopgroup管理的线程数可以通过构造函数设置，如果没有设置，默认取-dio.netty.eventloopthreads，如果该系统参数也没有指定，则为可用的cpu内核数 × 2。
bossgroup线程组实际就是acceptor线程池，负责处理客户端的tcp连接请求，如果系统只有一个服务端端口需要监听，则建议bossgroup线程组线程数设置为1。
workergroup是真正负责i/o读写操作的线程组，通过serverbootstrap的group方法进行设置，用于后续的channel绑定。
第二步，acceptor线程绑定监听端口，启动nio服务端，相关代码如下：
图2-3 从bossgroup中选择一个acceptor线程监听服务端
其中，group()返回的就是bossgroup，它的next方法用于从线程组中获取可用线程，代码如下：
图2-4 选择acceptor线程
服务端channel创建完成之后，将其注册到多路复用器selector上，用于接收客户端的tcp连接，核心代码如下：
图2-5 注册serversocketchannel 到selector
第三步，如果监听到客户端连接，则创建客户端socketchannel连接，重新注册到workergroup的io线程上。首先看acceptor如何处理客户端的接入：
图2-6 处理读或者连接事件
调用unsafe的read（）方法，对于nioserversocketchannel，它调用了niomessageunsafe的read()方法，代码如下：
图2-7 nioserversocketchannel的read()方法
最终它会调用nioserversocketchannel的doreadmessages方法，代码如下：
图2-8 创建客户端连接socketchannel
其中childeventloopgroup就是之前的workergroup, 从中选择一个i/o线程负责网络消息的读写。
第四步，选择io线程之后，将socketchannel注册到多路复用器上，监听read操作。
图2-9 监听网络读事件
第五步，处理网络的i/o读写事件，核心代码如下：
图2-10 处理读写事件
相比于服务端，客户端的线程模型简单一些，它的工作原理如下：
图2-11 netty客户端线程模型
第一步，由用户线程发起客户端连接，示例代码如下：
图2-12 netty客户端创建代码示例
大家发现相比于服务端，客户端只需要创建一个eventloopgroup，因为它不需要独立的线程去监听客户端连接，也没必要通过一个单独的客户端线程去连接服务端。netty是异步事件驱动的nio框架，它的连接和所有io操作都是异步的，因此不需要创建单独的连接线程。相关代码如下：
图2-13 绑定客户端连接线程
当前的group（）就是之前传入的eventloopgroup，从中获取可用的io线程eventloop，然后作为参数设置到新创建的niosocketchannel中。
第二步，发起连接操作，判断连接结果，代码如下：
图2-14 连接操作
判断连接结果，如果没有连接成功，则监听连接网络操作位selectionkey.op_connect。如果连接成功，则调用pipeline().firechannelactive()将监听位修改为read。
第三步，由nioeventloop的多路复用器轮询连接操作结果，代码如下：
图2-15 selector发起轮询操作
判断连接结果，如果或连接成功，重新设置监听位为read：
图2-16 判断连接操作结果
图2-17 设置操作位为read
第四步，由nioeventloop线程负责i/o读写，同服务端。
总结：客户端创建，线程模型如下：
由用户线程负责初始化客户端资源，发起连接操作；
如果连接成功，将socketchannel注册到io线程组的nioeventloop线程中，监听读操作位；
如果没有立即连接成功，将socketchannel注册到io线程组的nioeventloop线程中，监听连接操作位；
连接成功之后，修改监听位为read，但是不需要切换线程。
nioeventloop是netty的reactor线程，它的职责如下：
作为服务端acceptor线程，负责处理客户端的请求接入；
作为客户端connecor线程，负责注册监听连接操作位，用于判断异步连接结果；
作为io线程，监听网络读操作位，负责从socketchannel中读取报文；
作为io线程，负责向socketchannel写入报文发送给对方，如果发生写半包，会自动注册监听写事件，用于后续继续发送半包数据，直到数据全部发送完成；
作为定时任务线程，可以执行定时任务，例如链路空闲检测和发送心跳消息等；
作为线程执行器可以执行普通的任务线程（runnable）。
在服务端和客户端线程模型章节我们已经详细介绍了nioeventloop如何处理网络io事件，下面我们简单看下它是如何处理定时任务和执行普通的runnable的。
首先nioeventloop继承singlethreadeventexecutor，这就意味着它实际上是一个线程个数为1的线程池，类继承关系如下所示：
图2-18 nioeventloop继承关系
图2-19 线程池和任务队列定义
对于用户而言，直接调用nioeventloop的execute(runnable task)方法即可执行自定义的task，代码实现如下：
图2-20 执行用户自定义task
图2-21 nioeventloop实现scheduledexecutorservice
通过调用singlethreadeventexecutor的schedule系列方法，可以在nioeventloop中执行netty或者用户自定义的定时任务，接口定义如下：
图2-22 nioeventloop的定时任务执行接口定义
我们知道当系统在运行过程中，如果频繁的进行线程上下文切换，会带来额外的性能损耗。多线程并发执行某个业务流程，业务开发者还需要时刻对线程安全保持警惕，哪些数据可能会被并发修改，如何保护？这不仅降低了开发效率，也会带来额外的性能损耗。
串行执行handler链
为了解决上述问题，netty采用了串行化设计理念，从消息的读取、编码以及后续handler的执行，始终都由io线程nioeventloop负责，这就意外着整个流程不会进行线程上下文的切换，数据也不会面临被并发修改的风险，对于用户而言，甚至不需要了解netty的线程细节，这确实是个非常好的设计理念，它的工作原理图如下：
图2-23 nioeventloop串行执行channelhandler
一个nioeventloop聚合了一个多路复用器selector，因此可以处理成百上千的客户端连接，netty的处理策略是每当有一个新的客户端接入，则从nioeventloop线程组中顺序获取一个可用的nioeventloop，当到达数组上限之后，重新返回到0，通过这种方式，可以基本保证各个nioeventloop的负载均衡。一个客户端连接只注册到一个nioeventloop上，这样就避免了多个io线程去并发操作它。
netty通过串行化设计理念降低了用户的开发难度，提升了处理性能。利用线程组实现了多个串行化线程水平并行执行，线程之间并没有交集，这样既可以充分利用多核提升并行处理能力，同时避免了线程上下文的切换和并发保护带来的额外性能损耗。
在netty中，有很多功能依赖定时任务，比较典型的有两种：
客户端连接超时控制；
链路空闲检测。
一种比较常用的设计理念是在nioeventloop中聚合jdk的定时任务线程池scheduledexecutorservice，通过它来执行定时任务。这样做单纯从性能角度看不是最优，原因有如下三点：
在io线程中聚合了一个独立的定时任务线程池，这样在处理过程中会存在线程上下文切换问题，这就打破了netty的串行化设计理念；
存在多线程并发操作问题，因为定时任务task和io线程nioeventloop可能同时访问并修改同一份数据；
jdk的scheduledexecutorservice从性能角度看，存在性能优化空间。
最早面临上述问题的是操作系统和协议栈，例如tcp协议栈，其可靠传输依赖超时重传机制，因此每个通过tcp传输的
packet 都需要一个 timer来调度 timeout
事件。这类超时可能是海量的，如果为每个超时都创建一个定时器，从性能和资源消耗角度看都是不合理的。
根据george
varghese和tony lauck 1996年的论文《hashed and hierarchical timing wheels:
data structures to efficiently implement a timer
facility》提出了一种定时轮的方式来管理和维护大量的timer调度。netty的定时任务调度就是基于时间轮算法调度，下面我们一起来看下netty的实现。
定时轮是一种数据结构，其主体是一个循环列表，每个列表中包含一个称之为slot的结构，它的原理图如下：
图2-24 时间轮工作原理
定时轮的工作原理可以类比于时钟，如上图箭头（指针）按某一个方向按固定频率轮动，每一次跳动称为一个tick。这样可以看出定时轮由个3个重要的属性参数：ticksperwheel（一轮的tick数），tickduration（一个tick的持续时间）以及
timeunit（时间单位），例如当ticksperwheel=60，tickduration=1，timeunit=秒，这就和时钟的秒针走动完全类似了。
下面我们具体分析下netty的实现：时间轮的执行由nioeventloop来复杂检测，首先看任务队列中是否有超时的定时任务和普通任务，如果有则按照比例循环执行这些任务，代码如下：
图2-25 执行任务队列
如果没有需要理解执行的任务，则调用selector的select方法进行等待，等待的时间为定时任务队列中第一个超时的定时任务时延，代码如下：
图2-26 计算时延
从定时任务task队列中弹出delay最小的task，计算超时时间，代码如下：
图2-27 从定时任务队列中获取超时时间
定时任务的执行：经过周期tick之后，扫描定时任务列表，将超时的定时任务移除到普通任务队列中，等待执行，相关代码如下：
图2-28 检测超时的定时任务
检测和拷贝任务完成之后，就执行超时的定时任务，代码如下：
图2-29 执行定时任务
为了保证定时任务的执行不会因为过度挤占io事件的处理，netty提供了io执行比例供用户设置，用户可以设置分配给io的执行比例，防止因为海量定时任务的执行导致io处理超时或者积压。
因为获取系统的纳秒时间是件耗时的操作，所以netty每执行64个定时任务检测一次是否达到执行的上限时间，达到则退出。如果没有执行完，放到下次selector轮询时再处理，给io事件的处理提供机会，代码如下：
图2-30 执行时间上限检测
netty是个异步高性能的nio框架，它并不是个业务运行容器，因此它不需要也不应该提供业务容器和业务线程。合理的设计模式是netty只负责提供和管理nio线程，其它的业务层线程模型由用户自己集成，netty不应该提供此类功能，只要将分层划分清楚，就会更有利于用户集成和扩展。
令人遗憾的是在netty 3系列版本中，netty提供了类似mina异步filter的executionhandler，它聚合了jdk的线程池java.util.concurrent.executor，用户异步执行后续的handler。
executionhandler是为了解决部分用户handler可能存在执行时间不确定而导致io线程被意外阻塞或者挂住，从需求合理性角度分析这类需求本身是合理的，但是netty提供该功能却并不合适。原因总结如下：
1. 它打破了netty坚持的串行化设计理念，在消息的接收和处理过程中发生了线程切换并引入新的线程池，打破了自身架构坚守的设计原则，实际是一种架构妥协；
2. 潜在的线程并发安全问题，如果异步handler也操作它前面的用户handler，而用户handler又没有进行线程安全保护，这就会导致隐蔽和致命的线程安全问题；
3. 用户开发的复杂性，引入executionhandler，打破了原来的channelpipeline串行执行模式，用户需要理解netty底层的实现细节，关心线程安全等问题，这会导致得不偿失。
鉴于上述原因，netty的后续版本彻底删除了executionhandler，而且也没有提供类似的相关功能类，把精力聚焦在netty的io线程nioeventloop上，这无疑是一种巨大的进步，netty重新开始聚焦在io线程本身，而不是提供用户相关的业务线程模型。
如果业务非常简单，执行时间非常短，不需要与外部网元交互、访问数据库和磁盘，不需要等待其它资源，则建议直接在业务channelhandler中执行，不需要再启业务的线程或者线程池。避免线程上下文切换，也不存在线程并发问题。
对于此类业务，不建议直接在业务channelhandler中启动线程或者线程池处理，建议将不同的业务统一封装成task，统一投递到后端的业务线程池中进行处理。
过多的业务channelhandler会带来开发效率和可维护性问题，不要把netty当作业务容器，对于大多数复杂的业务产品，仍然需要集成或者开发自己的业务容器，做好和netty的架构分层。
对于channelhandler，io线程和业务线程都可能会操作，因为业务通常是多线程模型，这样就会存在多线程操作channelhandler。为了尽量避免多线程并发问题，建议按照netty自身的做法，通过将操作封装成独立的task由nioeventloop统一执行，而不是业务线程直接操作，相关代码如下所示：
图2-31 封装成task防止多线程并发操作
如果你确认并发访问的数据或者并发操作是安全的，则无需多此一举，这个需要根据具体的业务场景进行判断，灵活处理。
尽管netty的线程模型并不复杂，但是如何合理利用netty开发出高性能、高并发的业务产品，仍然是个有挑战的工作。只有充分理解了netty的线程模型和设计原理，才能开发出高质量的产品。
目前市面上介绍netty的文章很多，如果读者希望系统性的学习netty，推荐两本书：
1) 《netty in action》，建议阅读英文原版。
2) 《netty权威指南》，建议通过理论联系实际方式学习。
李林锋，2007年毕业于东北大学，2008年进入华为公司从事高性能通信软件的设计和开发工作，有6年nio设计和开发经验，精通netty、mina等nio框架,netty中国社区创始人和netty框架推广者。
原文链接:[http://wely.iteye.com/blog/2360395]