Почему JVM делает так много мусора

Question

Ниже приведен вывод jstat из JVM, работающей со следующими параметрами

-Xmx10240m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 

Вывод jstat с параметрами

jstat -gcutil <pid> 10s

Раздел является фрагментом за период80 секунд, и, согласно статистике, почти 70 секунд из этого расходуется в GC.Все они - полные сборщики мусора, которые запускаются.

Timestamp   S0  S1  E       O       P       YGC     YGCT        FGC     FGCT        GCT         Diff
1040430.2   0   0   23.69   24.58   95.03   168048  22187.057   3672    4483.931    26670.988   8.175
1040440.2   0   0   0.1     24.58   95.02   168048  22187.057   3674    4495.551    26682.608   11.62
1040450.2   0   0   4.19    24.59   95.03   168048  22187.057   3677    4506.731    26693.788   11.18
1040460.2   0   0   0.01    24.45   95.02   168048  22187.057   3679    4517.391    26704.448   10.66
1040470.2   0   0   0.33    24.45   95.03   168048  22187.057   3681    4522.213    26709.27    4.822
1040480.2   0   0   0       24.43   95.02   168048  22187.057   3684    4534.816    26721.874   12.604

Пространство PermGen почти заполнено, но я не думал, что механизм Sun GC попытается собрать здесь, и я вижу причинусобраны на основе Эдема или Старого пространства.

Кто-нибудь, кто может дать мне несколько советов о том, что может происходить?

Answer 1

Почему JVM делает так много сборщиков мусора.

Это наиболее вероятно, потому что постоянная занятость поколения довольно высока. При использовании алгоритма CMS основная коллекция включается только тогда, когда занятость старого или постоянного поколений превышает определенный порог. Порог занятости по умолчанию для старого поколения составляет 68%, если я не ошибаюсь, и его можно изменить с помощью флага -XX:CMSInitiatingOccupancyFraction=n . Тем не менее, в контексте представленных данных это значение представляется несущественным, поскольку занятость старого поколения на момент сбора статистики составляет менее 25% (это не означает, что старое поколение не заполнило промежуточный период). , но маловероятно, когда само постоянное поколение демонстрирует более высокую занятость).

Обратите внимание, что сборщик CMS не запрашивает объекты из постоянной генерации по умолчанию. Для этого потребуется включить флаг CMSClassUnloading. Если поведение не улучшается, то вероятно, что постоянное поколение имеет неправильный размер, и ему нужно было бы уделить больше памяти, поскольку было бы очевидно, что только несколько объектов в постоянном поколении могут быть собраны на каждый крупный цикл сбора.