有過痛苦的經歷，特別能寫出深刻的文章 —— 凱爾文. 肖
直接內存是IO框架的絕配，但直接內存的分配銷毀不易，所以使用內存池能大幅提高性能，也告別了頻繁的GC。但，要重新培養被Java的自動垃圾回收慣壞了的惰性。
Netty有一篇必讀的文檔 官方文檔翻譯：引用計數對象 ，在此基礎上補充一些自己的理解和細節。
1.為什么要有引用計數器
Netty里四種主力的ByteBuf，
其中UnpooledHeapByteBuf 底下的byte[]能夠依賴JVM GC自然回收；而UnpooledDirectByteBuf底下是DirectByteBuffer，如Java堆外內存掃盲貼所述，除了等JVM GC，最好也能主動進行回收；而PooledHeapByteBuf 和 PooledDirectByteBuf，則必須要主動將用完的byte[]/ByteBuffer放回池里，否則內存就要爆掉。所以，Netty ByteBuf需要在JVM的GC機制之外，有自己的引用計數器和回收過程。
一下又回到了C的冰冷時代，自己malloc對象要自己free。 但和C時代又不完全一樣，內有引用計數器，外有JVM的GC，情況更為復雜。
2. 引用計數器常識
- 計數器基於 AtomicIntegerFieldUpdater，為什么不直接用AtomicInteger？因為ByteBuf對象很多，如果都把int包一層AtomicInteger花銷較大，而AtomicIntegerFieldUpdater只需要一個全局的靜態變量。
- 所有ByteBuf的引用計數器初始值為1。
- 調用release()，將計數器減1，等於零時， deallocate()被調用，各種回收。
- 調用retain()，將計數器加1，即使ByteBuf在別的地方被人release()了，在本Class沒喊cut之前，不要把它釋放掉。
- 由duplicate(), slice()和order()所衍生的ByteBuf，與原對象共享底下的buffer，也共享引用計數器，所以它們經常需要調用retain()來顯示自己的存在。
- 當引用計數器為0，底下的buffer已被回收，即使ByteBuf對象還在，對它的各種訪問操作都會拋出異常。
3.誰來負責Release
在C時代，我們喜歡讓malloc和free成對出現，而在Netty里，因為Handler鏈的存在，ByteBuf經常要傳遞到下一個Hanlder去而不復還，所以規則變成了誰是最后使用者，誰負責釋放。
另外，更要注意的是各種異常情況，ByteBuf沒有成功傳遞到下一個Hanlder，還在自己地界里的話，一定要進行釋放。
3.1 InBound Message
在AbstractNioByteChannel.NioByteUnsafe.read() 處創建了ByteBuf並調用 pipeline.fireChannelRead(byteBuf) 送入Handler鏈。
根據上面的誰最后誰負責原則，每個Handler對消息可能有三種處理方式
- 對原消息不做處理，調用 ctx.fireChannelRead(msg)把原消息往下傳，那不用做什么釋放。
- 將原消息轉化為新的消息並調用 ctx.fireChannelRead(newMsg)往下傳，那必須把原消息release掉。
- 如果已經不再調用ctx.fireChannelRead(msg)傳遞任何消息，那更要把原消息release掉。
假設每一個Handler都把消息往下傳，Handler並也不知道誰是啟動Netty時所設定的Handler鏈的最后一員，所以Netty在Handler鏈的最末補了一個TailHandler，如果此時消息仍然是ReferenceCounted類型就會被release掉。
3.2 OutBound Message
要發送的消息由應用所創建，並調用 ctx.writeAndFlush(msg) 進入Handler鏈。在每個Handler中的處理類似InBound Message，最后消息會來到HeadHandler，再經過一輪復雜的調用，在flush完成后終將被release掉。
3.3 異常發生時的釋放
多層的異常處理機制，有些異常處理的地方不一定准確知道ByteBuf之前釋放了沒有，可以在釋放前加上引用計數大於0的判斷避免釋放失敗；
有時候不清楚ByteBuf被引用了多少次，但又必須在此進行徹底的釋放，可以循環調用reelase()直到返回true。
4. 內存泄漏檢測
所謂內存泄漏，主要是針對池化的ByteBuf。ByteBuf對象被JVM GC掉之前，沒有調用release()把底下的DirectByteBuffer或byte[]歸還到池里，會導致池越來越大。而非池化的ByteBuf，即使像DirectByteBuf那樣可能會用到System.gc()，但終歸會被release掉的，不會出大事。
Netty擔心大家不小心就搞出個大新聞來，因此提供了內存泄漏的監測機制。
Netty默認會從分配的ByteBuf里抽樣出大約1%的來進行跟蹤。如果泄漏，會有如下語句打印：
LEAK: ByteBuf.release() was not called before it's garbage-collected. Enable advanced leak reporting to find out where the leak occurred. To enable advanced leak reporting, specify the JVM option '-Dio.netty.leakDetectionLevel=advanced' or call ResourceLeakDetector.setLevel()
這句話報告有泄漏的發生，提示你用-D參數，把防漏等級從默認的simple升到advanced，就能具體看到被泄漏的ByteBuf被創建和訪問的地方。
- 禁用（DISABLED） - 完全禁止泄露檢測，省點消耗。
- 簡單（SIMPLE） - 默認等級，告訴我們取樣的1%的ByteBuf是否發生了泄露，但總共一次只打印一次，看不到就沒有了。
- 高級（ADVANCED） - 告訴我們取樣的1%的ByteBuf發生泄露的地方。每種類型的泄漏（創建的地方與訪問路徑一致）只打印一次。對性能有影響。
- 偏執（PARANOID） - 跟高級選項類似，但此選項檢測所有ByteBuf，而不僅僅是取樣的那1%。對性能有絕大的影響。
實現細節
每當各種ByteBufAllocator 創建ByteBuf時，都會問問是否需要采樣，Simple和Advanced級別下，就是以113這個素數來取模（害我看文檔的時候還在瞎擔心，1％，萬一泄漏的地方有所規律，剛好躲過了100這個數字呢，比如都是3倍數的），命中了就創建一個Java堆外內存掃盲貼里說的PhantomReference。然后創建一個Wrapper，包住ByteBuf和Reference。
simple級別下，wrapper只在執行release()時調用Reference.clear()，Advanced級別下則會記錄每一個創建和訪問的動作。
當GC發生，還沒有被clear()的Reference就會被JVM放入到之前設定的ReferenceQueue里。
在每次創建PhantomReference時，都會順便看看有沒有因為忘記執行release()把Reference給clear掉，在GC時被放進了ReferenceQueue的對象，有則以 "io.netty.util.ResourceLeakDetector”為logger name，寫出前面例子里的Error級別的日日志。順便說一句，Netty能自動匹配日志框架，先找Slf4j，再找Log4j，最后找JDK logger。
值得說三遍的事
一定要盯緊log里有沒有出現 "LEAK: "字樣，因為simple級別下它只會出現一次，所以不要依賴自己的眼睛，要依賴grep。如果出現了，而且你用的是PooledBuf，那一定是問題，不要有任何的僥幸，立刻用"-Dio.netty.leakDetectionLevel=advanced" 再跑一次，看清楚它創建和訪問的地方。
功能測試時，最好開着"-Dio.netty.leakDetectionLevel=paranoid"。
但是，怎么測試都可能存在沒有覆蓋到的分支。如果內存尚夠，可以適當把-XX:MaxDirectMemorySize 調大，反正只是max，平時也不會真用了你的。然后監控其使用量，及時報警。
文章持續修訂，轉載請保留原鏈接： http://calvin1978.blogcn.com/articles/netty-leak.html