JVM内存泄漏之MaxDirectMemory

背景

楼主线上使用的是docker容器，发现有比较多的容器退出，container exited with a non-zero exit code 137；google之后发现应该是因为进程oom导致的；https://www.containiq.com/post/exit-code-137；
楼主的配置：docker 12G 16Core；jvm配置 -Xmx9G ，查遍程序的日志没发现oom的错误，但docker的日志里也没发现明显的错误（郁闷）。

尝试思路

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 这个方法申请的；查了我的程序，没有发现调用的地方；扩大范围搜索依赖的三方库，发现couchbase的client依赖了netty，而netty作为一个优秀的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.寻找佐证

发现一篇非常有价值的博客，源地址：https://www.cnblogs.com/dengq/p/13687423.html ，主要内容贴上：

1) Java_JVM参数-XX:MaxDirectMemorySize

JVM堆内存大小可以通过-Xmx来设置，同样的direct ByteBuffer可以通过-XX:MaxDirectMemorySize来设置，此参数的含义是当Direct ByteBuffer分配的堆外内存到达指定大小后，即触发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