記一次堆內外內存問題的排查和優化

為優化淘寶帶寬成本，我們在網關 SDK（Java）統一使用 ZSTD 替代 GZIP 壓縮以獲取更高的壓縮比，從而得到更小的響應包。具體實現采用官方推薦的?zstd-jni 庫。zstd-jni 會調用 zstd 的 c++ 庫。

背景

在性能壓測和優化過程中，遇到了以下三個問題：

GC 次數不變，但耗時翻倍
進程內存泄漏，極限情況下會出現 OOM Killer 殺掉進程的情況
Netty 堆外內存泄漏（在優化問題 1 時引入）

下面我會從這三個問題展開，分享排查、解決問題的思路和過程。

GC 優化

???【GC 耗時翻倍問題】現象

在我們預期中，使用 ZSTD 壓縮，在大包場景下（20KB 以上），不僅能夠獲得比 GZIP 更高的壓縮比；同時壓縮性能也應有一定優化，具體優化程度取決于業務特征，但至少不會有性能劣化。

但實際性能壓測發現相比于同級別的 Netty GZIP，ZSTD 壓縮下，GC 次數不變，但耗時幾乎翻倍，導致最終應用表現為幾乎無任何性能優化，甚至影響 RT（CMS 下）。

???【GC 耗時翻倍問題】分析

我們的 ZSTD 壓縮是通過 JNI 實現，流程是將堆內數據拷貝到堆外壓縮，再將拷回堆內。

使用 JNI 會在一定程度上影響 GC 的效率，這是我們已知的，但是耗時翻倍超出了我們的預期。因此我們嘗試分析壓縮的執行流程。

JDK 22 中通過在 G1 中實現 region pinning 來減少延遲，以在 JNI 執行期間無需禁用 GC，詳見 JEP?423:?Region?Pinning?for?G1（地址：https://openjdk.org/jeps/423）

相比 GZIP，ZSTD 在單次壓縮過程中，多了內存占用：

壓縮后數據占用的堆內內存
a.ZSTD 壓縮原始數據和壓縮后數據分開保存，占用兩份內存。而 GZIP 會將壓縮后的數據寫回到壓縮前的 byte 數組，只占用一份內存。
b.除此之外，尤其是在流式 ZSTD 場景下，多個響應復用同一個 OutputStream 以達到最優壓縮比，但 OutputStream 里的 buffer 會占用額外的堆內空間。
堆外壓縮需要的內存，保存 ZSTD 壓縮上下文（保存字典）。

據圖分析，可能存在兩個問題導致 GC 耗時變長：

不必要的堆內內存占用
不必要的堆內外數據拷貝

???【GC 耗時翻倍問題】解決

思路：為了能夠解決以上兩個問題，我們希望能夠將原始數據在堆外壓縮后直接寫出，一方面盡早釋放原始數據占用的堆內內存，另一方面減少不必要的堆內外拷貝。

實現：使用 zstd-jni 提供的堆外壓縮接口，直接原始數據拷貝到堆外進行壓縮，并通過 Netty 直接在堆外寫出（流程為上圖的 ZSTD Direct）。

???【Finalizer 問題】現象

但是，轉堆外壓縮后，再次進行壓測，發現 GC 并沒有如期下降，反而更加頻繁，堆內存使用更高。

于是 GC 后 dump 查看堆布局，分析 JVM 堆內存，發現整體堆使用大小 915M/4G，這很不正常，我們的測試應用沒有長壽命對象，預期 GC 后，堆大小應該只有幾十 M。

進一步查看堆內對象，發現有大量新增可疑對象：

Finalizer
ZstdJNIDirectByteBufCompressor（壓縮實例，JNI 調用入口。）
DefaultInvocation（請求上下文，包含請求和響應的全部信息，為應用大對象。）

他們的引用關系為：

Finalizer -> ZstdJNIDirectByteBufCompressor <-> DefaultInvocation。

其中 ZstdJNIDirectByteBufCompressor 和 DefaultInvocation 有高達 1604 個，占用內存超 704M，占已使用堆內存的 77%，但之前并沒有這些對象。

