Почему использование кучи из MxBean отличается от использования в дампе кучи?

Question

У меня есть приложение Java, которое, кажется, утечка памяти, но я не смог найти способ определить основную причину. И использование кучи памяти, которое у меня было из MemoryMXBean , похоже, совсем не похоже на то, что я получил из дампа кучи .

Согласно:

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

Использование динамической памяти со временем увеличивается с 55 МБ в начале до 90 МБ после 4 дней работы.

Но дамп кучи, собранный в начале, составлял 28,7 МБ и 34 МБ при работе в течение 4 дней.

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

Приложение основано на работе. Это означает, что он большую часть времени бездействует до тех пор, пока не начнется ежедневная работа, в результате которой создается рабочая нагрузка. Как можно видеть, использование динамической памяти начинается с 55 МБ, каждый день она поднимается до тех пор, пока приложение не будет перезапущено. На пике после нескольких дней без развертывания использование кучи может достигать 110 МБ.

Вот как запускается приложение:

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 = 35 МБ), не согласуется с разницей между числом в дампах кучи (34 - 28,7 = 5,3 МБ), почему?

Дамп кучи приложения после запуска содержал следующую информацию в дампе кучи:

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

Формат дампа кучи не содержит полной информации, например, о заполнении памяти, и заставляет средство отображения угадывать.См. Что за куча дампов лежит на вас О статье , в которой подробно рассматриваются проблемы, показывающие, что инструменты будут отображать разные оценки.Сумма может быть:

• У большинства инструментов на основе HPROF возникают проблемы с определением фактического отпечатка экземпляра;Специальный созданный пример в этой статье показывает> 25% разницу между фактическим и предполагаемым размером экземпляра, что может привести к неверному направлению анализа.Тем не менее, подобные случаи редки, и большинство анализов должны быть хорошими, особенно когда речь идет о гигабайтах мемликов.
• Были разговоры, чтобы исправить HPROF, но они сводились к итоговой сумме "нам просто нужен лучший формат », потому что у инструментов уже есть оговорки относительно того, что фактически означает HPROF.JEP, кто-нибудь?
• Онлайн-инструменты - это лучшее, чтобы выяснить фактическую площадь экземпляра.Используйте JOL, запустите его через командную строку, вставьте в свои проекты.Не пытайтесь угадать расположение объектов, глядя на дампы кучи.