最近项目中用到了 Netty，遇到了不少问题，所以写篇文章做个总结：
先来放段代码：
public static void main(String[] args) throws InterruptedException {
EventLoopGroup parentGroup = new NioEventLoopGroup(new DefaultThreadFactory("boss"));
EventLoopGroup childGroup = new NioEventLoopGroup(new DefaultThreadFactory("worker"));
EventLoopGroup business = new NioEventLoopGroup(new DefaultThreadFactory("business"));
try{
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(parentGroup,childGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG,1024)
.childOption(ChannelOption.TCP_NODELAY,true)
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(new StringDecoder());
pipeline.addLast(new StringEncoder());
pipeline.addLast(new msgInHandler());
pipeline.addLast(new msgOutHandler());
}
});
ChannelFuture future = bootstrap.bind(8888).sync();
future.channel().closeFuture().sync();
}finally {
parentGroup.shutdownGracefully();
childGroup.shutdownGracefully();
}
}
这是 Netty server 的通用写法，下面我们来分析一下，每行代码都做了哪些事情。
NIO
Netty 是一款基于 NIO 开发的网络通信框架，对比于 BIO，他的并发性能得到了很大提高，那到底 NIO 比 BIO 厉害在哪呢？
让我们先看一下传统的服务器端同步阻塞 I/O 处理（也就是 BIO，Blocking I/O）的经典编程模型：
public class SomeServer {
public static void main(String[] args) throws IOException {
int port=8080;
if(args !=null && args.length >0){
port=Integer.valueOf(args[0]);
}
ServerSocket server=null;
try{
server= new ServerSocket(port);
System.out.println("The server is start in port: "+port);
Socket socket=null;
while(true){
//当没有客户端连接时，程序会阻塞在accept这里，当有客户端访问时，就会创建新的线程去重新执行。
socket=server.accept();
//每有一个客户端访问，就添加一个线程执行
new Thread(new SomeServerHandler(socket)).start();
}
}finally{
if(server !=null){
System.out.println("The server close");
server.close();
server=null;
}
}
}
}
如上面代码，每当有一个连接过来的时候，程序必须创建一个线程去处理，否则 CPU 就会阻塞。在活动连接数不是特别高的情况下，这种模型是比较不错的，当面对百万万甚至千万级连接的时候，传统的 BIO 模型就无能为力了。
下面我们来介绍一下 Netty 的 NIO 模型 Reactor：
单线程 Reator 模型：
Reactor 单线程模型，一个线程干了全套的事儿，所有的 IO 操作都在同一个 NIO 线程上面完成。
作为 NIO 服务端，接收客户端的 TCP 连接，作为 NIO 客户端，向服务端发起 TCP 连接，读取通信对端的请求或者应答消息，向通信对端发送消息请求或者应答消息。
这一个线程在连接多的时候会被累死，性能上无法支撑，即便 NIO 线程的 CPU 负荷达到 100%，也无法满足海量消息的编码、解码、读取和发送。所以我们就需要多线程模型。
Reactor 多线程模型
如图所示，Reactor 多线程模型有专门一个 NIO 线程 Acceptor 线程用于监听服务端，接收客户端的 TCP 连接请求，网络 IO 操作-读、写等由一个 NIO 线程池负责，这些 NIO 线程负责消息的读取、解码、编码和发送。
分工明确，不同线程组干不同的事儿，线程也不阻塞。
我们再来看下面代码就清晰了。
EventLoopGroup parentGroup = new NioEventLoopGroup(new DefaultThreadFactory("boss"));
EventLoopGroup childGroup = new NioEventLoopGroup(new DefaultThreadFactory("worker"));
EventLoopGroup business = new NioEventLoopGroup(new DefaultThreadFactory("business"));
每一行代码建立不同的线程组，“boss” 接收 TCP 的连接操作，“worker” 用在进行 I/O 读写，“business” 用来处理耗时、复杂的业务逻辑（编解码等）。
理解了上面的内容，下面的代码也就不难理解了。
try{
ServerBootstrap bootstrap = new ServerBootstrap();
bootstrap.group(parentGroup,childGroup)
.channel(NioServerSocketChannel.class)
.option(ChannelOption.SO_BACKLOG,1024)
.childOption(ChannelOption.TCP_NODELAY,true)
bootstrap.group(parentGroup,childGroup) 就是绑定主线程和从线程，用于 Acceptor 的主"线程池"以及用于 I/O 工作的从"线程池"。
指定通道 channel 的类型，由于是服务端，故而是 NioServerSocketChannel；
设置 ServerSocketChannel 参数，SO_BACKLOG 服务端接受连接的队列长度，如果队列已满，客户端连接将被拒绝，长度 1024。
设置 ChildChannel 参数，如果 TCP_NODELAY 不设置为 true, 底层的 TCP 为了能减少交互次数,会将网络数据积累到一定的数量后,服务器端才发送出去,会造成一定的延迟。如果服务是低延迟的,要将 TCP_NODELAY 设置为 true。
pipline 事件传播机制
下面代码是设置 SocketChannel 的处理器，将每个 handler 从尾端放入 pipline 中。
.childHandler(new ChannelInitializer<SocketChannel>() {
@Override
protected void initChannel(SocketChannel ch) throws Exception {
ChannelPipeline pipeline = ch.pipeline();
pipeline.addLast(new StringDecoder());
pipeline.addLast(new StringEncoder());
pipeline.addLast(new msgInHandler());
pipeline.addLast(new msgOutHandler());
}
});
每个 handler 是实现了 ChannelHandler 的两个子接口 ChannelInboundHandler 和 ChannelOutboundHandler，一个用来处理接收到的消息，一个用来处理发出的消息。
到这里，就发现会有个问题，InboundHandler 可以和 OutboundHandler 混在一起放在 pipline 中，如果 pipline 是顺序执行的，那么收发消息进入 handler 中处理岂不是乱套了？
其实不然，这就涉及到 pipline 的事件传播机制了，先来看两张图：
虽然 pipline.addLast 方法是顺序将 handler 加入到 pipline 中，但是并不影响 Inbound 和 Outbound 的执行
inbound 事件与 outbound 事件传播机制实现原理相同，只是方向不同，inbound 事件的传播从 HeadContext 开始，沿着 next 指针进行传播，而 outbound 事件传播从 TailContext 开始，沿着 prev 指针向前传播。
源码中
InboundHandler之间传递数据，通过ctx.fireChannelRead(msg)
AbstractChannelHandlerContext#fireChannelRead
public ChannelHandlerContext fireChannelRead(final Object msg) {
invokeChannelRead(findContextInbound(), msg);
return this;
}
private AbstractChannelHandlerContext findContextInbound() {
AbstractChannelHandlerContext ctx = this;
do {
ctx = ctx.next;
} while (!ctx.inbound);
return ctx;
}
上述就从事件链中按顺序提取 inbound 类型的处理器.
OutboundHandler 之间传递数据，通过 ctx.write(msg, promise);
AbstractChannelHandlerContext#write
private void write(Object msg, boolean flush, ChannelPromise promise) {
ObjectUtil.checkNotNull(msg, "msg");
try {
if (isNotValidPromise(promise, true)) {
ReferenceCountUtil.release(msg);
// cancelled
return;
}
} catch (RuntimeException e) {
ReferenceCountUtil.release(msg);
throw e;
}
final AbstractChannelHandlerContext next = findContextOutbound(flush ?
(MASK_WRITE | MASK_FLUSH) : MASK_WRITE);
final Object m = pipeline.touch(msg, next);
EventExecutor executor = next.executor();
if (executor.inEventLoop()) {
if (flush) {
next.invokeWriteAndFlush(m, promise);
} else {
next.invokeWrite(m, promise);
}
} else {
final WriteTask task = WriteTask.newInstance(next, m, promise, flush);
if (!safeExecute(executor, task, promise, m, !flush)) {
task.cancel();
}
}
}
端口绑定，建立连接
下面代码就比较好理解了
ChannelFuture future = bootstrap.bind(8888).sync();
future.channel().closeFuture().sync();
第一行是绑定端口并建立连接，因为建立连接是阻塞的，所以要异步操作加上 .sync()
第二行通过 ChannelFuture 可以获取到Channel，从而利用 Channel 在通道上进行读、写、关闭等操作；
Netty 优雅退出
}finally {
parentGroup.shutdownGracefully();
childGroup.shutdownGracefully();
}
Netty 的优雅关闭，主要涉及一下几个操作：
把 NIO 线程的状态位设置成 ST_SHUTTING_DOWN 状态，不再处理新的消息（不允许再对外发送消息）；
退出前的预处理操作：把发送队列中尚未发送或者正在发送的消息发送完、把已经到期或者在退出超时之前到期的定时任务执行完成、把用户注册到 NIO 线程的退出 Hook 任务执行完成；
资源的释放操作：所有 Channel 的释放、多路复用器的去注册和关闭、所有队列和定时任务的清空取消，最后是 NIO 线程的退出。
最后
致此一个完整的 Netty 服务端代码已经分析完成了，Netty 框架非常之强大且复杂，以后有机会可以展开更加深入的探讨 Netty 的源码和框架涉及原理。
