如何调试JVM上本机内存中的泄漏？

Question

我们有一个在Mule上运行的Java应用程序。我们已将XMX值配置为6144M，但通常会看到整体内存使用率不断攀升。前几天，它已接近20 GB，然后我们主动重新启动它。

Thu Jun 30 03:05:57 CDT 2016
top - 03:05:58 up 149 days,  6:19,  0 users,  load average: 0.04, 0.04, 0.00
Tasks: 164 total,   1 running, 163 sleeping,   0 stopped,   0 zombie
Cpu(s):  4.2%us,  1.7%sy,  0.0%ni, 93.9%id,  0.2%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  24600552k total, 21654876k used,  2945676k free,   440828k buffers
Swap:  2097144k total,    84256k used,  2012888k free,  1047316k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3840 myuser  20   0 23.9g  18g  53m S  0.0 79.9 375:30.02 java

jps命令显示：

10671 Jps
3840 MuleContainerBootstrap

jstat命令显示：

 S0C    S1C    S0U    S1U      EC       EU        OC         OU       PC     PU    YGC     YGCT    FGC    FGCT     GCT
37376.0 36864.0 16160.0  0.0   2022912.0 1941418.4 4194304.0   445432.2  78336.0 66776.7    232    7.044  17     17.403   24.447

启动参数为（敏感位已更改）：

3840 MuleContainerBootstrap -Dmule.home=/mule -Dmule.base=/mule -Djava.net.preferIPv4Stack=TRUE -XX:MaxPermSize=256m -Djava.endorsed.dirs=/mule/lib/endorsed -XX:+HeapDumpOnOutOfMemoryError -Dmyapp.lib.path=/datalake/app/ext_lib/ -DTARGET_ENV=prod -Djava.library.path=/opt/mapr/lib -DksPass=mypass -DsecretKey=aeskey -DencryptMode=AES -Dkeystore=/mule/myStore -DkeystoreInstance=JCEKS -Djava.security.auth.login.config=/opt/mapr/conf/mapr.login.conf -Dmule.mmc.bind.port=1521 -Xms6144m -Xmx6144m -Djava.library.path=%LD_LIBRARY_PATH%:/mule/lib/boot -Dwrapper.key=a_guid -Dwrapper.port=32000 -Dwrapper.jvm.port.min=31000 -Dwrapper.jvm.port.max=31999 -Dwrapper.disable_console_input=TRUE -Dwrapper.pid=10744 -Dwrapper.version=3.5.19-st -Dwrapper.native_library=wrapper -Dwrapper.arch=x86 -Dwrapper.service=TRUE -Dwrapper.cpu.timeout=10 -Dwrapper.jvmid=1 -Dwrapper.lang.domain=wrapper -Dwrapper.lang.folder=../lang

从jps中添加“容量”项表明，只有6144m用于Java堆。其余的内存在哪里使用？堆栈内存？本机堆？我什至不知道如何进行。

如果任其继续增长，它将消耗系统上的所有内存，并且我们最终将看到系统冻结并抛出交换空间错误。

我还有另一个正在成长的过程。目前常驻内存约为11g。

pmap 10746 > pmap_10746.txt
cat pmap_10746.txt | grep anon | cut -c18-25 | sort -h | uniq -c | sort -rn | less

Top 10 entries by count:
    119     12K
    112   1016K
     56      4K
     38 131072K
     20  65532K
     15 131068K
     14  65536K
     10    132K
      8  65404K
      7    128K


Top 10 entries by allocation size:
     1 6291456K
      1 205816K
      1 155648K
     38 131072K
     15 131068K
      1 108772K
      1  71680K
     14  65536K
     20  65532K
      1  65512K

And top 10 by total size:
Count   Size    Aggregate
1   6291456K    6291456K
38  131072K 4980736K
15  131068K 1966020K
20  65532K  1310640K
14  65536K  917504K
8   65404K  523232K
1   205816K 205816K
1   155648K 155648K
112 1016K   113792K

这似乎是在告诉我，因为Xmx和Xms设置为相同的值，所以为Java堆分配了6291456K。其他分配不是Java堆内存。这些是什么？他们正在分配相当大的块。

Answer 1

扩展彼得答案的更多细节。

您可以从 VisualVM 中获取二进制堆转储（右键单击左侧列表中的进程，然后单击堆转储 - 不久后它将出现在正下方）。如果您无法将 VisualVM 连接到 JVM，您还可以使用以下命令生成转储：

jmap -dump:format=b,file=heap.hprof $PID

然后复制该文件并使用 Visual VM 打开它（“文件”、“加载”、选择“堆转储类型”、找到该文件。）

正如 Peter 指出的，泄漏的一个可能原因可能是未收集 DirectByteBuffer（例如：另一个类的某些实例没有正确取消引用缓冲区，因此它们永远不会被 GC）。

要确定这些引用的来源，您可以使用 Visual VM 检查堆并在“类”选项卡中查找 DirectByteByffer 的所有实例。找到DBB类，右键单击，转到实例视图。

这将为您提供实例列表。您可以单击其中一个，查看谁在为每一个保留参考：

请注意底部窗格，我们有 Cleaner 类型的“referent”和 2 个“mybuffer”。这些将是其他类中引用我们深入研究的 DirectByteBuffer 实例的属性（如果您忽略 Cleaner 并专注于其他类，应该没问题）。

从此时起，您需要根据您的申请继续操作。

获取 DBB 实例列表的另一种等效方法是从 OQL 选项卡。这个查询：

select x from java.nio.DirectByteBuffer x

给我们提供了与之前相同的列表。使用 OQL 的好处是您可以执行更复杂的查询。例如，这获取保留对 DirectByteBuffer 的引用的所有实例：

select referrers(x) from java.nio.DirectByteBuffer x