線上應用長連接 Netty 服務出現內存泄漏了！

應用介紹

說起支付業務的長連接服務，真是說來話長，我們這就長話短說： 隨著業務及系統架構的復雜化，一些場景，用戶操作無法同步得到結果。一般采用的短連接輪訓的策略，客戶端需要不停的發起請求，時效性較差還浪費服務器資源。 短輪訓痛點:

時效性差

耗費服務器性能

建立、關閉鏈接頻繁

相比于短連接輪訓策略，長連接服務可做到實時推送數據，并且在一個鏈接保持期間可進行多次數據推送。服務應用常見場景：PC 端掃碼支付，用戶打開掃碼支付頁面，手機掃碼完成支付，頁面實時展示支付成功信息，提供良好的用戶體驗。 長連服務優勢:

時效性高提升用戶體驗

減少鏈接建立次數

一次鏈接多次推送數據

提高系統吞吐量

這個長連接服務使用?Netty?框架，Netty?的高性能為這個應用帶來了無上的榮光，承接了眾多長連接使用場景的業務：

PC 收銀臺微信支付

聲波紅包

POS 線下掃碼支付

問題現象

回到線上問題，出現內存泄漏的是長連接前置服務，觀察線上服務，這個應用的內存泄漏的現象總伴隨著內存的增長，這個增長真是非常的緩慢，緩慢，緩慢，2、3 個月內從 30% 慢慢增長到 70%，極難發現：



每次發生內存泄漏，內存快耗盡時，總得重啟下，雖說重啟是最快解決的方法，但是程序員是天生懶惰的，要數著日子來重啟，那絕對不是一個優秀程序員的行為！問題必須徹底解決！

問題排查與復現

排查

遇到問題，毫無頭緒，首先還是需要去案發第一現場，排查 “死者 (應用實例)” 死亡現場，通過在發生 FullGC 的時間點，通過 Digger 查詢ERROR日志，沒想到還真找到破案的第一線索:

io.netty.util.ResourceLeakDetector [176] - 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.leakDetection.level=advanced' or call ResourceLeakDetector.setLevel() See http://netty.io/wiki/reference-counted-objects.html for more information.

ByteBuf.release（） 在垃圾回收之前沒有被調用。啟用高級泄漏報告以找出泄漏發生的位置。要啟用高級泄漏報告，請指定 JVM 選項 “-Dio.netty.leakDetectionLevel=advanced” 或調用 ResourceLeakDetector.setLevel（）

啊哈！這信息不就是說了嘛！ByteBuf.release（）在垃圾回收前沒有調用，有ByteBuf對象沒有被釋放，ByteBuf可是分配在直接內存的，沒有被釋放，那就意味著堆外內存泄漏，所以內存一直是非常緩慢的增長，GC 都不能夠進行釋放。

提供了這個線索，那到底是我們應用中哪段代碼出現了ByteBuf對象的內存泄漏呢？
項目這么大，Netty 通信處理那么多，怎么找呢？自己從中搜索，那肯定是不靠譜，找到了又怎么釋放呢？

復現

面對這一連三問？別著急，Netty 的日志提示還是非常完善：啟用高級泄漏報告找出泄漏發生位置嘛，生產上不可能啟用，并且生產發生時間極長，時間上來不及，而且未經驗證，不能直接生產發布，那就本地代碼復現一下！找到具體代碼位置。

為了本地復現Netty泄漏，定位詳細的內存泄漏代碼，我們需要做這幾步：

1、配置足夠小的本地 JVM 內存，以便快速模擬堆外內存泄漏。

如圖，我們設置設置 PermSize=30M, MaxPermSize=43M

2、模擬足夠多的長連接請求，我們使用 Postman 定時批量發請求，以達到服務的堆外內存泄漏。

啟動項目，通過JProfilerJVM 監控工具，我們觀察到內存緩慢的增長，最終觸發了本地Netty的堆外內存泄漏，本地復現成功：

_那問題具體出現在代碼中哪塊呢？_我們最重要的是定位具體代碼，在開啟了Netty的高級內存泄漏級別為高級，來定位下：

3、開啟Netty的高級內存泄漏檢測級別，JVM 參數如下：

-Dio.netty.leakDetectionLevel=advanced

再啟動項目，模擬請求，達到本地應用 JVM 內存泄漏，Netty 輸出如下具體日志信息，可以看到，具體的日志信息比之前的信息更加完善：

2020-09-24 2059.078 [nioEventLoopGroup-3-1] INFO  io.netty.handler.logging.LoggingHandler [101] - [id: 0x2a5e5026, L:/00008883] READ: [id: 0x926e140c, L:/127.0.0.1:8883 - R:/127.0.0.1:58920]
2020-09-24 2059.078 [nioEventLoopGroup-3-1] INFO  io.netty.handler.logging.LoggingHandler [101] - [id: 0x2a5e5026, L:/00008883] READ COMPLETE
2020-09-24 2059.079 [nioEventLoopGroup-2-8] ERROR io.netty.util.ResourceLeakDetector [171] - LEAK: ByteBuf.release() was not called before it's garbage-collected. See http://netty.io/wiki/reference-counted-objects.html for more information.
WARNING: 1 leak records were discarded because the leak record count is limited to 4. Use system property io.netty.leakDetection.maxRecords to increase the limit.
Recent access records: 5
#5:
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.readBytes(AdvancedLeakAwareCompositeByteBuf.java:476)
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.readBytes(AdvancedLeakAwareCompositeByteBuf.java:36)
com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.getClientMassageInfo(LongRotationServerHandler.java:169)
com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.handleHttpFrame(LongRotationServerHandler.java:121)
com.jd.jr.keeplive.front.service.nettyServer.handler.LongRotationServerHandler.channelRead(LongRotationServerHandler.java:80)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:362)
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:348)
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:340)
io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
......
#4:
Hint: 'LongRotationServerHandler#0' will handle the message from this point.
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)
io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)
......
#3:
Hint: 'HttpServerExpectContinueHandler#0' will handle the message from this point.
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)
io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)
  ......
