最近項目中用到了 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 開發(fā)的網(wǎng)絡通信框架步绸，對比于 BIO，他的并發(fā)性能得到了很大提高吃媒，那到底 NIO 比 BIO 厲害在哪呢瓤介？
讓我們先看一下傳統(tǒng)的服務器端同步阻塞 I/O 處理（也就是 BIO，Blocking I/O）的經(jīng)典編程模型：
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這里惑朦，當有客戶端訪問時，就會創(chuàng)建新的線程去重新執(zhí)行漓概。
socket=server.accept();
//每有一個客戶端訪問漾月，就添加一個線程執(zhí)行
new Thread(new SomeServerHandler(socket)).start();
}
}finally{
if(server !=null){
System.out.println("The server close");
server.close();
server=null;
}
}
}
}
如上面代碼，每當有一個連接過來的時候胃珍，程序必須創(chuàng)建一個線程去處理梁肿，否則 CPU 就會阻塞蜓陌。在活動連接數(shù)不是特別高的情況下，這種模型是比較不錯的吩蔑，當面對百萬萬甚至千萬級連接的時候钮热，傳統(tǒng)的 BIO 模型就無能為力了。
下面我們來介紹一下 Netty 的 NIO 模型 Reactor：
單線程 Reator 模型：
Reactor 單線程模型烛芬，一個線程干了全套的事兒隧期，所有的 IO 操作都在同一個 NIO 線程上面完成。
作為 NIO 服務端赘娄，接收客戶端的 TCP 連接仆潮，作為 NIO 客戶端，向服務端發(fā)起 TCP 連接遣臼，讀取通信對端的請求或者應答消息性置，向通信對端發(fā)送消息請求或者應答消息。
這一個線程在連接多的時候會被累死揍堰，性能上無法支撐鹏浅，即便 NIO 線程的 CPU 負荷達到 100%，也無法滿足海量消息的編碼屏歹、解碼隐砸、讀取和發(fā)送。所以我們就需要多線程模型蝙眶。
Reactor 多線程模型
如圖所示季希，Reactor 多線程模型有專門一個 NIO 線程 Acceptor 線程用于監(jiān)聽服務端，接收客戶端的 TCP 連接請求械馆，網(wǎng)絡 IO 操作-讀胖眷、寫等由一個 NIO 線程池負責，這些 NIO 線程負責消息的讀取霹崎、解碼珊搀、編碼和發(fā)送。
分工明確尾菇，不同線程組干不同的事兒境析，線程也不阻塞。
我們再來看下面代碼就清晰了派诬。
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” 用來處理耗時沛鸵、復雜的業(yè)務邏輯（編解碼等）。
理解了上面的內(nèi)容，下面的代碼也就不難理解了曲掰。
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 參數(shù)吊趾，SO_BACKLOG 服務端接受連接的隊列長度宛裕，如果隊列已滿，客戶端連接將被拒絕论泛，長度 1024揩尸。
設置 ChildChannel 參數(shù)，如果 TCP_NODELAY 不設置為 true, 底層的 TCP 為了能減少交互次數(shù),會將網(wǎng)絡數(shù)據(jù)積累到一定的數(shù)量后,服務器端才發(fā)送出去,會造成一定的延遲孵奶。如果服務是低延遲的,要將 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 是實現(xiàn)了 ChannelHandler 的兩個子接口 ChannelInboundHandler 和 ChannelOutboundHandler，一個用來處理接收到的消息湿颅，一個用來處理發(fā)出的消息载绿。
到這里，就發(fā)現(xiàn)會有個問題油航，InboundHandler 可以和 OutboundHandler 混在一起放在 pipline 中崭庸，如果 pipline 是順序執(zhí)行的，那么收發(fā)消息進入 handler 中處理豈不是亂套了谊囚？
其實不然怕享，這就涉及到 pipline 的事件傳播機制了，先來看兩張圖：
雖然 pipline.addLast 方法是順序將 handler 加入到 pipline 中镰踏，但是并不影響 Inbound 和 Outbound 的執(zhí)行
inbound 事件與 outbound 事件傳播機制實現(xiàn)原理相同函筋，只是方向不同，inbound 事件的傳播從 HeadContext 開始奠伪，沿著 next 指針進行傳播跌帐，而 outbound 事件傳播從 TailContext 開始，沿著 prev 指針向前傳播绊率。
源碼中
InboundHandler之間傳遞數(shù)據(jù)谨敛，通過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 之間傳遞數(shù)據(jù)，通過 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 優(yōu)雅退出
}finally {
parentGroup.shutdownGracefully();
childGroup.shutdownGracefully();
}
Netty 的優(yōu)雅關閉蜜葱，主要涉及一下幾個操作：
把 NIO 線程的狀態(tài)位設置成 ST_SHUTTING_DOWN 狀態(tài)全景，不再處理新的消息（不允許再對外發(fā)送消息）；
退出前的預處理操作：把發(fā)送隊列中尚未發(fā)送或者正在發(fā)送的消息發(fā)送完牵囤、把已經(jīng)到期或者在退出超時之前到期的定時任務執(zhí)行完成爸黄、把用戶注冊到 NIO 線程的退出 Hook 任務執(zhí)行完成；
資源的釋放操作：所有 Channel 的釋放揭鳞、多路復用器的去注冊和關閉炕贵、所有隊列和定時任務的清空取消，最后是 NIO 線程的退出野崇。
最后
致此一個完整的 Netty 服務端代碼已經(jīng)分析完成了称开，Netty 框架非常之強大且復雜，以后有機會可以展開更加深入的探討 Netty 的源碼和框架涉及原理乓梨。
