Как интерпретировать вывод из "jmap -permstat"?

Я пытаюсь устранить утечку permgen и хотел бы попросить вас рассказать о том, как интерпретировать вывод из jmap -permstat.

Скажем, что у меня есть отчет jmap -permstat, например:

class_loader        classes  bytes     parent_loader       alive?  type

<bootstrap>            4791  25941568                null   live  <internal>
0x00000007203ed508        0         0  0x00000007203ed228   dead  com/example/object/[email protected]
0x000000071dc17620        1      3056  0x0000000705e692a8   dead  sun/reflect/[email protected]
0x000000071f26a898        0       100                null   dead  com/example/object/[email protected]
0x0000000721c6dba0        0       100                null   dead  com/example/object/[email protected]
0x000000071e36df20        0       100                null   dead  com/example/object/[email protected]
0x000000072157c1b8      339   2069112  0x000000072157b8d8   dead  com/example/object/[email protected]
0x00000007128b7830        1      1912  0x0000000700056db8   dead  sun/reflect/[email protected]
0x0000000707634360        1      3088  0x0000000700056db8   dead  sun/reflect/[email protected]

Здесь, как бы я интерпретировал вышеприведенный вывод, пожалуйста, исправьте все ошибки, которые я сделал при этом.

Значения в столбце "тип" не уникальны. Мы видим несколько объектов, которые появляются три раза. Однако значение class_loader уникально для всех трех; поэтому каждый из них представляет собой отдельный объект, занимающий пространство перггенов. В этом примере каждый из них занимает 100 байт; поэтому 300 байтов пространства перменов занимают объекты типа SomeClassLoader.

Если значение классов отличное от нуля, то этот объект должен быть каким-то классом-загрузчиком, и это относится к числу классов, которые он ссылается. (Примечание: в фактическом файле эти три объекта имеют нули в столбце байтов, я добавил значения для этого примера. На практике я предполагаю, что если в столбце классов есть 0, значение байта может быть любым, кроме нуля.)

Если живое значение "мертвое", это означает, что объект готов к сбору мусора, но JVM этого не делает. Там будет отдельное обсуждение причин, почему это может быть так.

Если в столбце parent_loader есть значение, то это объект, на который ссылается другой загрузчик классов, и не может быть мусором, собранным до тех пор, пока этот объект не будет собран.

Наконец: 1) Если я вижу 500 строк в отчете, все списки одного типа, 2), но они перечисляют разные значения class_loader, 3), то я могу добавить значения в столбец байтов 4), и это будет точно представлять, сколько пространства пергменов занято объектами этого типа.

Это правильно? Спасибо!

ОТВЕТЫ

Ответ 1

Из этого запись в блоге:

Для каждого объекта загрузчика класса печатаются следующие данные:

  • (class_loader). Адрес объекта загрузчика класса - при снимке при запуске утилиты.
  • (classes) Количество загруженных классов (определяется этим загрузчиком с помощью метода (java.lang.ClassLoader.defineClass).
  • (байты) Примерное количество байтов, потребляемых метаданными для всех классов, загруженных этим загрузчиком классов.
  • (parent_loader). Адрес загрузчика родительского класса (если есть).
  • (живой?) Индикация "живая" или "мертвая" - указывает, будет ли объект-загрузчик собирать мусор в будущем.
  • (type) Имя класса этого загрузчика классов.

Постоянное поколение не содержит простые объекты, а метаданные класса (см. Что действительно означает PermGen?). Итак, переписывая ваше выражение:

Наконец: 1) Если я вижу 500 строк в отчете, что все перечисляют один и тот же тип, 2), но они перечисляют разные значения class_loader, 3), тогда я могу добавить значения в столбце 4 байт), и это будет точно укажите, сколько пространства пергменов занято мета-данными для всех классов, загружаемых объектами класса loader того же класса (SomeClassLoader).

"Сохраненная куча", показанная инструментом Eclipse Memory Analyzer, относится к памяти кучи (молодой + старой), потребляемой объектами.

Постоянное поколение находится за пределами кучи (см. fooobar.com/info/349310/...) и рассматривает метаданные класса.