JVM內存泄漏之MaxDirectMemory

背景

樓主線上使用的是docker容器，發(fā)現有比較多的容器退出，container exited with a non-zero exit code 137；google之后發(fā)現應該是因為進程oom導致的；https://www.containiq.com/post/exit-code-137；
樓主的配置：docker 12G 16Core；jvm配置 -Xmx9G ，查遍程序的日志沒發(fā)現oom的錯誤，但docker的日志里也沒發(fā)現明顯的錯誤（郁悶）。

嘗試思路

1.開啟了jvm的 NMT 來搜集信息

開啟方式：-XX:NativeMemoryTracking=detail
使用方式參見別人的文檔：https://cloud.tencent.com/developer/article/1406522；或者官方文檔https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr007.html#BABIIIAC
說下我結論： 對比了程序啟動和一天之后的內存使用，heap，thread，code，gc等幾個大模塊的內存使用都比較正常，只有Internal模塊內存增長不太對（啟動之初幾百M，第二天2.6G），可以確定的是Internal模塊使用的是堆外內存；

Native Memory Tracking:

Total: reserved=14379MB +376MB, committed=13186MB +377MB

-                 Java Heap (reserved=8192MB, committed=8192MB)
                           (mmap: reserved=8192MB, committed=8192MB)

-                     Class (reserved=1137MB, committed=126MB)
                           (classes #19403 +9)
                           (malloc=3MB #42664 +262)
                           (mmap: reserved=1134MB, committed=123MB)

-                    Thread (reserved=1637MB +45MB, committed=1637MB +45MB)
                           (thread #1625 +45)
                           (stack: reserved=1630MB +45MB, committed=1630MB +45MB)
                           (malloc=5MB #8146 +225)
                           (arena=2MB #3236 +90)

-                      Code (reserved=258MB, committed=93MB +1MB)
                           (malloc=15MB #21645 +120)
                           (mmap: reserved=244MB, committed=78MB +1MB)

-                        GC (reserved=477MB +6MB, committed=477MB +6MB)
                           (malloc=141MB +6MB #175565 +134)
                           (mmap: reserved=336MB, committed=336MB)

-                  Compiler (reserved=4MB, committed=4MB)
                           (malloc=3MB #4926 +113)

-                  Internal (reserved=2619MB +325MB, committed=2619MB +325MB)
                           (malloc=2619MB +325MB #179961 +793)

-                    Symbol (reserved=26MB, committed=26MB)
                           (malloc=24MB #253198 +42)
                           (arena=2MB #1)

-    Native Memory Tracking (reserved=12MB, committed=12MB)
                           (malloc=1MB #11519 +2941)
                           (tracking overhead=11MB)

-               Arena Chunk (reserved=1MB, committed=1MB)
                           (malloc=1MB)

-                   Unknown (reserved=16MB, committed=0MB)
                           (mmap: reserved=16MB, committed=0MB)

[0x00007fc68e2ad16a] Unsafe_AllocateMemory+0xfa
[0x00007fc67a40aea8]
                            (malloc=1684MB type=Internal +320MB #1665 +29)
# 重要： 注意此處internal 分配了1.6G，跟我設置的baseline比較增長了320M，分配次數29次；

[0x00007fc68e24fac5] ObjectSynchronizer::omAlloc(Thread*)+0x6c5
[0x00007fc68e24fda5] ObjectSynchronizer::inflate(Thread*, oopDesc*)+0x255
[0x00007fc68e250ec6] ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*)+0x76
[0x00007fc68e1dfc0c] SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0x6c
                            (malloc=11MB type=Internal +2MB #497 +76)

[0x00007fc68e24fac5] ObjectSynchronizer::omAlloc(Thread*)+0x6c5
[0x00007fc68e24fbb0] ObjectSynchronizer::inflate(Thread*, oopDesc*)+0x60
[0x00007fc68e250ec6] ObjectSynchronizer::fast_enter(Handle, BasicLock*, bool, Thread*)+0x76
[0x00007fc68e1dfc0c] SharedRuntime::complete_monitor_locking_C(oopDesc*, BasicLock*, JavaThread*)+0x6c
                            (malloc=16MB type=Internal +3MB #756 +138)

注意上面這一段：
[0x00007fc68e2ad16a] Unsafe_AllocateMemory+0xfa <--- 分配內存的調用方法
[0x00007fc67a40aea8]
(malloc=1684MB type=Internal +320MB #1665 +29)
意思是internal 分配了1.6G(剛啟動才幾百兆)，跟我設置的baseline比較增長了320M，分配次數29次；
從調用方可知Unsafe_AllocateMemory 這個方法申請的；查了我的程序，沒有發(fā)現調用的地方；擴大范圍搜索依賴的三方庫，發(fā)現couchbase的client依賴了netty，而netty作為一個優(yōu)秀的io框架，為了保證性能，有在操作direct memory.

至此：可以大膽猜測是它造成的，雖然沒有確鑿證據，但是只有它在調用unsafe.allocateMemory .
于是去查了下direct memory的默認大小，如下：

-XX:MaxDirectMemorySize
-XX:MaxDirectMemorySize=size 用于設置 New I/O (java.nio) direct-buffer allocations 的最大大小，size 的單位可以使用 k/K、m/M、g/G；如果沒有設置該參數則默認值為 0，意味著 JVM 自己自動給 NIO direct-buffer allocations 選擇最大大小，從代碼 java.base/jdk/internal/misc/VM.java 中可以看到默認是取的 Runtime.getRuntime ().maxMemory ()

在沒有配置的情況下，最大等于Xmx，確實比較危險。

2.尋找佐證

發(fā)現一篇非常有價值的博客，源地址：https://www.cnblogs.com/dengq/p/13687423.html ，主要內容貼上：

1) Java_JVM參數-XX:MaxDirectMemorySize

JVM堆內存大小可以通過-Xmx來設置，同樣的direct ByteBuffer可以通過-XX:MaxDirectMemorySize來設置，此參數的含義是當Direct ByteBuffer分配的堆外內存到達指定大小后，即觸發(fā)Full GC。注意該值是有上限的，默認是64M，最大為sun.misc.VM.maxDirectMemory()，在程序中中可以獲得-XX:MaxDirectMemorySize的設置的值。
1.2.2、沒有配置MaxDirectMemorySize的，因此MaxDirectMemorySize的大小即等于-Xmx
1.2.3、Direct Memory的回收機制，Direct Memory是受GC控制的
1.2.4、對于使用Direct Memory較多的場景，需要注意下MaxDirectMemorySize的設置，避免-Xmx + Direct Memory超出物理內存大小的現象

2)用JDK8的一定要配置：-Xms -Xmx -XX:MaxDirectMemorySize，【Xmx +（加） MaxDirectMemorySize】的值不能超過docker的最大內存，不然docker內存占滿了會被oomkill掉；**

 沒配置參數導致的問題以及處理參考：[http://hellojava.info/?tag=maxdirectmemorysize](http://hellojava.info/?tag=maxdirectmemorysize) （[物理內存耗盡、CMS GC碎片造成RT慢的兩個Case](http://hellojava.info/?p=188)）
分析：[https://my.oschina.net/go4it/blog/3029481](https://my.oschina.net/go4it/blog/3029481)

其他：看到一個有用的java排障地址，收藏下https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/index.html

?著作權歸作者所有,轉載或內容合作請聯系作者
【社區(qū)內容提示】社區(qū)部分內容疑似由AI輔助生成，瀏覽時請結合常識與多方信息審慎甄別。
平臺聲明：文章內容（如有圖片或視頻亦包括在內）由作者上傳并發(fā)布，文章內容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關閱讀更多精彩內容

友情鏈接更多精彩內容