???【Finalizer 問題】分析

哪來這么多 Finalizer 對象，和 GC 耗時增長有什么關系？

要想知道 Finalizer 對象是什么，我們首先需要了解 JVM 的 finalize() 方法：

finalize() 方法定義在 Object 類中，對于實現了 finalize() 的對象，當垃圾回收器確定該對象沒有任何引用時，就會調用其 finalize()。

筆者建議大家盡量避免使用它，因為它并不能等同于 C 和 C++ 語言中的析構函數，而是 Java 剛誕生時為了使傳統 C、C++ 程序員更容易接受 Java 所做出的一項妥協。它的運行代價高昂，不確定性大，無法保證各個對象的調用順序，如今已被官方明確聲明為不推薦使用的語法。有些教材中描述它適合做“關閉外部資源”之類的清理性工作，這完全是對 finalize() 方法用途的一種自我安慰。finalize() 能做的所有工作，使用 try-finally 或者其他方式都可以做得更好、更及時，所以筆者建議大家完全可以忘掉 Java 語言里面的這個方法。

--《深入理解 JVM》

多數同學對 finalize 方法的了解，可能都來自于以上這段話，知道其 “運行代價高昂”，“不推薦使用” ，那它到底會對我們應用產生什么影響？

JVM 是如何執行 finalize() 的？

JVM 在加載類的時候，會去識別該類是否實現了 finalize() ；若是，則標記出該類為“ finalize class”。
在創建 “finalize Class” 對象時，會調用 Finalizer#register()，在該方法中創建一個 Finalizer 對象，Finalizer 對象會引用原始對象，然后將其注冊到名為 unfinalized 的全局隊列中（保證 Finalizer 對象及其引用的原始對象一直可達，以確保在被 GC 前，其 finalize() 能被執行）。

在一次 GC時，JVM 判斷原始對象除了 Finalizer 對象引用之外沒有其他對象引用之后，就把 Finalizer 對象從 “unfinalized” 隊列中取出，加入到 “Finalizer queue” 中。
JVM 在啟動時，會啟動一個“finalize”線程，該線程會一直從“Finalizer queue”中取出對象，然后執行原始對象中的 finalize()。

在完成步驟 4 后，Finalizer 對象以及其引用的原始對象，再無其他引用，屬于不可達對象，再次 GC 的時候他們將會被回收掉。（如果在 finalize() 使該對象重新可達，再次 GC 該對象不會被回收，即 finalize() 方法是對象逃脫死亡 (GC) 命運的最后一次機會）。

使用 finalize() 帶來哪些影響？

創建一個實現 finalize() 的對象時，需要額外創建其 Finalizer 對象并且注冊到隊列中，因此需要額外的內存空間，且創建時間長于普通對象創建。
相比普通對象，實現 finalize() 的對象生存周期更長，至少需要兩次 GC 才可被回收。
在 GC 時需要對實現 finalize() 的對象做特殊處理（比如 Finalizer 對象的出隊入隊操作等）， GC 耗時更長。
因為 finalize 線程優先級比較低，若 CPU 繁忙，可能會導致 “ Finalizer queue” 有積壓，在經歷多次 YGC 之后原始對象及其 Finalizer 對象就會進入 old 區域，那么這些對象只能等待 FGC 才能被 GC。

總的來說，使用 finalize() 方法本身會加重系統負擔、嚴重影響 GC 并且無法保證 finalize 的調用時機，其應用場景也僅僅是防止資源泄漏，finalize() 能做的所有工作，使用 try-finally 或者其他方式都可以做得更好、更及時，所以我們還是忘記它的存在吧。

???【Finalizer 問題】解決

最佳實踐：

盡可能避免使用 finalize 機制。若實在無法避免，也應盡量避免其引用大對象。

JDK 18 中已經棄用 finalize 機制以在未來版本中刪除。詳見：Deprecate?Finalization?for?Removal（地址：https://openjdk.org/jeps/421）

在我們的 ZSTD 場景下，由于 zstd-jni 將 finalize() 作為堆外資源的兜底清理手段，因此我們斷開其對應用大對象的引用后，耗時翻倍的問題被成功解決。

