from：http://www.infoq.com/cn/articles/netty-version-upgrade-history-thread-part
1. 背景
1.1. Netty 3.X系列版本現(xiàn)狀
根據(jù)對Netty社區(qū)部分用戶的調查，結合Netty在其它開源項目中的使用情況，我們可以看出目前Netty商用的主流版本集中在3.X和4.X上，其中以Netty 3.X系列版本使用最為廣泛。
Netty社區(qū)非常活躍，3.X系列版本從2011年2月7日發(fā)布的netty-3.2.4 Final版本到2014年12月17日發(fā)布的netty-3.10.0 Final版本，版本跨度達3年多，期間共推出了61個Final版本。
1.2. 升級還是堅守老版本
相比于其它開源項目，Netty用戶的版本升級之路更加艱辛，最根本的原因就是Netty 4對Netty 3沒有做到很好的前向兼容。
由于版本不兼容，大多數(shù)老版本使用者的想法就是既然升級這么麻煩，我暫時又不需要使用到Netty 4的新特性，當前版本還挺穩(wěn)定，就暫時先不升級，以后看看再說。
堅守老版本還有很多其它的理由，例如考慮到線上系統(tǒng)的穩(wěn)定性、對新版本的熟悉程度等。無論如何升級Netty都是一件大事，特別是對Netty有直接強依賴的產品。
從上面的分析可以看出，堅守老版本似乎是個不錯的選擇；但是，“理想是美好的,現(xiàn)實卻是殘酷的”，堅守老版本并非總是那么容易，下面我們就看下被迫升級的案例。
1.3. “被迫”升級到Netty 4.X
除了為了使用新特性而主動進行的版本升級，大多數(shù)升級都是“被迫的”。下面我們對這些升級原因進行分析。
- 公司的開源軟件管理策略：對于那些大廠，不同部門和產品線依賴的開源軟件版本經(jīng)常不同，為了對開源依賴進行統(tǒng)一管理，降低安全、維護和管理成本，往往會指定優(yōu)選的軟件版本。由于Netty 4.X 系列版本已經(jīng)非常成熟，因為，很多公司都優(yōu)選Netty 4.X版本。
- 維護成本：無論是依賴Netty 3.X，還是Netty4.X，往往需要在原框架之上做定制。例如，客戶端的短連重連、心跳檢測、流控等。分別對Netty 4.X和3.X版本實現(xiàn)兩套定制框架，開發(fā)和維護成本都非常高。根據(jù)開源軟件的使用策略，當存在版本沖突的時候，往往會選擇升級到更高的版本。對于Netty，依然遵循這個規(guī)則。
- 新特性：Netty 4.X相比于Netty 3.X,提供了很多新的特性，例如優(yōu)化的內存管理池、對MQTT協(xié)議的支持等。如果用戶需要使用這些新特性，最簡便的做法就是升級Netty到4.X系列版本。
- 更優(yōu)異的性能：Netty 4.X版本相比于3.X老版本，優(yōu)化了內存池，減少了GC的頻率、降低了內存消耗；通過優(yōu)化Rector線程池模型，用戶的開發(fā)更加簡單，線程調度也更加高效。
1.4. 升級不當付出的代價
表面上看，類庫包路徑的修改、API的重構等似乎是升級的重頭戲，大家往往把注意力放到這些“明槍”上，但真正隱藏和致命的卻是“暗箭”。如果對Netty底層的事件調度機制和線程模型不熟悉，往往就會“中槍”。
本文以幾個比較典型的真實案例為例，通過問題描述、問題定位和問題總結，讓這些隱藏的“暗箭”不再傷人。
由于Netty 4線程模型改變導致的升級事故還有很多，限于篇幅，本文不一一枚舉，這些問題萬變不離其宗，只要抓住線程模型這個關鍵點，所謂的疑難雜癥都將迎刃而解。
2. Netty升級之后遭遇內存泄露
2.1. 問題描述
隨著JVM虛擬機和JIT即時編譯技術的發(fā)展，對象的分配和回收是個非常輕量級的工作。但是對于緩沖區(qū)Buffer，情況卻稍有不同，特別是對于堆外直接內存的分配和回收，是一件耗時的操作。為了盡量重用緩沖區(qū)，Netty4.X提供了基于內存池的緩沖區(qū)重用機制。性能測試表明，采用內存池的ByteBuf相比于朝生夕滅的ByteBuf，性能高23倍左右（性能數(shù)據(jù)與使用場景強相關）。
業(yè)務應用的特點是高并發(fā)、短流程，大多數(shù)對象都是朝生夕滅的短生命周期對象。為了減少內存的拷貝，用戶期望在序列化的時候直接將對象編碼到PooledByteBuf里，這樣就不需要為每個業(yè)務消息都重新申請和釋放內存。
業(yè)務的相關代碼示例如下：
//在業(yè)務線程中初始化內存池分配器，分配非堆內存 ByteBufAllocator allocator = new PooledByteBufAllocator(true); ByteBuf buffer = allocator.ioBuffer(1024); //構造訂購請求消息并賦值，業(yè)務邏輯省略 SubInfoReq infoReq = new SubInfoReq (); infoReq.setXXX(......); //將對象編碼到ByteBuf中 codec.encode(buffer, info); //調用ChannelHandlerContext進行消息發(fā)送 ctx.writeAndFlush(buffer);
業(yè)務代碼升級Netty版本并重構之后，運行一段時間，Java進程就會宕機，查看系統(tǒng)運行日志發(fā)現(xiàn)系統(tǒng)發(fā)生了內存泄露（示例堆棧）：
圖2-1 OOM內存溢出堆棧
對內存進行監(jiān)控（切換使用堆內存池，方便對內存進行監(jiān)控），發(fā)現(xiàn)堆內存一直飆升，如下所示（示例堆內存監(jiān)控）：
圖2-2 堆內存監(jiān)控
2.2. 問題定位
使用jmap -dump:format=b,file=netty.bin PID 將堆內存dump出來，通過IBM的HeapAnalyzer工具進行分析，發(fā)現(xiàn)ByteBuf發(fā)生了泄露。
因為使用了內存池，所以首先懷疑是不是申請的ByteBuf沒有被釋放導致？查看代碼，發(fā)現(xiàn)消息發(fā)送完成之后，Netty底層已經(jīng)調用ReferenceCountUtil.release(message)對內存進行了釋放。這是怎么回事呢？難道Netty 4.X的內存池有Bug，調用release操作釋放內存失敗？
考慮到Netty 內存池自身Bug的可能性不大，首先從業(yè)務的使用方式入手分析：
- 內存的分配是在業(yè)務代碼中進行，由于使用到了業(yè)務線程池做I/O操作和業(yè)務操作的隔離，實際上內存是在業(yè)務線程中分配的；
- 內存的釋放操作是在outbound中進行，按照Netty 3的線程模型，downstream（對應Netty 4的outbound，Netty 4取消了upstream和downstream）的handler也是由業(yè)務調用者線程執(zhí)行的，也就是說釋放跟分配在同一個業(yè)務線程中進行。
初次排查并沒有發(fā)現(xiàn)導致內存泄露的根因，一籌莫展之際開始查看Netty的內存池分配器PooledByteBufAllocator的Doc和源碼實現(xiàn)，發(fā)現(xiàn)內存池實際是基于線程上下文實現(xiàn)的，相關代碼如下：
final ThreadLocal<PoolThreadCache> threadCache = new ThreadLocal<PoolThreadCache>() { private final AtomicInteger index = new AtomicInteger(); @Override protected PoolThreadCache initialValue() { final int idx = index.getAndIncrement(); final PoolArena<byte[]> heapArena; final PoolArena<ByteBuffer> directArena; if (heapArenas != null) { heapArena = heapArenas[Math.abs(idx % heapArenas.length)]; } else { heapArena = null; } if (directArenas != null) { directArena = directArenas[Math.abs(idx % directArenas.length)]; } else { directArena = null; } return new PoolThreadCache(heapArena, directArena); }也就是說內存的申請和釋放必須在同一線程上下文中，不能跨線程。跨線程之后實際操作的就不是同一塊內存區(qū)域，這會導致很多嚴重的問題，內存泄露便是其中之一。內存在A線程申請，切換到B線程釋放，實際是無法正確回收的。
通過對Netty內存池的源碼分析，問題基本鎖定。保險起見進行簡單驗證，通過對單條業(yè)務消息進行Debug，發(fā)現(xiàn)執(zhí)行釋放的果然不是業(yè)務線程，而是Netty的NioEventLoop線程：當某個消息被完全發(fā)送成功之后，會通過ReferenceCountUtil.release(message)方法釋放已經(jīng)發(fā)送成功的ByteBuf。
問題定位出來之后，繼續(xù)溯源，發(fā)現(xiàn)Netty 4修改了Netty 3的線程模型：在Netty 3的時候，upstream是在I/O線程里執(zhí)行的，而downstream是在業(yè)務線程里執(zhí)行。當Netty從網(wǎng)絡讀取一個數(shù)據(jù)報投遞給業(yè)務handler的時候，handler是在I/O線程里執(zhí)行；而當我們在業(yè)務線程中調用write和writeAndFlush向網(wǎng)絡發(fā)送消息的時候,handler是在業(yè)務線程里執(zhí)行，直到最后一個Header handler將消息寫入到發(fā)送隊列中，業(yè)務線程才返回。
Netty4修改了這一模型，在Netty 4里inbound(對應Netty 3的upstream)和outbound(對應Netty 3的downstream)都是在NioEventLoop(I/O線程)中執(zhí)行。當我們在業(yè)務線程里通過ChannelHandlerContext.write發(fā)送消息的時候，Netty 4在將消息發(fā)送事件調度到ChannelPipeline的時候，首先將待發(fā)送的消息封裝成一個Task，然后放到NioEventLoop的任務隊列中，由NioEventLoop線程異步執(zhí)行。后續(xù)所有handler的調度和執(zhí)行，包括消息的發(fā)送、I/O事件的通知，都由NioEventLoop線程負責處理。
下面我們分別通過對比Netty 3和Netty 4的消息接收和發(fā)送流程，來理解兩個版本線程模型的差異：
Netty 3的I/O事件處理流程：
圖2-3 Netty 3 I/O事件處理線程模型
Netty 4的I/O消息處理流程：
圖2-4 Netty 4 I/O事件處理線程模型
2.3. 問題總結
Netty 4.X版本新增的內存池確實非常高效，但是如果使用不當則會導致各種嚴重的問題。諸如內存泄露這類問題，功能測試并沒有異常，如果相關接口沒有進行壓測或者穩(wěn)定性測試而直接上線，則會導致嚴重的線上問題。
內存池PooledByteBuf的使用建議：
- 申請之后一定要記得釋放，Netty自身Socket讀取和發(fā)送的ByteBuf系統(tǒng)會自動釋放，用戶不需要做二次釋放；如果用戶使用Netty的內存池在應用中做ByteBuf的對象池使用，則需要自己主動釋放；
- 避免錯誤的釋放：跨線程釋放、重復釋放等都是非法操作，要避免。特別是跨線程申請和釋放，往往具有隱蔽性，問題定位難度較大；
- 防止隱式的申請和分配：之前曾經(jīng)發(fā)生過一個案例，為了解決內存池跨線程申請和釋放問題，有用戶對內存池做了二次包裝，以實現(xiàn)多線程操作時，內存始終由包裝的管理線程申請和釋放，這樣可以屏蔽用戶業(yè)務線程模型和訪問方式的差異。誰知運行一段時間之后再次發(fā)生了內存泄露，最后發(fā)現(xiàn)原來調用ByteBuf的write操作時，如果內存容量不足，會自動進行容量擴展。擴展操作由業(yè)務線程執(zhí)行，這就繞過了內存池管理線程，發(fā)生了“引用逃逸”。該Bug只有在ByteBuf容量動態(tài)擴展的時候才發(fā)生，因此，上線很長一段時間沒有發(fā)生，直到某一天......因此，大家在使用Netty 4.X的內存池時要格外當心，特別是做二次封裝時，一定要對內存池的實現(xiàn)細節(jié)有深刻的理解。
3. Netty升級之后遭遇數(shù)據(jù)被篡改
3.1. 問題描述
某業(yè)務產品，Netty3.X升級到4.X之后，系統(tǒng)運行過程中，偶現(xiàn)服務端發(fā)送給客戶端的應答數(shù)據(jù)被莫名“篡改”。
業(yè)務服務端的處理流程如下：
- 將解碼后的業(yè)務消息封裝成Task，投遞到后端的業(yè)務線程池中執(zhí)行；
- 業(yè)務線程處理業(yè)務邏輯，完成之后構造應答消息發(fā)送給客戶端；
- 業(yè)務應答消息的編碼通過繼承Netty的CodeC框架實現(xiàn)，即Encoder ChannelHandler;
- 調用Netty的消息發(fā)送接口之后，流程繼續(xù)，根據(jù)業(yè)務場景，可能會繼續(xù)操作原發(fā)送的業(yè)務對象。
業(yè)務相關代碼示例如下：
//構造訂購應答消息 SubInfoResp infoResp = new SubInfoResp(); //根據(jù)業(yè)務邏輯，對應答消息賦值 infoResp.setResultCode(0); infoResp.setXXX()； 后續(xù)賦值操作省略...... //調用ChannelHandlerContext進行消息發(fā)送 ctx.writeAndFlush(infoResp); //消息發(fā)送完成之后，后續(xù)根據(jù)業(yè)務流程進行分支處理，修改infoResp對象 infoResp.setXXX(); 后續(xù)代碼省略......
3.2. 問題定位
首先對應答消息被非法“篡改”的原因進行分析，經(jīng)過定位發(fā)現(xiàn)當發(fā)生問題時，被“篡改”的內容是調用writeAndFlush接口之后，由后續(xù)業(yè)務分支代碼修改應答消息導致的。由于修改操作發(fā)生在writeAndFlush操作之后，按照Netty 3.X的線程模型不應該出現(xiàn)該問題。
在Netty3中，downstream是在業(yè)務線程里執(zhí)行的，也就是說對SubInfoResp的編碼操作是在業(yè)務線程中執(zhí)行的，當編碼后的ByteBuf對象被投遞到消息發(fā)送隊列之后，業(yè)務線程才會返回并繼續(xù)執(zhí)行后續(xù)的業(yè)務邏輯，此時修改應答消息是不會改變已完成編碼的ByteBuf對象的，所以肯定不會出現(xiàn)應答消息被篡改的問題。
初步分析應該是由于線程模型發(fā)生變更導致的問題，隨后查驗了Netty 4的線程模型，果然發(fā)生了變化：當調用outbound向外發(fā)送消息的時候，Netty會將發(fā)送事件封裝成Task，投遞到NioEventLoop的任務隊列中異步執(zhí)行，相關代碼如下：
@Override public void invokeWrite(ChannelHandlerContext ctx, Object msg, ChannelPromise promise) { if (msg == null) { throw new NullPointerException("msg"); } validatePromise(ctx, promise, true); if (executor.inEventLoop()) { invokeWriteNow(ctx, msg, promise); } else { AbstractChannel channel = (AbstractChannel) ctx.channel(); int size = channel.estimatorHandle().size(msg); if (size > 0) { ChannelOutboundBuffer buffer = channel.unsafe().outboundBuffer(); // Check for null as it may be set to null if the channel is closed already if (buffer != null) { buffer.incrementPendingOutboundBytes(size); } } safeExecuteOutbound(WriteTask.newInstance(ctx, msg, size, promise), promise, msg); } }通過上述代碼可以看出，Netty首先對當前的操作的線程進行判斷，如果操作本身就是由NioEventLoop線程執(zhí)行，則調用寫操作；否則，執(zhí)行線程安全的寫操作，即將寫事件封裝成Task，放入到任務隊列中由Netty的I/O線程執(zhí)行，業(yè)務調用返回，流程繼續(xù)執(zhí)行。
通過源碼分析，問題根源已經(jīng)很清楚：系統(tǒng)升級到Netty 4之后，線程模型發(fā)生變化，響應消息的編碼由NioEventLoop線程異步執(zhí)行，業(yè)務線程返回。這時存在兩種可能：
- 如果編碼操作先于修改應答消息的業(yè)務邏輯執(zhí)行，則運行結果正確；
- 如果編碼操作在修改應答消息的業(yè)務邏輯之后執(zhí)行，則運行結果錯誤。
由于線程的執(zhí)行先后順序無法預測，因此該問題隱藏的相當深。如果對Netty 4和Netty3的線程模型不了解，就會掉入陷阱。
Netty 3版本業(yè)務邏輯沒有問題，流程如下：
圖3-1 升級之前的業(yè)務流程線程模型
升級到Netty 4版本之后，業(yè)務流程由于Netty線程模型的變更而發(fā)生改變，導致業(yè)務邏輯發(fā)生問題：
圖3-2 升級之后的業(yè)務處理流程發(fā)生改變
3.3. 問題總結
很多讀者在進行Netty 版本升級的時候，只關注到了包路徑、類和API的變更，并沒有注意到隱藏在背后的“暗箭”- 線程模型變更。
升級到Netty 4的用戶需要根據(jù)新的線程模型對已有的系統(tǒng)進行評估，重點需要關注outbound的ChannelHandler，如果它的正確性依賴于Netty 3的線程模型，則很可能在新的線程模型中出問題，可能是功能問題或者其它問題。
4. Netty升級之后性能嚴重下降
4.1. 問題描述
相信很多Netty用戶都看過如下相關報告：
在Twitter，Netty 4 GC開銷降為五分之一：Netty 3使用Java對象表示I/O事件，這樣簡單，但會產生大量的垃圾，尤其是在我們這樣的規(guī)模下。Netty 4在新版本中對此做出了更改，取代生存周期短的事件對象，而以定義在生存周期長的通道對象上的方法處理I/O事件。它還有一個使用池的專用緩沖區(qū)分配器。
每當收到新信息或者用戶發(fā)送信息到遠程端，Netty 3均會創(chuàng)建一個新的堆緩沖區(qū)。這意味著，對應每一個新的緩沖區(qū)，都會有一個‘new byte[capacity]’。這些緩沖區(qū)會導致GC壓力，并消耗內存帶寬：為了安全起見，新的字節(jié)數(shù)組分配時會用零填充，這會消耗內存帶寬。然而，用零填充的數(shù)組很可能會再次用實際的數(shù)據(jù)填充，這又會消耗同樣的內存帶寬。如果Java虛擬機（JVM）提供了創(chuàng)建新字節(jié)數(shù)組而又無需用零填充的方式，那么我們本來就可以將內存帶寬消耗減少50%，但是目前沒有那樣一種方式。
在Netty 4中，代碼定義了粒度更細的API，用來處理不同的事件類型，而不是創(chuàng)建事件對象。它還實現(xiàn)了一個新緩沖池，那是一個純Java版本的 jemalloc （Facebook也在用）。現(xiàn)在，Netty不會再因為用零填充緩沖區(qū)而浪費內存帶寬了。
我們比較了兩個分別建立在Netty 3和4基礎上echo協(xié)議服務器。（Echo非常簡單，這樣，任何垃圾的產生都是Netty的原因，而不是協(xié)議的原因）。我使它們服務于相同的分布式echo協(xié)議客戶端，來自這些客戶端的16384個并發(fā)連接重復發(fā)送256字節(jié)的隨機負載，幾乎使千兆以太網(wǎng)飽和。
根據(jù)測試結果，Netty 4：
- GC中斷頻率是原來的1/5： 45.5 vs. 9.2次/分鐘
- 垃圾生成速度是原來的1/5： 207.11 vs 41.81 MiB/秒
正是看到了相關的Netty 4性能提升報告，很多用戶選擇了升級。事后一些用戶反饋Netty 4并沒有跟產品帶來預期的性能提升，有些甚至還發(fā)生了非常嚴重的性能下降，下面我們就以某業(yè)務產品的失敗升級經(jīng)歷為案例，詳細分析下導致性能下降的原因。
4.2. 問題定位
首先通過JMC等性能分析工具對性能熱點進行分析，示例如下（信息安全等原因，只給出分析過程示例截圖）：
圖4-1 JMC性能監(jiān)控分析
通過對熱點方法的分析，發(fā)現(xiàn)在消息發(fā)送過程中，有兩處熱點：
- 消息發(fā)送性能統(tǒng)計相關Handler;
- 編碼Handler。
對使用Netty 3版本的業(yè)務產品進行性能對比測試，發(fā)現(xiàn)上述兩個Handler也是熱點方法。既然都是熱點，為啥切換到Netty4之后性能下降這么厲害呢？
通過方法的調用樹分析發(fā)現(xiàn)了兩個版本的差異：在Netty 3中，上述兩個熱點方法都是由業(yè)務線程負責執(zhí)行；而在Netty 4中，則是由NioEventLoop(I/O)線程執(zhí)行。對于某個鏈路，業(yè)務是擁有多個線程的線程池，而NioEventLoop只有一個，所以執(zhí)行效率更低，返回給客戶端的應答時延就大。時延增大之后，自然導致系統(tǒng)并發(fā)量降低，性能下降。
找出問題根因之后，針對Netty 4的線程模型對業(yè)務進行專項優(yōu)化，性能達到預期，遠超過了Netty 3老版本的性能。
Netty 3的業(yè)務線程調度模型圖如下所示：充分利用了業(yè)務多線程并行編碼和Handler處理的優(yōu)勢，周期T內可以處理N條業(yè)務消息。
圖4-2 Netty 3業(yè)務調度性能模型
切換到Netty 4之后，業(yè)務耗時Handler被I/O線程串行執(zhí)行，因此性能發(fā)生比較大的下降：
圖4-3 Netty 4業(yè)務調度性能模型
4.3. 問題總結
該問題的根因還是由于Netty 4的線程模型變更引起，線程模型變更之后，不僅影響業(yè)務的功能，甚至對性能也會造成很大的影響。
對Netty的升級需要從功能、兼容性和性能等多個角度進行綜合考慮，切不可只盯著API變更這個芝麻，而丟掉了性能這個西瓜。API的變更會導致編譯錯誤，但是性能下降卻隱藏于無形之中，稍不留意就會中招。
對于講究快速交付、敏捷開發(fā)和灰度發(fā)布的互聯(lián)網(wǎng)應用，升級的時候更應該要當心。
5. Netty升級之后上下文丟失
5.1. 問題描述
為了提升業(yè)務的二次定制能力，降低對接口的侵入性，業(yè)務使用線程變量進行消息上下文的傳遞。例如消息發(fā)送源地址信息、消息Id、會話Id等。
業(yè)務同時使用到了一些第三方開源容器，也提供了線程級變量上下文的能力。業(yè)務通過容器上下文獲取第三方容器的系統(tǒng)變量信息。
升級到Netty 4之后，業(yè)務繼承自Netty的ChannelHandler發(fā)生了空指針異常，無論是業(yè)務自定義的線程上下文、還是第三方容器的線程上下文，都獲取不到傳遞的變量值。
5.2. 問題定位
首先檢查代碼，看業(yè)務是否傳遞了相關變量，確認業(yè)務傳遞之后懷疑跟Netty 版本升級相關，調試發(fā)現(xiàn)，業(yè)務ChannelHandler獲取的線程上下文對象和之前業(yè)務傳遞的上下文不是同一個。這就說明執(zhí)行ChannelHandler的線程跟處理業(yè)務的線程不是同一個線程！
查看Netty 4線程模型的相關Doc發(fā)現(xiàn)，Netty修改了outbound的線程模型，正好影響了業(yè)務消息發(fā)送時的線程上下文傳遞，最終導致線程變量丟失。
5.3. 問題總結
通常業(yè)務的線程模型有如下幾種：
- 業(yè)務自定義線程池/線程組處理業(yè)務，例如使用JDK 1.5提供的ExecutorService；
- 使用J2EE Web容器自帶的線程模型，常見的如JBoss和Tomcat的HTTP接入線程等；
- 隱式的使用其它第三方框架的線程模型，例如使用NIO框架進行協(xié)議處理，業(yè)務代碼隱式使用的就是NIO框架的線程模型，除非業(yè)務明確的實現(xiàn)自定義線程模型。
在實踐中我們發(fā)現(xiàn)很多業(yè)務使用了第三方框架，但是只熟悉API和功能，對線程模型并不清楚。某個類庫由哪個線程調用，糊里糊涂。為了方便變量傳遞，又隨意的使用線程變量，實際對背后第三方類庫的線程模型產生了強依賴。當容器或者第三方類庫升級之后，如果線程模型發(fā)生了變更，則原有功能就會發(fā)生問題。
鑒于此，在實際工作中，盡量不要強依賴第三方類庫的線程模型，如果確實無法避免，則必須對它的線程模型有深入和清晰的了解。當?shù)谌筋悗焐壷螅枰獧z查線程模型是否發(fā)生變更，如果發(fā)生變化，相關的代碼也需要考慮同步升級。
6. Netty3.X VS Netty4.X 之線程模型
通過對三個具有典型性的升級失敗案例進行分析和總結，我們發(fā)現(xiàn)有個共性：都是線程模型改變惹的禍!
下面小節(jié)我們就詳細得對Netty3和Netty4版本的I/O線程模型進行對比，以方便大家掌握兩者的差異，在升級和使用中盡量少踩雷。
6.1 Netty 3.X 版本線程模型
Netty 3.X的I/O操作線程模型比較復雜，它的處理模型包括兩部分：
- Inbound：主要包括鏈路建立事件、鏈路激活事件、讀事件、I/O異常事件、鏈路關閉事件等；
- Outbound：主要包括寫事件、連接事件、監(jiān)聽綁定事件、刷新事件等。
我們首先分析下Inbound操作的線程模型：
圖6-1 Netty 3 Inbound操作線程模型
從上圖可以看出，Inbound操作的主要處理流程如下：
- I/O線程（Work線程）將消息從TCP緩沖區(qū)讀取到SocketChannel的接收緩沖區(qū)中；
- 由I/O線程負責生成相應的事件，觸發(fā)事件向上執(zhí)行，調度到ChannelPipeline中；
- I/O線程調度執(zhí)行ChannelPipeline中Handler鏈的對應方法，直到業(yè)務實現(xiàn)的Last Handler;
- Last Handler將消息封裝成Runnable，放入到業(yè)務線程池中執(zhí)行，I/O線程返回，繼續(xù)讀/寫等I/O操作；
- 業(yè)務線程池從任務隊列中彈出消息，并發(fā)執(zhí)行業(yè)務邏輯。
通過對Netty 3的Inbound操作進行分析我們可以看出，Inbound的Handler都是由Netty的I/O Work線程負責執(zhí)行。
下面我們繼續(xù)分析Outbound操作的線程模型：
圖6-2 Netty 3 Outbound操作線程模型
從上圖可以看出，Outbound操作的主要處理流程如下：
業(yè)務線程發(fā)起Channel Write操作，發(fā)送消息；
- Netty將寫操作封裝成寫事件，觸發(fā)事件向下傳播；
- 寫事件被調度到ChannelPipeline中，由業(yè)務線程按照Handler Chain串行調用支持Downstream事件的Channel Handler;
- 執(zhí)行到系統(tǒng)最后一個ChannelHandler，將編碼后的消息Push到發(fā)送隊列中，業(yè)務線程返回；
- Netty的I/O線程從發(fā)送消息隊列中取出消息，調用SocketChannel的write方法進行消息發(fā)送。
6.2 Netty 4.X 版本線程模型
相比于Netty 3.X系列版本，Netty 4.X的I/O操作線程模型比較簡答，它的原理圖如下所示：
圖6-3 Netty 4 Inbound和Outbound操作線程模型
從上圖可以看出，Outbound操作的主要處理流程如下：
- I/O線程NioEventLoop從SocketChannel中讀取數(shù)據(jù)報，將ByteBuf投遞到ChannelPipeline，觸發(fā)ChannelRead事件；
- I/O線程NioEventLoop調用ChannelHandler鏈，直到將消息投遞到業(yè)務線程，然后I/O線程返回，繼續(xù)后續(xù)的讀寫操作；
- 業(yè)務線程調用ChannelHandlerContext.write(Object msg)方法進行消息發(fā)送；
- 如果是由業(yè)務線程發(fā)起的寫操作，ChannelHandlerInvoker將發(fā)送消息封裝成Task，放入到I/O線程NioEventLoop的任務隊列中，由NioEventLoop在循環(huán)中統(tǒng)一調度和執(zhí)行。放入任務隊列之后，業(yè)務線程返回；
- I/O線程NioEventLoop調用ChannelHandler鏈，進行消息發(fā)送，處理Outbound事件，直到將消息放入發(fā)送隊列，然后喚醒Selector，進而執(zhí)行寫操作。
通過流程分析，我們發(fā)現(xiàn)Netty 4修改了線程模型，無論是Inbound還是Outbound操作，統(tǒng)一由I/O線程NioEventLoop調度執(zhí)行。
6.3. 線程模型對比
在進行新老版本線程模型PK之前，首先還是要熟悉下串行化設計的理念：
我們知道當系統(tǒng)在運行過程中，如果頻繁的進行線程上下文切換，會帶來額外的性能損耗。多線程并發(fā)執(zhí)行某個業(yè)務流程，業(yè)務開發(fā)者還需要時刻對線程安全保持警惕，哪些數(shù)據(jù)可能會被并發(fā)修改，如何保護？這不僅降低了開發(fā)效率，也會帶來額外的性能損耗。
為了解決上述問題，Netty 4采用了串行化設計理念，從消息的讀取、編碼以及后續(xù)Handler的執(zhí)行，始終都由I/O線程NioEventLoop負責，這就意外著整個流程不會進行線程上下文的切換，數(shù)據(jù)也不會面臨被并發(fā)修改的風險，對于用戶而言，甚至不需要了解Netty的線程細節(jié)，這確實是個非常好的設計理念，它的工作原理圖如下：
圖6-4 Netty 4的串行化設計理念
一個NioEventLoop聚合了一個多路復用器Selector，因此可以處理成百上千的客戶端連接，Netty的處理策略是每當有一個新的客戶端接入，則從NioEventLoop線程組中順序獲取一個可用的NioEventLoop，當?shù)竭_數(shù)組上限之后，重新返回到0，通過這種方式，可以基本保證各個NioEventLoop的負載均衡。一個客戶端連接只注冊到一個NioEventLoop上，這樣就避免了多個I/O線程去并發(fā)操作它。
Netty通過串行化設計理念降低了用戶的開發(fā)難度，提升了處理性能。利用線程組實現(xiàn)了多個串行化線程水平并行執(zhí)行，線程之間并沒有交集，這樣既可以充分利用多核提升并行處理能力，同時避免了線程上下文的切換和并發(fā)保護帶來的額外性能損耗。
了解完了Netty 4的串行化設計理念之后，我們繼續(xù)看Netty 3線程模型存在的問題，總結起來，它的主要問題如下：
- Inbound和Outbound實質都是I/O相關的操作，它們的線程模型竟然不統(tǒng)一，這給用戶帶來了更多的學習和使用成本；
- Outbound操作由業(yè)務線程執(zhí)行，通常業(yè)務會使用線程池并行處理業(yè)務消息，這就意味著在某一個時刻會有多個業(yè)務線程同時操作ChannelHandler，我們需要對ChannelHandler進行并發(fā)保護，通常需要加鎖。如果同步塊的范圍不當，可能會導致嚴重的性能瓶頸，這對開發(fā)者的技能要求非常高，降低了開發(fā)效率；
- Outbound操作過程中，例如消息編碼異常，會產生Exception，它會被轉換成Inbound的Exception并通知到ChannelPipeline，這就意味著業(yè)務線程發(fā)起了Inbound操作！它打破了Inbound操作由I/O線程操作的模型，如果開發(fā)者按照Inbound操作只會由一個I/O線程執(zhí)行的約束進行設計，則會發(fā)生線程并發(fā)訪問安全問題。由于該場景只在特定異常時發(fā)生，因此錯誤非常隱蔽！一旦在生產環(huán)境中發(fā)生此類線程并發(fā)問題，定位難度和成本都非常大。
講了這么多，似乎Netty 4 完勝 Netty 3的線程模型，其實并不盡然。在特定的場景下，Netty 3的性能可能更高，就如本文第4章節(jié)所講，如果編碼和其它Outbound操作非常耗時，由多個業(yè)務線程并發(fā)執(zhí)行，性能肯定高于單個NioEventLoop線程。
但是，這種性能優(yōu)勢不是不可逆轉的，如果我們修改業(yè)務代碼，將耗時的Handler操作前置，Outbound操作不做復雜業(yè)務邏輯處理，性能同樣不輸于Netty 3，但是考慮內存池優(yōu)化、不會反復創(chuàng)建Event、不需要對Handler加鎖等Netty 4的優(yōu)化，整體性能Netty 4版本肯定會更高。
總而言之，如果用戶真正熟悉并掌握了Netty 4的線程模型和功能類庫，相信不僅僅開發(fā)會更加簡單，性能也會更優(yōu)！
6.4. 思考
就Netty 而言，掌握線程模型的重要性不亞于熟悉它的API和功能。很多時候我遇到的功能、性能等問題，都是由于缺乏對它線程模型和原理的理解導致的，結果我們就以訛傳訛，認為Netty 4版本不如3好用等。
不能說所有開源軟件的版本升級一定都勝過老版本，就Netty而言，我認為Netty 4版本相比于老的Netty 3，確實是歷史的一大進步。
7. 作者簡介
李林鋒，2007年畢業(yè)于東北大學，2008年進入華為公司從事高性能通信軟件的設計和開發(fā)工作，有7年NIO設計和開發(fā)經(jīng)驗，精通Netty、Mina等NIO框架和平臺中間件，現(xiàn)任華為軟件平臺架構部架構師，《Netty權威指南》作者。
聯(lián)系方式：新浪微博 Nettying 微信：Nettying 微信公眾號：Netty之家
感謝郭蕾對本文的策劃和審校。
給InfoQ中文站投稿或者參與內容翻譯工作，請郵件至editors@cn.infoq.com。也歡迎大家通過新浪微博（@InfoQ）或者騰訊微博（@InfoQ）關注我們，并與我們的編輯和其他讀者朋友交流。