Сборщик мусора G1 - Java 9: различия между версиями

Материал из Документация Ключ-АСТРОМ
(Новая страница: «Виртуальная машина Oracle Java 9 Hotspot поставляется с GC Garbage First (G1) в качестве сборщика мусора по...»)
 
 
(не показана 1 промежуточная версия 1 участника)
Строка 1: Строка 1:
'''''[[Поддержка технологий]] / [[Java]] / Сборщик мусора G1 - Java 9'''''
Виртуальная машина Oracle Java 9 Hotspot поставляется с GC Garbage First (G1) в качестве сборщика мусора по умолчанию. Этот сборщик мусора, впервые представленный в Java 7, может эффективно и одновременно обрабатывать очень большие кучи. Его также можно настроить так, чтобы не превышалось максимальное время паузы.
Виртуальная машина Oracle Java 9 Hotspot поставляется с GC Garbage First (G1) в качестве сборщика мусора по умолчанию. Этот сборщик мусора, впервые представленный в Java 7, может эффективно и одновременно обрабатывать очень большие кучи. Его также можно настроить так, чтобы не превышалось максимальное время паузы.


Строка 8: Строка 10:
* алгоритм с эффективным использованием памяти может использоваться на старом поколении; время выполнения зависит от размера кучи, но максимально эффективно использует доступную память.
* алгоритм с эффективным использованием памяти может использоваться на старом поколении; время выполнения зависит от размера кучи, но максимально эффективно использует доступную память.


A heap of such a collector would look like this:
Куча такого коллектора будет выглядеть так:
[[Файл:Heap-736-04799a203f.png|мини|468x468пкс]]
 
 
 


<image>


По сравнению с большинством сборщиков мусора G1 имеет два основных преимущества:
По сравнению с большинством сборщиков мусора G1 имеет два основных преимущества:
Строка 20: Строка 25:


Куча G1 обычно выглядит так:
Куча G1 обычно выглядит так:
[[Файл:G1 heap.png|мини]]


<image>


Разделение кучи на небольшие области позволяет G1 выбрать небольшую группу областей для быстрого сбора и завершения. Если регион запланирован для сбора, все уцелевшие объекты копируются из собранного региона в неназначенный регион. Предполагая, что собранная область была из пространства Эдема, неназначенная область, содержащая все выжившие объекты, становится оставшейся областью. В идеале, если регион заполнен мусором и не содержит ни одного уцелевшего объекта, его можно объявить «неназначенным», и с ним не будет производиться никакая работа.
Разделение кучи на небольшие области позволяет G1 выбрать небольшую группу областей для быстрого сбора и завершения. Если регион запланирован для сбора, все уцелевшие объекты копируются из собранного региона в неназначенный регион. Предполагая, что собранная область была из пространства Эдема, неназначенная область, содержащая все выжившие объекты, становится оставшейся областью. В идеале, если регион заполнен мусором и не содержит ни одного уцелевшего объекта, его можно объявить «неназначенным», и с ним не будет производиться никакая работа.

Текущая версия на 15:05, 15 августа 2023

Поддержка технологий / Java / Сборщик мусора G1 - Java 9

Виртуальная машина Oracle Java 9 Hotspot поставляется с GC Garbage First (G1) в качестве сборщика мусора по умолчанию. Этот сборщик мусора, впервые представленный в Java 7, может эффективно и одновременно обрабатывать очень большие кучи. Его также можно настроить так, чтобы не превышалось максимальное время паузы.

Большинство современных сборщиков мусора классифицируют кучи на объекты молодого или старого поколения. Это происходит главным образом потому, что исследования реальных Java-приложений показали, что более 90% объектов не переживают свою первую сборку мусора. Более старые объекты, которые пережили несколько циклов сбора, как правило, остаются живыми и имеют 98% шанс на выживание. Сборщики мусора Java разделяют объекты молодого поколения на пространство выживших и пространство Eden.

Недавно размещенные объекты всегда размещаются в пространстве Eden. Как только объект переживает первую сборку мусора, он передается старшему поколению. Это сделано для того, чтобы:

  • алгоритм, эффективный во время выполнения, может быть использован для новых объектов; время выполнения зависит только от количества уцелевших объектов, но тратит впустую половину размера кучи.
  • алгоритм с эффективным использованием памяти может использоваться на старом поколении; время выполнения зависит от размера кучи, но максимально эффективно использует доступную память.

Куча такого коллектора будет выглядеть так:

Heap-736-04799a203f.png



По сравнению с большинством сборщиков мусора G1 имеет два основных преимущества:

  • он может работать одновременно, не останавливая потоки приложений
  • он использует прерывистые пространства, что позволяет G1 эффективно обрабатывать очень большие кучи

Благодаря тому, как он использует доступную кучу, G1 может одновременно собирать молодые и старые поколения. Вместо того, чтобы разделять кучу на 3 области: Eden, Survivor и old, она разбивает кучу на несколько крошечных областей, размер которых по умолчанию составляет 2 МБ. Каждому региону назначается пространство.

Куча G1 обычно выглядит так:

G1 heap.png


Разделение кучи на небольшие области позволяет G1 выбрать небольшую группу областей для быстрого сбора и завершения. Если регион запланирован для сбора, все уцелевшие объекты копируются из собранного региона в неназначенный регион. Предполагая, что собранная область была из пространства Эдема, неназначенная область, содержащая все выжившие объекты, становится оставшейся областью. В идеале, если регион заполнен мусором и не содержит ни одного уцелевшего объекта, его можно объявить «неназначенным», и с ним не будет производиться никакая работа.

Чтобы собрать всю кучу, G1 может выбрать любое количество или комбинацию регионов для сбора. Чтобы оптимизировать время сбора, он всегда выбирает области, заполненные или почти заполненные мусором, тем самым сводя к минимуму объем работы, необходимой для освобождения места в куче для последующего выделения. Другие сборщики мусора всегда собирают все поколение, поэтому их сложность во время выполнения зависит от общего размера кучи. В случае G1 это зависит от количества живых объектов, поскольку память может быть освобождена без обработки всего поколения. В идеале, когда куча достаточно велика, некоторые области всегда будут полностью заполнены мусором, что упростит их сбор.

Кроме того, G1 может выполнять большую часть своей работы одновременно. В мире Java мы уже знаем о параллельных коллекциях из Concurrent Mark & Sweep GC (CMS). Однако CMS может одновременно собирать только старое поколение и по-прежнему должна останавливать приложение, чтобы собрать молодое поколение. Процесс проходит в следующие этапы:

  1. Начальная отметка : G1 останавливает приложение только в начале сборки мусора, чтобы выполнить некоторую быструю бухгалтерию перед возобновлением работы приложения.
  2. Параллельная отметка :Пока приложение выполняется, сборщик мусора отслеживает все ссылки и отмечает жизненные объекты.
  3. Окончательная оценка : Приложение снова приостанавливается, и выполняется окончательная очистка.
  4. Эвакуация: Выбирается и собирается несколько регионов.

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