我們的測試應用單機極限 QPS 較低（300），Finalizer 只要不引用大對象，對 GC 的影響不大；但在更高 QPS 場景下，Finalizer 對 GC 的影響會更加凸顯。

我們在另一線上應用使用 ZSTD 壓縮，在單機 QPS 1000 時，比起使用 NoFinalizer 的 Zstd Compressor，使用 Finalizer 的 Zstd Compressor GC 耗時漲了近 10 倍。

因此，我們最終決定直接使用 NoFinalizer 的 Zstd Compressor。

Netty ByteBuf 內存泄漏

???現象

為了優化 GC，我們通過 Netty 的 DirectByteBuf 操作堆外內存，直接在堆外壓縮并響應。

但在性能壓測時，通過 Netty 的內存泄漏檢測工具，發現在極限情況下會產生內存泄漏，經過觀察，會伴隨著以下幾種現象：

施壓 QPS 達到單機極限，持續有 FGC 產生；
客戶端超時主動斷連，繼續往被關閉的 channel 里寫入內容失敗，會出現連接已關閉的報錯；
Netty 堆外內存滿；

???分析

Step 1 泄漏堆棧顯示泄漏對象為響應內容的 DirectByteBuf

Step 2 通過增加埋點追溯業務代碼中可能的泄漏點，發現在寫給 netty ChannelOutboundHandler pipeline 之前，是沒有泄漏的。

Step 3 排查聚焦在 netty 的 ChannelOutboundHandler pipeline，排查我們自己實現的 ChannelOutboundHandler 內部也并未有泄漏。

Step 4 進一步分析 netty 內存泄漏檢測的堆棧，發現泄漏內存的最后訪問點有 netty 框架內部代碼，所以猜測泄漏可能是框架執行過程中產生。

Step 5 進一步分析 netty 寫出響應的代碼。

我們調用 netty 的 AbstractChannel#writeAndFlush(java.lang.Object) 寫出內容，會從 pipeline 的最后一個節點執行，最終進入到 next.invokeWriteAndFlush(m, promise)。

invokeHandler() 會檢查 handler 的狀態（如下圖），確認其是否可被執行。若 handler 被認為不可執行，則會直接嘗試執行下一個 handler （如 1 中圖）。

嘗試追溯 handlerState 的更新。發現當 channel 被 deregister 后（連接關閉）， pipeline 所有中間 handler 的狀態都會被置為 REMOVE_COMPLETE，即不可執行，這樣后續再寫入的消息都不會再進入到這些 handler 里了。（泄漏就是從這里開始）

