java - 为什么 MxBean 中的堆使用与堆转储中的不同？

Question

我有一个 Java 应用程序似乎正在泄漏内存，但我无法找到确定根本原因的方法。而且我从 MemoryMXBean 获得的堆内存使用情况似乎与我从堆转储 获得的堆内存使用情况有很大不同。

根据:

((double) memoryMXBean.getHeapMemoryUsage().getUsed()) / (1024 * 1024)

随着时间的推移，堆内存使用量从开始时的 55MB 增加到运行 4 天后的 90MB。

但是一开始收集的heap dump是28.7MB，运行4天后是34MB。

              MemoryMXBean  heap_dump
beginning             55MB     28.7MB
after 4 days          90MB       34MB

该应用程序是基于工作的。这意味着它大部分时间都处于空闲状态，直到日常工作开始产生工作量。可以看出，堆内存使用率从55MB左右开始，每天攀升一次，直到应用重启。在几天未部署后的高峰期，堆使用量可能高达 110MB。

以下是应用程序的启动方式:

jdk1.8/bin/java
  -Dpid=29816
  -Dscript=someApp
  -Djdbc.drivers=someDriver
  -Xmx256M
  -Duser.timezone=UTC
  -Djavax.net.ssl.trustStore=someTrustStore.jks
  -Djavax.net.ssl.trustStorePassword=*****
  -XX:+PrintGCDetails
  -XX:+PrintGCDateStamps
  -XX:+PrintTenuringDistribution
  -XX:+PrintGCCause
  -XX:+PrintGCApplicationStoppedTime
  -XX:+HeapDumpOnOutOfMemoryError
  -XX:HeapDumpPath=/tmp/output/logs
  -Xloggc:/tmp/output/logs/someApp-gclog
  package.SomeApp

我通过以下命令从服务器获取堆转储:

jmap -dump:format=b,file=<FILENAME> <PID>

我的问题是:

1. 为什么来自 mxbean 的堆使用数与堆转储中的不一致？
2. 甚至 mxbean 所说的差异 (90 - 55 = 35MB) 与堆转储中的数字差异 (34 - 28.7 = 5.3MB) 也不一致，为什么？

应用程序启动后的堆转储在堆转储中有以下信息:

Used heap dump  28.7 MB
Number of objects   594,867
Number of classes   8,929
Number of class loaders 84
Number of GC roots  2,710
Format  hprof
JVM version 
Time    2:30:45 PM PDT
Date    Apr 8, 2019
Identifier size 64-bit
Compressed object pointers  true
File path   /tmp/20190408_lessThanOneDay_6168.hprof
File length 71,387,808

运行了 4 天的堆转储是:

Used heap dump  34 MB
Number of objects   677,239
Number of classes   9,162
Number of class loaders 92
Number of GC roots  2,859
Format  hprof
JVM version 
Time    9:00:15 AM PDT
Date    Apr 8, 2019
Identifier size 64-bit
Compressed object pointers  true
File path   /tmp/20190408_4days_19324.hprof
File length 120,467,694

Answer 1

堆转储格式不包含完整信息，例如关于内存填充并强制显示工具猜测。参见 What Heap Dumps Are Lying To You About深入探讨问题详细信息的文章显示工具将显示不同的估计值。总结起来就是:

• Most of the HPROF-based tools have problems with deducing the actual instance footprint; the special crafted example in this article shows >25% difference between actual and estimated instance size, which can lead the analysis in the wrong direction. However, the cases like that are rare, and most analyses should be fine, especially when dealing with gigabytes worth of memleaks.
• There were talks to get HPROF fixed up, but they winded down with the bottom-line "we just need a better format", because tools already have reservations about what HPROF actually means. JEP, anyone?
• Online tools are the best to figure out actual instance footprint. Use JOL, run it via command-line, embed it into your projects. Don’t you ever, ever guess the object layouts by looking at the heap dumps.