Почему JVM постоянно выполняет полную сборку мусора, в то время как старое поколение заполнено только наполовину?

Я использую jdk 1.7.0_09 на 64-битной Linux-машине CentOS.

Связанные с gc vm args

-Xmx4g -Xmn2g -XX:SurvivorRatio=4 -XX:PermSize=128m -XX:MaxPermSize=128m -XX:InitialTenuringThreshold=15 -XX:CMSWaitDuration=50 -XX:MaxTenuringThreshold=15 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:CMSInitiatingOccupancyFraction=80 -XX:+CMSParallelRemarkEnabled -XX:ReservedCodeCacheSize=128m

Но он постоянно выполняет полный сборщик мусора

jstat -gcutil pid 1000    
    S0     S1     E      O      P     YGC     YGCT    FGC    FGCT     GCT   
    0.00   0.00  15.62  57.52  19.90     11    2.081 11109 7454.686 7456.767   
    0.00   0.00  15.81  57.52  19.90     11    2.081 11109 7454.686 7456.767   
    0.00   0.00  15.81  57.51  19.90     11    2.081 11111 7454.892 7456.973   
    0.00   0.00  16.06  57.51  19.90     11    2.081 11111 7455.115 7457.196
    0.00   0.00  16.06  57.51  19.90     11    2.081 11111 7455.115 7457.196
    0.00   0.00  16.27  57.51  19.90     11    2.081 11111 7455.115 7457.196
    0.00   0.00  16.27  57.51  19.90     11    2.081 11111 7455.115 7457.196
    0.00   0.00  16.29  57.51  19.90     11    2.081 11111 7455.115 7457.196
    0.00   0.00  16.29  57.51  19.90     11    2.081 11111 7455.115 7457.196
    0.00   0.00  16.29  57.47  19.90     11    2.081 11113 7455.549 7457.629
    0.00   0.00  16.29  57.47  19.90     11    2.081 11113 7455.549 7457.629
    0.00   0.00  16.34  57.47  19.90     11    2.081 11113 7455.549 7457.629
    0.00   0.00  16.34  57.47  19.90     11    2.081 11113 7455.549 7457.629
    0.00   0.00  16.34  57.47  19.90     11    2.081 11113 7455.549 7457.629
    0.00   0.00  16.42  57.47  19.90     11    2.081 11114 7455.549 7457.629
    0.00   0.00  16.42  57.44  19.90     11    2.081 11115 7455.986 7458.067

java garbage-collection jvm-hotspot concurrent-mark-sweep
person Timmy    schedule 26.11.2012    source источник

Ответы (2)


arrow_upward
3
arrow_downward

Несмотря на колонку «ФСК», это не совсем полноценная ГК. То, что делает CMS, — это параллельная коллекция, чтобы увидеть, можно ли что-то очистить от старой коллекции (что, как вы можете видеть, она делает). Способ сказать, что это не полный сборщик мусора, заключается в том, что полный сборщик мусора очищает пространство Эдема и копирует его из одного пространства оставшихся в живых в другое.

ИМХО Чем больше вариантов вы используете, тем больше шансов, что вы столкнетесь с какой-то комбинацией с неожиданными результатами. Я бы придерживался минимума вариантов и посмотрел, как это работает. Добавляйте опцию только тогда, когда знаете, что они всегда помогут.

Попробуйте начать с,

-mx4g -XX:MaxPermSize=128m -XX:+UseConcMarkSweepGC
person Peter Lawrey    schedule 26.11.2012
comment
Я согласен. Используемые флаги указывают на то, что это гугл-конфиг. если вы действительно хотите -XX:InitialTenuringThreshold=15 -XX:CMSWaitDuration=50 -XX:MaxTenuringThreshold=15, вы должны знать почему. (и тогда вы бы знали, что они не имеют большого значения) - person Fabian Lange; 26.11.2012
comment
Что еще хуже, так это то, что часто флаги являются чисто максимальными усилиями, уже включены по умолчанию или не делают того, что они делают. Даже -ms и -mx (обычно известные как -Xms и -Xmx) не делают того, что думает большинство людей. - person Peter Lawrey; 26.11.2012
comment
@FabianLange Мы сравнили наше приложение с различными настройками флагов gc и, наконец, остановились на этом. Мы знаем, что некоторая конфигурация — это просто предложение. - person Timmy; 26.11.2012

arrow_upward
0
arrow_downward

Это нормально. Если бы вы сделали «-verbose:gc», вы бы увидели, что «Полная» коллекция на самом деле является параллельной (вы указали «-XX:+UseConcMarkSweepGC»). Вы также можете увидеть, что время не увеличивается на много. И это время одновременное, а не остановившее мир.

person Fabian Lange    schedule 26.11.2012