#java #garbage-collection #garbage #g1gc
Вопрос:
Аргументы JVM следующие: -Xms20g -Xmx20g -XX:MaxGCPauseMillis=10000 -XX:G1ReservePercent=30 -Часовой пояс пользователя=UTC
Единственное, что есть в журналах, это
- Пауза Молодая (Нормальная) (Пауза эвакуации G1)
Замечание о паузе
Пауза Молодая (Подготовка Смешанная) (Пауза эвакуации G1)
Пауза Янг (Смешанная) (Пауза эвакуации G1)
Пауза Молодого (Одновременный запуск)
….
Но ничто не сравнится с полным GC. Ни разу.
Использование памяти превышает 65 процентов.
При каких уровнях потребления памяти мы можем ожидать полного GC ?
Комментарии:
1. Разработчики потратили много усилий, чтобы как можно больше избежать полного GC. Почему вы не довольны их успехом? Какую проблему вы хотите решить?
2. Пробел заключался в моем понимании того, что полного GC следует/следует избегать как можно больше. Я пытался понять журналы GC, но смог увидеть одну полную ссылку на GC, и это вызвало у меня любопытство. Спасибо
Ответ №1:
Полный GC будет запущен, когда ваши объекты станут долгоживущими (т. Е. продвигаются от молодого поколения к старому). И тогда он будет срабатывать только в том случае, если в этом возникнет необходимость из-за нехватки памяти.
Поэтому вам нужно будет хранить множество объектов в долговременной структуре, такой как хэш-карта. Огромная хэш-карта. Затем дайте ему посидеть в течение длительного времени, а затем попытайтесь выделить большие объекты.
Кроме того, большинство алгоритмов GC стараются как можно больше избегать полного GC. Поэтому использование более старого алгоритма, такого как ConcurrentMarkAndSweep, может упростить его запуск. Добиться этого с помощью коллектора G1 теоретически возможно, но будет непросто.
Для сборщика G1 выделение большого количества объектов, которые сохраняются в коллекциях, а затем попытка выделить очень большие объекты может вызвать его. Но это будет нелегко.
Я видел их в дикой природе с огромной кучей. Вероятно, его легче воспроизвести с 16 ГБ оперативной памяти, чем с небольшой кучей (я вижу, вы используете 20 ГБ, что хорошо).
Комментарии:
1. Когда мы говорим «долгожители», о каких временах мы говорим ?
2. Он должен пережить несколько коллекций. Молодые поколения будут классически использовать сборщик копий, в то время как старое поколение (если у вас есть набор ConcurrentMarkAndSweep) будет использовать алгоритм пометки и развертки. Поэтому, чтобы смоделировать это, я бы оставил его включенным на некоторое время, пока он непрерывно добавляет/удаляет вещи.. вы бы хотели, чтобы некоторые данные сохранились в коллекциях и попали в старую часть памяти.
3. Совпадение и совпадение ?? у нас здесь есть G1. Остается ли концепция метки и развертки верной в G1 GC ?
4. Поскольку вы делаете это с помощью сборщика G1, я думаю, что вы можете заставить это сделать, выделив огромные объекты. Но, к счастью, G1 был построен так, чтобы избежать именно этого сценария.
5. Я не заметил, что вы используете G1. С G1 это будет очень сложно.