haddler处理队列 netty_Netty堆外内存泄漏排查，这一篇全讲清楚了
上篇文章介紹了Netty內存模型原理，由于Netty在使用不當會導致堆外內存泄漏，網上關于這方面的資料比較少，所以寫下這篇文章，專門介紹排查Netty堆外內存相關的知識點，診斷工具，以及排查思路提供參考
現象
堆外內存泄漏的現象主要是，進程占用的內存較高(Linux下可以用top命令查看)，但Java堆內存占用并不高(jmap命令查看)，常見的使用堆外內存除了Netty，還有基于java.nio下相關接口申請堆外內存，JNI調用等，下面側重介紹Netty堆外內存泄漏問題排查
堆外內存釋放底層實現
1 java.nio堆外內存釋放
Netty堆外內存是基于原生java.nio的DirectByteBuffer對象的基礎上實現的，所以有必要先了解下它的釋放原理
java.nio提供的DirectByteBuffer提供了sun.misc.Cleaner類的clean()方法，進行系統調用釋放堆外內存，觸發clean()方法的情況有2種
(1) 應用程序主動調用
ByteBuffer buf = ByteBuffer.allocateDirect(1);
((DirectBuffer) byteBuffer).cleaner().clean();
(2) 基于GC回收
Cleaner類繼承了java.lang.ref.Reference，GC線程會通過設置Reference的內部變量(pending變量為鏈表頭部節點，discovered變量為下一個鏈表節點)，將可被回收的不可達的Reference對象以鏈表的方式組織起來
Reference的內部守護線程從鏈表的頭部(head)消費數據，如果消費到的Reference對象同時也是Cleaner類型，線程會調用clean()方法(Reference#tryHandlePending())
2 Netty noCleaner策略
介紹noCleaner策略之前，需要先理解帶有Cleaner對象的DirectByteBuffer在初始化時做了哪些事情：
只有在DirectByteBuffer(int cap)構造方法中才會初始化Cleaner對象，方法中檢查當前內存是否超過允許的最大堆外內存(可由-XX:MaxDirectMemorySize配置)
如果超出，則會先嘗試將不可達的Reference對象加入Reference鏈表中，依賴Reference的內部守護線程觸發可以被回收DirectByteBuffer關聯的Cleaner的run()方法
如果內存還是不足， 則執行 System.gc()，觸發full gc，來回收堆內存中的DirectByteBuffer對象來觸發堆外內存回收，如果還是超過限制，則拋出java.lang.OutOfMemoryError(代碼位于java.nio.Bits#reserveMemory()方法)
而Netty在4.1引入可以noCleaner策略：創建不帶Cleaner的DirectByteBuffer對象，這樣做的好處是繞開帶Cleaner的DirectByteBuffer執行構造方法和執行Cleaner的clean()方法中一些額外開銷，當堆外內存不夠的時候，不會觸發System.gc()，提高性能
hasCleaner的DirectByteBuffer和noCleaner的DirectByteBuffer主要區別如下：
構造器方式不同：
noCleaner對象：由反射調用 private DirectByteBuffer(long addr, int cap)創建
hasCleaner對象：由 new DirectByteBuffer(int cap)創建
釋放內存的方式不同
noCleaner對象：使用 UnSafe.freeMemory(address);
hasCleaner對象：使用 DirectByteBuffer 的 Cleaner 的 clean() 方法
note：Unsafe是位于sun.misc包下的一個類，可以提供內存操作、對象操作、線程調度等本地方法，這些方法在提升Java運行效率、增強Java語言底層資源操作能力方面起到了很大的作用，但不正確使用Unsafe類會使得程序出錯的概率變大，程序不再“安全”，因此官方不推薦使用，并可能在未來的jdk版本移除
Netty在啟動時需要判斷檢查當前環境、環境配置參數是否允許noCleaner策略(具體邏輯位于PlatformDependent的static代碼塊)，例如運行在Android下時，是沒有Unsafe類的，不允許使用noCleaner策略，如果不允許，則使用hasCleaner策略
note：可以調用PlatformDependent.useDirectBufferNoCleaner()方法查看當前Netty程序是否使用noCleaner策略
讀到這里，也許有讀者會問，如果Netty基于hasCleaner策略，通過GC觸發Cleaner.clean()，自動回收堆外內存，是不是就可以不用考慮ByteBuf.release()方法的調用，不會內存泄漏？
當然不是，一方面原因是自動觸發不實時：需要ByteBuffer對象被GC線程回收才會觸發，如果ByteBuffer對象進入老年代后才變得可回收，則需要等到發送頻率較低老年代GC才會觸發
另一方面，Netty需要基于ByteBuf.release()方法執行其他操作，例如池化內存釋放回內存池，否則該對象會被內存池一直標記為已使用
ByteBuf.release()觸發機制
業界有一種誤解認為 Netty 框架分配的 ByteBuf，框架會自動釋放，業務不需要釋放；業務創建的 ByteBuf 則需要自己釋放，Netty 框架不會釋放
產生這種誤解是有原因的，Netty框架是會在一些場景調用ByteBuf.release()方法：
1 入站消息處理
當處理入站消息時，Netty會創建ByteBuf讀取channel上的消息，并觸發調用pipeline上的ChannelHandler處理，應用程序定義的使用ByteBuf的ChannelHandler需要負責release()
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf buf = (ByteBuf) msg;
try {
...
} finally {
buf.release();
}
}
如果該ByteBuf不由當前ChannelHandler處理，則傳遞給pipeline上下一個handler：
public void channelRead(ChannelHandlerContext ctx, Object msg) {
ByteBuf buf = (ByteBuf) msg;
...
ctx.fireChannelRead(buf);
}
常用的我們會通過繼承ChannelInboundHandlerAdapter定義入站消息處理的handler，這種情況下如果所有程序的hanler都沒有調用release()方法，該入站消息Netty最后并不會release()，會導致內存泄漏；
當在pipeline的handler處理中拋出異常之后，最后Netty框架是會捕捉該異常進行ByteBuf.release()的；
完整流程位于AbstractNioByteChannel.NioByteUnsafe#read(),下面抽取關鍵片段：
try {
do {
byteBuf = allocHandle.allocate(allocator);
allocHandle.lastBytesRead(doReadBytes(byteBuf));
// 入站消息已讀完
if (allocHandle.lastBytesRead() <= 0) {
// ...
break;
}
// 觸發pipline上handler進行處理
pipeline.fireChannelRead(byteBuf);
byteBuf = null;
} while (allocHandle.continueReading());
// ...
} catch (Throwable t) {
// 異常處理中包括調用 byteBuf.release()
handleReadException(pipeline, byteBuf, t, close, allocHandle);
}
不過，常用的還有通過繼承SimpleChannelInboundHandler定義入站消息處理，在該類會保證消息最終被release：
@Override
public void channelRead(ChannelHandlerContext ctx, Object msg) throws Exception {
boolean release = true;
try {
// 該消息由當前handler處理
if (acceptInboundMessage(msg)) {
I imsg = (I) msg;
channelRead0(ctx, imsg);
} else {
// 不由當前handler處理，傳遞給pipeline上下一個handler
release = false;
ctx.fireChannelRead(msg);
}
} finally {
// 觸發release
if (autoRelease && release) {
ReferenceCountUtil.release(msg);
}
}
}
2 出站消息處理
不同于入站消息是由Netty框架自動創建的，出站消息通常由應用程序創建，然后調用基于channel的write()方法或writeAndFlush()方法，這些方法內部會負責調用傳入的byteBuf的release()方法
note： write()方法在netty-4.0.0.CR2前的版本存在問題，不會調用ByteBuf.release()
3 release()注意事項
(1) 引用計數
還有一種常見的誤解就是，只要調用了ByteBuf的release()方法，或者ReferenceCountUtil.release()方法，對象的內存就保證釋放了，其實不是
因為Netty的ByteBuf引用計數來管理ByteBuf對象的生命周期，ByteBuf繼承了ReferenceCounted接口，對外提供retain()和release()方法，用于增加或減少引用計數值，當調用release()方法時，內部計數值被減為0才會觸發內存回收動作
(2) derived ByteBuf
derived，派生的意思，在ByteBuf.duplicate(), ByteBuf.slice() 和 ByteBuf.order(ByteOrder) 等方法會創建出derived ByteBuf，創建出來的ByteBuf與原有ByteBuf是共享引用計數的，原有ByteBuf的release()方法調用，也會導致這些對象內存回收
相反ByteBuf.copy() 和 ByteBuf.readBytes(int)方法創建出來的對象并不是derived ByteBuf，這些對象與原有ByteBuf不是共享引用計數的，原有ByteBuf的release()方法調用不會導致這些對象內存回收
堆外內存大小控制參數
配置堆外內存大小的參數有-XX:MaxDirectMemorySize和-Dio.netty.maxDirectMemory，這2個參數有什么區別？
-XX:MaxDirectMemorySize
用于限制Netty中hasCleaner策略的DirectByteBuffer堆外內存的大小，默認值是JVM能從操作系統申請的最大內存，如果內存本身沒限制，則值為Long.MAX_VALUE個字節(默認值由Runtime.getRuntime().maxMemory()返回)，代碼位于java.nio.Bits#reserveMemory()方法中
note：-XX:MaxDirectMemorySize無法限制Netty中noCleaner策略的DirectByteBuffer堆外內存的大小
-Dio.netty.maxDirectMemory
用于限制noCleaner策略下Netty的DirectByteBuffer分配的最大堆外內存的大小，如果該值為0，則使用hasCleaner策略，代碼位于PlatformDependent#incrementMemoryCounter()方法中
堆外內存監控
如何獲取堆外內存的使用情況？
1 代碼工具
(1) hasCleaner的DirectByteBuffer監控
對于hasCleaner策略的DirectByteBuffer，java.nio.Bits類是有記錄堆外內存的使用情況，但是該類是包級別的訪問權限，不能直接獲取，可以通過MXBean來獲取
note：MXBean，Java提供的一系列用于監控統計的特殊Bean，通過不同類型的MXBean可以獲取JVM進程的內存，線程、類加載信息等監控指標
List bufferPoolMXBeans = ManagementFactoryHelper.getBufferPoolMXBeans();
BufferPoolMXBean directBufferMXBean = bufferPoolMXBeans.get(0);
// hasCleaner的DirectBuffer的數量
long count = directBufferMXBean.getCount();
// hasCleaner的DirectBuffer的堆外內存占用大小，單位字節
long memoryUsed = directBufferMXBean.getMemoryUsed();
note： MappedByteBuffer：是基于FileChannelImpl.map進行進行mmap內存映射(零拷貝的一種實現)得到的另外一種堆外內存的ByteBuffer，可以通過ManagementFactoryHelper.getBufferPoolMXBeans().get(1)獲取到該堆外內存的監控指標
(2) noCleaner的DirectByteBuffer監控
Netty中noCleaner的DirectByteBuffer的監控比較簡單，直接通過PlatformDependent.usedDirectMemory()訪問即可
2 Netty自帶內存泄漏檢測工具
Netty也自帶了內存泄漏檢測工具，可用于檢測出ByteBuf對象被GC回收，但ByteBuf管理的內存沒有釋放的情況，但不適用ByteBuf對象還沒被GC回收內存泄漏的情況，例如任務隊列積壓
為了便于用戶發現內存泄露，Netty提供4個檢測級別：
disabled 完全關閉內存泄露檢測
simple 以約1%的抽樣率檢測是否泄露，默認級別
advanced 抽樣率同simple，但顯示詳細的泄露報告
paranoid 抽樣率為100%，顯示報告信息同advanced
使用方法是在命令行參數設置：
-Dio.netty.leakDetectionLevel=[檢測級別]
示例程序如下，設置檢測級別為paranoid ：
// -Dio.netty.leakDetectionLevel=paranoid
public static void main(String[] args) {
for (int i = 0; i < 500000; ++i) {
ByteBuf byteBuf = UnpooledByteBufAllocator.DEFAULT.buffer(1024);
byteBuf = null;
}
System.gc();
}
可以看到控制臺輸出泄漏報告：
十二月 27, 2019 8:37:04 上午 io.netty.util.ResourceLeakDetector reportTracedLeak
嚴重: LEAK: ByteBuf.release() was not called before it's garbage-collected. See https://netty.io/wiki/reference-counted-objects.html for more information.
Recent access records:
Created at:
io.netty.buffer.UnpooledByteBufAllocator.newDirectBuffer(UnpooledByteBufAllocator.java:96)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:187)
io.netty.buffer.AbstractByteBufAllocator.directBuffer(AbstractByteBufAllocator.java:178)
io.netty.buffer.AbstractByteBufAllocator.buffer(AbstractByteBufAllocator.java:115)
org.caison.netty.demo.memory.BufferLeaksDemo.main(BufferLeaksDemo.java:15)
內存泄漏的原理是利用弱引用，弱引用(WeakReference)創建時需要指定引用隊列(refQueue)，通過將ByteBuf對象用弱引用包裝起來(代碼入口位于AbstractByteBufAllocator#toLeakAwareBuffer()方法)
當發生GC時，如果GC線程檢測到ByteBuf對象只被弱引用對象關聯，會將該WeakReference加入refQueue；
當ByteBuf內存被正常釋放，會調用WeakReference的clear()方法解除對ByteBuf的引用，后續GC線程不會再將該WeakReference加入refQueue；
Netty在每次創建ByteBuf時，基于抽樣率，抽樣命中時會輪詢(poll)refQueue中的WeakReference對象，輪詢返回的非null的WeakReference關聯的ByteBuf即為泄漏的堆外內存(代碼入口位于ResourceLeakDetector#track()方法)
3 圖形化工具
在代碼獲取堆外內存的基礎上，通過自定義接入一些監控工具定時檢測獲取，繪制圖形即可，例如比較流行的Prometheus或者Zabbix
也可以通過jdk自帶的Visualvm獲取，需要安裝Buffer Pools插件，底層原理是訪問MXBean中的監控指標，只能獲取hasCleaner的DirectByteBuffer的使用情況
此外，對于JNI調用產生的堆外內存分配，可以使用google-perftools進行監控
堆外內存泄漏診斷
堆外內存泄漏的具體原因比較多，先介紹任務隊列堆積的監控，再介紹通用堆外內存泄漏診斷思路
1 任務隊列堆積
這里的任務隊列是值NioEventLoop中的QueuetaskQueue，提交到該任務隊列的場景有：
(1) 用戶自定義普通任務
ctx.channel().eventLoop().execute(runnable);
(2) 對channel進行寫入
channel.write(...)
channel.writeAndFlush(...)
(3) 用戶自定義定時任務
ctx.channel().eventLoop().schedule(runnable, 60, TimeUnit.SECONDS);
當隊列中積壓任務過多，導致消息不能對channel進行寫入然后進行釋放，會導致內存泄漏
public void channelActive(ChannelHandlerContext ctx) throws NoSuchFieldException, IllegalAccessException {
monitorPendingTaskCount(ctx);
monitorQueueFirstTask(ctx);
monitorOutboundBufSize(ctx);
}
/** 監控任務隊列堆積任務數，任務隊列中的任務包括io讀寫任務，業務程序提交任務 */
public void monitorPendingTaskCount(ChannelHandlerContext ctx) {
int totalPendingSize = 0;
for (EventExecutor eventExecutor : ctx.executor().parent()) {
SingleThreadEventExecutor executor = (SingleThreadEventExecutor) eventExecutor;
// 注意，Netty4.1.29以下版本本pendingTasks()方法存在bug，導致線程阻塞問題
// 參考 https://github.com/netty/netty/issues/8196
totalPendingSize += executor.pendingTasks();
}
System.out.println("任務隊列中總任務數 = " + totalPendingSize);
}
/** 監控各個堆積的任務隊列中第一個任務的類信息 */
public void monitorQueueFirstTask(ChannelHandlerContext ctx) throws NoSuchFieldException, IllegalAccessException {
Field singleThreadField = SingleThreadEventExecutor.class.getDeclaredField("taskQueue");
singleThreadField.setAccessible(true);
for (EventExecutor eventExecutor : ctx.executor().parent()) {
SingleThreadEventExecutor executor = (SingleThreadEventExecutor) eventExecutor;
Runnable task = ((Queue) singleThreadField.get(executor)).peek();
if (null != task) {
System.out.println("任務隊列中第一個任務信息：" + task.getClass().getName());
}
}
}
/** 監控出站消息的隊列積壓的byteBuf大小 */
public void monitorOutboundBufSize(ChannelHandlerContext ctx) {
long outBoundBufSize = ((NioSocketChannel) ctx.channel()).unsafe().outboundBuffer().totalPendingWriteBytes();
System.out.println("出站消息隊列中積壓的buf大小" + outBoundBufSize);
}
note: 上面程序至少需要基于Netty4.1.29版本才能使用，否則有性能問題
實際基于Netty進行業務開發，耗時的業務邏輯代碼應該如何處理？
先說結論，建議自定義一組新的業務線程池，將耗時業務提交業務線程池
Netty的worker線程(NioEventLoop)，除了作為NIO線程處理連接數據讀取，執行pipeline上channelHandler邏輯，另外還有消費taskQueue中提交的任務，包括channel的write操作。
如果將耗時任務提交到taskQueue，也會影響NIO線程的處理還有taskQueue中的任務，因此建議在單獨的業務線程池進行隔離處理
2 通用診斷思路
Netty堆外內存泄漏的原因多種多樣，例如代碼漏了寫調用release()；通過retain()增加了ByteBuf的引用計數值而在調用release()時引用計數值未清空；因為Exception導致未能release()；ByteBuf引用對象提前被GC，而關聯的堆外內存未能回收等等，這里無法全部列舉，所以嘗試提供一套通用的診斷思路提供參考
首先，需要能復現問題，為了不影響線上服務的運行，盡量在測試環境或者本地環境進行模擬。但這些環境通常沒有線上那么大的并發量，可以通過壓測工具來模擬請求
對于有些無法模擬的場景，可以通過Linux流量復制工具將線上真實的流量復制到到測試環境，同時不影響線上的業務，類似工具有Gor、tcpreplay、tcpcopy等
能復現之后，接下來就要定位問題所在，先通過前面介紹的監控手段、日志信息試試能不能直接找到問題所在；
如果找不到，就需要定位出堆外內存泄漏的觸發條件，但有時應用程序比較龐大，對外提供的流量入口很多，無法逐一排查。
在非線上環境的話，可以將流量入口注釋掉，每次注釋掉一半，然后再運行檢查問題是否還存在，如果存在，繼續再注釋掉剩下的一半，通過這種二分法的策略通過幾次嘗試可以很快定位出問題觸發條件
定位出觸發條件之后，再檢查程序中在該觸發條件處理邏輯，如果該處理程序很復雜，無法直接看出來，還可以繼續注釋掉部分代碼，二分法排查，直到最后找出具體的問題代碼塊
整套思路的核心在于，問題復現、監控、排除法，也可以用于排查其他問題，例如堆內內存泄漏、CPU 100%，服務進程掛掉等
總結
整篇文章側重于介紹知識點和理論，缺少實戰環節，這里分享一些優質博客文章：
《netty 堆外內存泄露排查盛宴》 閃電俠手把手帶如何debug堆外內存泄漏
https://www.jianshu.com/p/4e96beb37935
總結
以上是生活随笔為你收集整理的haddler处理队列 netty_Netty堆外内存泄漏排查，这一篇全讲清楚了的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 震惊！printf 与scanf 不可告
- 下一篇： (stl排序+检索）大理石在哪