Очко знаний в день: когда сработает полная сборка мусора

JVM

Цель ежедневной серии баллов знаний состоит в том, чтобы сделать общее резюме определенного пункта знаний, а понимание прочитанного пункта знаний может быть завершено в течение одной минуты.

Здесь не требуется детальной теоретической интерпретации, и она используется только как введение.

Настоящим пониманием должны быть знания, полученные в результате ваших собственных исследований и изысканий.Присоединение к организации приведет вас к прогрессу и росту вместе.

Самый быстрый короткий путь в мире — удержать ноги на земле. Эта статья была включенаКолонка архитектурных технологийОбратите внимание на это место, которым вы хотели бы поделиться, и получайте очко знаний каждый день

1. перечислить System.gc()

Предполагается только, что виртуальная машина выполняет полный сборщик мусора, но виртуальная машина не обязательно выполняет его. Не рекомендуется использовать этот способ, но пусть виртуальная машина управляет памятью.

2. Если размер старой и молодой генерации не указан, будет генерироваться fullgc при расширении и сжатии кучи, поэтому обязательно настройте -Xmx, -Xms

3. Недостаточно места для старости

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

Во избежание полного GC, вызванного вышеуказанными причинами, следует стараться не создавать слишком большие объекты и массивы.

Кроме того, вы можете увеличить размер нового поколения через параметр виртуальной машины -Xmn, чтобы объекты можно было максимально перерабатывать в новом поколении, не входя в старое поколение.

Вы также можете увеличить возраст объекта, входящего в старое поколение, на -XX:MaxTenuringThreshold, чтобы объект мог сохраняться в новом поколении в течение более длительного периода времени.

После выполнения полного GC места по-прежнему недостаточно, и выдается ошибка:java.lang.OutOfMemoryError: Java heap space

4. JDK 1.7 и предыдущее (постоянное поколение) пространство заполнено

В JDK 1.7 и более ранних версиях область методов виртуальной машины HotSpot была реализована с постоянным поколением, в котором хранилась некоторая информация о классе, константы, статика и т. д.

Переменные и другие данные.

Когда в системе много классов для загрузки, отраженных классов и методов для вызова, постоянная генерация может быть заполнена, и даже если она не настроена на использование CMS GC

Будет выполнена полная сборка мусора.

Если его по-прежнему невозможно восстановить после полного GC, виртуальная машина выдастjava.lang.OutOfMemoryError PermGen space

Чтобы избежать полного GC, вызванного вышеуказанными причинами, можно использовать следующие методы: увеличить Perm Gen или переключиться на CMS GC.

5. Гарантия распределения места не удалась

Гарантия пространства, следующие две ситуации являются отказом гарантии пространства:

1. Средний размер объектов, продвигаемых каждый раз > оставшегося места в старом поколении

2. Объекты, уцелевшие после Minor GC, превышают оставшееся пространство в старости.

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

Ошибка повышения происходит, когда выполняется Minor GC, и место для оставшихся в живых не может быть размещено, а старое поколение может быть только повышено, а старому поколению также не хватает места в это время.

Сбой параллельного режима вызван процессом CMS GC.В это время есть объекты для размещения в старости и места недостаточно.В этом случае сборщик Serial Old будет вырожденным и станет однопоточным, что в это время довольно медленно.

Как настроить

В какой-то момент стратегия состоит в том, чтобы попытаться переработать объекты в новом поколении, чтобы снизить вероятность перехода в старое поколение.

Проект с открытым исходным кодом: