Сообщения журнала коллекции мусора Java

Ответ 1

Большая часть из них объясняется в Руководстве по настройке GC (которое вам все равно нужно прочитать).

Опция командной строки -verbose:gc приводит к тому, что информация о сборке кучи и мусора должна быть напечатана в каждой коллекции. Например, здесь выводится из большого серверного приложения:

[GC 325407K->83000K(776768K), 0.2300771 secs]
[GC 325816K->83372K(776768K), 0.2454258 secs]
[Full GC 267628K->83769K(776768K), 1.8479984 secs]

Здесь мы видим две второстепенные коллекции, за которыми следует одна крупная коллекция. Числа до и после стрелки (например, 325407K->83000K из первой строки) указывают объединенный размер живых объектов до и после сбора мусора, соответственно. После небольших коллекций размер включает в себя некоторые объекты, которые являются мусором (уже не живыми), но которые не могут быть восстановлены. Эти объекты либо содержатся в поколенном поколении, либо ссылаются на постоянные или постоянные поколения.

Следующее число в круглых скобках (например, (776768K) снова из первой строки) - это фиксированный размер кучи: объем пространства, который можно использовать для объектов Java без запроса большего объема памяти из операционной системы. Обратите внимание, что это число не включает одно из оставшихся в живых, поскольку только один может быть использован в любой момент времени, а также не включает постоянное поколение, в котором хранятся метаданные, используемые виртуальной машиной.

Последний элемент строки (например, 0.2300771 secs) указывает время, затраченное на выполнение коллекции; в этом случае примерно четверть секунды.

Формат основной коллекции в третьей строке аналогичен.

Формат вывода, созданного -verbose:gc, может быть изменен в будущих выпусках.

Я не уверен, почему в вашем распоряжении PSYoungGen; вы изменили сборщик мусора?

Ответ 2

• PSYoungGen относится к сборщику мусора, который используется для небольшой коллекции. PS означает Parallel Scavenge.
• Первый набор чисел - это размеры до и после молодого поколения, а второй набор - для всей кучи. (Диагностика проблемы с сборкой мусора подробно описывает формат)
• Название указывает на генерацию и сборщик, о котором идет речь, второй набор для всей кучи.

Пример связанного полного GC также показывает коллекторы, используемые для старого и постоянного поколений:

3.757: [Full GC [PSYoungGen: 2672K->0K(35584K)] 
            [ParOldGen: 3225K->5735K(43712K)] 5898K->5735K(79296K) 
            [PSPermGen: 13533K->13516K(27584K)], 0.0860402 secs]

Наконец, разбив одну строку вашего выходного журнала журнала:

8109.128: [GC [PSYoungGen: 109884K->14201K(139904K)] 691015K->595332K(1119040K), 0.0454530 secs]

• 107Mb, используемый до GC, 14Mb, используемый после GC, максимальный размер молодого поколения 137Mb
• 675Mb куча, используемая до GC, 581Mb куча, используемая после GC, 1 ГБ максимальный размер кучи
• младший GC произошел 8109.128 секунд с момента запуска JVM и взял 0,04 секунды

Ответ 3

Я просто хотел упомянуть, что можно получить подробный журнал GC с помощью

-XX:+PrintGCDetails 

параметр. Затем вы видите вывод PSYoungGen или PSPermGen, как в ответе.

Также -Xloggc:gc.log, похоже, генерирует тот же результат, что и -verbose:gc, но вы можете указать выходной файл в первом.

Пример использования:

java -Xloggc:./memory.log -XX:+PrintGCDetails Memory

Чтобы лучше визуализировать данные, вы можете попробовать gcviewer (более позднюю версию можно найти на github).

Позаботьтесь о правильном написании параметров, я забыл "+", и мой JBoss не запустился, без каких-либо сообщений об ошибках!