導讀

本文記錄最近一例Java應用OOM問題的排查過程，希望可以給遇到類似問題的同學提供參考。

前言：此文記錄最近一例Java應用OOM問題的排查過程，希望可以給遇到類似問題的同學提供參考。在本地集團，大多數情況下Java堆的大小會設置為容器規格的50%～70%，但如果你設置為50%時還是遇到了OS OOM的問題，會不會無法忍受進而想要知道這是為什么？沒錯，我也有一樣的好奇。

背景

某核心應用的負責同學反饋應用存在少量機器OOM被OS kill的問題。看sunfire監控信息，的確如此。

初步收集到的信息：

容器內存=8G，Java 11，G1 GC=4G，MaxDirectMemorySize=1G。詳見下圖：

業務同學已經做過Java dump，可以看到堆外對象幾乎沒有，堆內的使用量也不大，<3G。上機器查看Java進程的內存使用量的確很大：

通過目前掌握到的信息來看，4G（Java堆）+1G（堆外）+512M（元空間）+250M（CodeCache）+其它，離6.8G還是有不少差距，無法簡單的明確原因，需要深入排查分析了。

問題結論

省流版

中間件中多個不同的ClassLoader加載了多個netty的io.netty.buffer.PooledByteBufAllocator，每一個都有1G的內存配額，所以存在實際使用的堆外內存超出1G限制的問題。

通過Arthas可以看到存在這個類的7個不同的實例：

而其中rocketmq-client的這一個，已經基本用完1G的內存（其它幾個使用量大多在100多M的樣子）：

詳細版

中間件中多個不同的ClassLoader加載了多個netty的io.netty.buffer.PooledByteBufAllocator，每個Allocator都用自己的計數器在限制堆外內存的使用量，這個限制值大多數情況下取值至MaxDirectMemorySize，所以會存在無法限制堆外內存使用量在1G以內的問題。（這個設計是否合理，還請中間件的同學幫忙補充了）

這個應用是餓了么彈內的應用，io.netty.buffer.PooledByteBufAllocator，有7個ClassLoader加載了它，分別是：

sentinel's ModuleClassLoader、rocketmq-client's ModuleClassLoader、tair-plugin's ModuleClassLoader、hsf's ModuleClassLoader、XbootModuleClassLoader、pandora-qos-service's ModuleClassLoader、ele-enhancer's ModuleClassLoader。

相比彈內應用的4個（數據來自淘天集團的核心應用ump2，如下圖），多了3個。

在Java8，以及Java11中（JVM參數設置了-Dio.netty.tryReflectionSetAccessible=true過后），netty會直接使用unsafe的方法申請堆外內存，不通過Java的DirectMemory分配API，所以通過監控看不到堆外內存的占用量，也不受JVM MaxDirectMemorySize的管控。

查看DirectByteBuffer實現代碼可以發現，它限制MaxDirectMemorySize的方法是在Java層（代碼標記處1），實際上在JVM底層是沒有任何限制的，netty是直接用了這里代碼標記處2的API分配內存。

排查過程

1.1.通過NativeMemoryTracking看Native內存的占用分布

通過在JVM參數上加上-XX:NativeMemoryTracking=detail，就可以打印出詳細的內存分類的占用信息了，觀察了一整天，發現主要的可疑變化是在Other部分，即堆外的部分，如下圖。（ Java NMT的詳細使用可以參考相應的技術文章）

明明是限制的堆外1G，怎么超過了這么多。再多觀察一會，發現它還會繼續緩慢上漲的，最高達到接近1.5GB。這就和最開始查看Java進程的RSS占用對上了。

1.2.native內存泄漏了嗎

JVM使用什么native分配器

通過查看機器上安裝的JDK的信息，可以看到使用的是jemalloc的內存分配器。是不是它有泄漏、內存碎片、歸還不及時的問題？

網上搜索，發現的有一篇文章講的場景和我們這里的有一些類似。（https://blog.csdn.net/liulilittle/article/details/137535634）

嘗試重新下載jemalloc的源碼，并進行其參數的調整：

export MALLOC_CONF="dirty_decay_ms:0,muzzy_decay_ms:0"

觀察發現內存的占用量有少量的下降，但還是會超過1個G，看起來核心問題不在這里。

誰在分配內存

同時還通過perf工具監控了下調用內存分配的調用棧，想看看有什么線索沒有，然而并沒有什么線索。畢竟這個內存的增長比較緩慢，perf也不可能抓太長時間了，遂放棄這個思路。

sudo perf probe -x /opt/taobao/install/ajdk11_11.0.23.24/lib/libjemalloc.so.2 malloc

sudo perf record -e probe_libjemalloc:malloc -p `pidof java` -g -- sleep 10