setRemoved:911, AbstractChannelHandlerContext (io.netty.channel)
callHandlerRemoved:950, AbstractChannelHandlerContext (io.netty.channel)
callHandlerRemoved0:637, DefaultChannelPipeline (io.netty.channel)
destroyDown:876, DefaultChannelPipeline (io.netty.channel)
destroyUp:844, DefaultChannelPipeline (io.netty.channel)
destroy:836, DefaultChannelPipeline (io.netty.channel)
access$700:46, DefaultChannelPipeline (io.netty.channel)
channelUnregistered:1392, DefaultChannelPipeline$HeadContext (io.netty.channel)
invokeChannelUnregistered:198, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelUnregistered:184, AbstractChannelHandlerContext (io.netty.channel)
fireChannelUnregistered:821, DefaultChannelPipeline (io.netty.channel)
run:839, AbstractChannel$AbstractUnsafe$8 (io.netty.channel)
safeExecute$$$capture:164, AbstractEventExecutor (io.netty.util.concurrent)
safeExecute:-1, AbstractEventExecutor (io.netty.util.concurrent)- Async stack trace
addTask:-1, SingleThreadEventExecutor (io.netty.util.concurrent)
execute:825, SingleThreadEventExecutor (io.netty.util.concurrent)
execute:815, SingleThreadEventExecutor (io.netty.util.concurrent)
invokeLater:1042, AbstractChannel$AbstractUnsafe (io.netty.channel)
deregister:822, AbstractChannel$AbstractUnsafe (io.netty.channel)
fireChannelInactiveAndDeregister:782, AbstractChannel$AbstractUnsafe (io.netty.channel)
close:765, AbstractChannel$AbstractUnsafe (io.netty.channel)
close:620, AbstractChannel$AbstractUnsafe (io.netty.channel)
close:1352, DefaultChannelPipeline$HeadContext (io.netty.channel)
invokeClose:622, AbstractChannelHandlerContext (io.netty.channel)
close:606, AbstractChannelHandlerContext (io.netty.channel)
close:472, AbstractChannelHandlerContext (io.netty.channel)
close:957, DefaultChannelPipeline (io.netty.channel)
close:244, AbstractChannel (io.netty.channel)
close:92, DefaultHttpStream (com.alibaba.xxx.xxx.xxx.inbound.http)
onRequestReceived:111, DefaultHttpStreamTest$getHttpServerRequestListener$1 (com.alibaba.xxx.xxx.xxx.inbound.http)
onHttpRequestReceived:53, HttpServerStreamHandler (com.alibaba.xxx.xxx.xxx.inbound.http.server)
channelRead:44, HttpServerStreamHandler (com.alibaba.xxx.xxx.xxx.inbound.http.server)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:286, IdleStateHandler (io.netty.handler.timeout)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:103, MessageToMessageDecoder (io.netty.handler.codec)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:103, MessageToMessageDecoder (io.netty.handler.codec)
channelRead:111, MessageToMessageCodec (io.netty.handler.codec)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:103, MessageToMessageDecoder (io.netty.handler.codec)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:324, ByteToMessageDecoder (io.netty.handler.codec)
channelRead:296, ByteToMessageDecoder (io.netty.handler.codec)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:357, AbstractChannelHandlerContext (io.netty.channel)
channelRead:1410, DefaultChannelPipeline$HeadContext (io.netty.channel)
invokeChannelRead:379, AbstractChannelHandlerContext (io.netty.channel)
invokeChannelRead:365, AbstractChannelHandlerContext (io.netty.channel)
fireChannelRead:919, DefaultChannelPipeline (io.netty.channel)
read:166, AbstractNioByteChannel$NioByteUnsafe (io.netty.channel.nio)
processSelectedKey:719, NioEventLoop (io.netty.channel.nio)
processSelectedKeysOptimized:655, NioEventLoop (io.netty.channel.nio)
processSelectedKeys:581, NioEventLoop (io.netty.channel.nio)
run:493, NioEventLoop (io.netty.channel.nio)
run:986, SingleThreadEventExecutor$4 (io.netty.util.concurrent)
run:74, ThreadExecutorMap$2 (io.netty.util.internal)
run:748, Thread (java.lang)

可以看到 pipeline 中間 handler 被跳過了，其中也包括我們自己實現的 handler。分析下圖代碼，我們寫給 netty pipeline 的 msg 實際是我們自己包裝的 HttpObject，是在我們自己實現的 handler 里才轉成 netty 的 ReferenceCounted 對象的，由于 handler 被跳過導致該對象并沒有被轉換成 ReferenceCounted，所以即使 netty 有兜底的 release ，實際并沒有產生作用，HttpObject 內部的 ByteBuf 并未真正被釋放，此時產生泄漏。

???解決

【最佳實踐】在寫入 channel 之前，一定要先判斷 channel 是否 active 。
【最佳實踐】我們寫給 netty 的內容，最好是實現了 ReferenceCounted 接口的對象，這樣即使 netty 內部出現不預期情況，我們也可以利用 netty 的兜底 release 來釋放資源。
控制 ByteBuf 的使用范圍。在我們的場景里，可以將壓縮的實現下移到 netty 層，但上述 1、2 也同樣必須改進才能確保不出問題。
好處：對 ByteBuf 的操作可以收口在傳輸層，應用層編程難度大大降低。
壞處：考慮到可能存在多個傳輸層 (http server) 的實現，壓縮邏輯可能需要根據堆內堆外做兩份實現，每個 http server 都需要對接。

堆外內存