#2:
Hint: 'HttpHeartbeatHandler#0' will handle the message from this point.
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)
io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)
  ......
#1:
Hint: 'IdleStateHandler#0' will handle the message from this point.
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:1028)
io.netty.buffer.AdvancedLeakAwareCompositeByteBuf.touch(AdvancedLeakAwareCompositeByteBuf.java:36)
io.netty.handler.codec.http.HttpObjectAggregator$AggregatedFullHttpMessage.touch(HttpObjectAggregator.java:359)
  ......
Created at:
io.netty.util.ResourceLeakDetector.track(ResourceLeakDetector.java:237)
io.netty.buffer.AbstractByteBufAllocator.compositeDirectBuffer(AbstractByteBufAllocator.java:217)
io.netty.buffer.AbstractByteBufAllocator.compositeBuffer(AbstractByteBufAllocator.java:195)
io.netty.handler.codec.MessageAggregator.decode(MessageAggregator.java:255)
  ......

問題解決

找到問題了，那我么就需要解決，如何釋放ByteBuf內存呢？

如何回收泄漏的 ByteBuf

其實Netty官方也針對這個問題做了專門的討論，一般的經驗法則是，最后訪問引用計數對象的一方負責銷毀該引用計數對象，具體來說：

如果一個 [發送] 組件將一個引用計數的對象傳遞給另一個 [接收] 組件，則發送組件通常不需要銷毀它，而是由接收組件進行銷毀。

如果一個組件使用了一個引用計數的對象，并且知道沒有其他對象將再訪問它（即，不會將引用傳遞給另一個組件），則該組件應該銷毀它。

總結起來主要三個方式：

方式一：手動釋放，哪里使用了，使用完就手動釋放。

方式二：升級ChannelHandler為SimpleChannelHandler， 在SimpleChannelHandler中，Netty對收到的所有消息都調用了ReferenceCountUtil.release（msg）。

方式三：如果處理過程中不確定ByteBuf是否應該被釋放，那交給 Netty 的ReferenceCountUtil.release（msg）來釋放，這個方法會判斷上下文是否可以釋放。 考慮到長連接前置應用使用的是ChannelHandler，如果升級SimpleChannelHandler對現有 API 接口變動比較大，同時如果手動釋放，不確定是否應該釋放風險也大，因此使用方式三，如下：

線上實例內存正常

問題修復后，線上服務正常，內存使用率也沒有再出現因泄漏而增長，從線上我們增加的日志中看出，FullHttpRequest中ByteBuf內存釋放成功。從此長連接前置內存泄漏的問題徹底解決。

總結

一、Netty 的內存泄漏排查其實并不難，Netty 提供了比較完整的排查內存泄漏工具 JVM 選項-Dio.netty.leakDetection.level 目前有 4 個泄漏檢測級別的：

DISABLED - 完全禁用泄漏檢測。不推薦。

SIMPLE - 抽樣 1% 的緩沖區是否有泄漏。默認。

ADVANCED - 抽樣 1% 的緩沖區是否泄漏，以及能定位到緩沖區泄漏的代碼位置。

PARANOID - 與 ADVANCED 相同，只是它適用于每個緩沖區，適用于自動化測試階段。如果生成輸出包含 “LEAK：”，則可能會使生成失敗。

本次內存泄漏問題，我們通過本地設置泄漏檢測級別為高級，即：-Dio.netty.leakDetectionLevel=advanced定位到了具體內存泄漏的代碼。 同時 Netty 也給出了避免泄漏的最佳實踐：

在 PARANOID 泄漏檢測級別以及 SIMPLE 級別運行單元測試和集成測試。

在 SIMPLE 級別向整個集群推出應用程序之前，請先在相當長的時間內查看是否存在泄漏。

如果有泄漏，灰度發布中使用 ADVANCED 級別，以獲得有關泄漏來源的一些提示。

不要將泄漏的應用程序部署到整個群集。

二、解決 Netty 內存泄漏，Netty 也提供了指導方案，主要有三種方式 方式一：手動釋放，哪里使用了，使用完就手動釋放，這個對使用方要求比較高了。

方式二：如果處理過程中不確定ByteBuf是否應該被釋放，那交給Netty的ReferenceCountUtil.release（msg）來釋放，這個方法會判斷上下文中是否可以釋放，簡單方便。

方式三：升級ChannelHandler為SimpleChannelHandler， 在 SimpleChannelHandler 中，Netty 對收到的所有消息都調用了ReferenceCountUtil.release（msg），升級接口，可能對現有 API 改動會比較大。

審核編輯：劉清