內存里面裝了什么

通過 sudo pmap -x `pidof java` | sort -k 3 -n 命令查看進程的所有內存塊信息，如下圖示：

排除最大的4G的這一個（這是Java堆），以及內存標志帶x的兩個（可執行代碼標志，那是CodeCache），把其它的塊都dump下來，看看里面都放了啥，有沒有什么不平凡的。

使用gdb命令：gdb --batch --pid `pidof java` -ex "dump memory mem1.log 0x7f0109800000 0x7f0109800000+0x200000"

然后將dump下的內存以字符串的方式輸出觀察下：cat mem1.log | strings

如圖所示，發現里面大量的內容都和RocketMQ有關。不過我發現我早率了，這些dump內容我看了快一天，根本沒有發現什么不太對的地方，看起來都是正常的占用。（不過明顯能看出來這里面存了一堆消費者信息，表達的比較冗余）

求助JVM專家

還真是從入門到放棄，到這個時候已經沒啥信心啦。遂求助于JVM的專家毛亮，他給了大的方向，一是這里不太可能有native的內存泄漏，二是既然懷疑是堆外，把堆外內存減少一點看看情況，明確下是不是native內存分配器的回收特性就是這樣。往往native的內存分配器都有自己的管理策略，他會有自己的回收拐點，比應用看到的高一點是合理的。

的確，那么接下來的策略就是把MaxDirectMemeorySize調低到512M觀察下效果吧。

1.3.堆外內存調小影響業務了

在堆外內存從1G調小到512M過后，過了個周末，周一的時候業務同學就反饋，調小遇到問題了，存在MQ消息消費不及時而導致消息擠壓的問題。結合之前看到的native內存的信息，突然想到，MQ客戶端一定是占用了超過512M的內存，內心里出現了兩個問題：

1.MQ底層依賴netty，那么netty實際使用的內存是多少？以及這個內存占用量和native的堆外占用量是什么關系？

2.為啥Java的DirectMemory占用這么少，netty的內存占用似乎并沒有被看到，這是怎么回事？

帶著這兩個問題，查看了netty內存管理的核心類 io.netty.buffer.PooledByteBufAllocator，以及機器上啟動過程中打印出的信息。

結合這里面涉及的另一個核心類io.netty.util.internal.PlatformDependent，大概明白了這里面的邏輯，netty是直接使用（是有前提條件的，但這個應用通過JVM參數[-Dio.netty.tryReflectionSetAccessible=true]開啟了這個特性，這也是大多數應用上面的行為）UNSAFE.allocateMemory分配內存，完全繞過Java的直接內存API。然后它自己實現了內存占用空間的限制，這個值等于JVM參數中的MaxDirectMemorySize。到這里，似乎發現了曙光，莫非就是netty？（netty這么做的原因是為了不依賴JVM機制而加速內存的釋放，同時也是為了解決在堆外內存不足時JVM的糟糕的回收機制設計。）

1.4.Netty到底占用了多少內存

好在netty的類中有一個靜態變量是可以很容易的看到這個信息的：

io.netty.buffer.PooledByteBufAllocator#DEFAULT。

那么這個時候就是需要上機器去執行它了。Arthas是個不錯的工具，可以直接在機器執行表達式看任何靜態變量的值，并不需要我們改代碼然后去調用上面的對象做日志打印。

登錄機器后，通過命令查找netty Allocator的類定義：

sc -d io.netty.buffer.PooledByteBufAllocator

發現有不止一個Allocator，來自于不同的ClassLoader，以及不同的jar包。一共有7個。

然后一個一個的看他們實際占用的大小：

getstatic -c d5bc00 io.netty.buffer.PooledByteBufAllocator DEFAULT

然后把他們占用的內存逐項加起來，發現的確超過了1G，同時和前面通過NMT看到的Other類別的內存大小是比較吻合的。到這里大概就明確具體是怎么回事了，內存是netty用掉的。

1.5.業務應該怎么做呢

到目前為此，問題是明確了，但似乎并沒有什么太好的解法。一個是rocketmq-client的內存占用是不是太大了，有沒有什么可以優化的地方？（從前面看native內存看到的內容來看，還是有很大的優化空間的，一大堆地址信息都是以字符串的形式寫在內存里面），另一個是中間件的調整肯定是長期的，短期業務要怎么辦呢？

思考再三，短期來看只能是先讓業務把Java堆調小（通過Java dump以及JVM監控可以看出來堆的使用率并不高），來適應當前的現狀了。

至于堆外內存大小沒有限制住的問題，我感覺并不是中間件同學的預期之中的，這塊后面也找相關同學聊一聊。

后記

以后排查Java堆外內存過大的問題，優先看netty的占用。