Статья для понимания коллекционера G1

Введение в G1

Garbage First Collector, называемый G1 Collector, представляет собой сборщик для большой памяти (число области кучи от G до нескольких 10G), многоядерную систему, представленную после HotspotJDK1.7, которая может выполнять сбор целевых объектов с мягкой паузой и имеет высокую пропускную способность, с более предсказуемое время паузы.

G1 — это одновременный, параллельный, частичный Stop The World, инкрементный коллектор поколения, собранный с использованием алгоритма копирования.
Операции G1 с полной кучей, такие как глобальная маркировка, выполняются одновременно с приложением (мутатором), что сокращает время паузы для мутатора. На этапе очистки используется многопоточность для повышения пропускной способности.
В отличие от сборщиков, таких как Serial, Parallel и CMS до Hotspot, G1 делит кучу на множество областей одинакового размера и оценивает активность каждой области во время каждой сборки, то есть долю объектов мусора, тем выше доля объектов мусора.Чем больше регионов утилизировано, тем больше выгода, а затем G1 оценит, какие регионы следует утилизировать в соответствии с установленным целевым временем паузы и временем, затраченным на утилизацию регионов в первые несколько раз, то есть для получения наибольшая польза за наименьшее время, что также является значением названия Garbage First.
Garbage First Collector предназначен для замены CMS в будущем и стал сборщиком по умолчанию в JDK 1.9.

Зачем нужен G1

В Hotspot уже есть такие сборщики, как Serial, Parallel, CMS и т. д. Зачем им разрабатывать новый G1? Три показателя производительности сборки мусора: занимаемая площадь, максимальное время паузы и пропускная способность, похоже, не удовлетворяются одновременно, как CAP.
На стороне сервера больше внимания уделяется короткому времени паузы, то есть времени остановки мира, и общее время паузы в течение периода времени также является мерой.
Как Mark-Sweep, так и Mark-Compact требуют рабочей нагрузки, пропорциональной размеру очищаемой области, в то время как алгоритму копирования обычно требуется половина пространства для хранения живых объектов каждой копии. Два этапа STW CMS, начальная маркировка и перемаркировка, занимают больше времени, когда область кучи становится все больше и больше, а из-за фрагментации памяти, если требуется сжатие, это также приведет к увеличению времени паузы. Таким образом, необходим сборщик с высокой пропускной способностью и коротким временем паузы, независимо от размера кучи.

Реализация G1

Region

Чтобы избежать длительных пауз, вы можете рассмотреть возможность разделения кучи на несколько частей и сбора части из них за раз.Этот метод также называется инкрементной коллекцией.Коллекция поколений также может рассматриваться как особый вид инкрементной коллекции.
Сборщик G1 делит память кучи на ряд регионов одинакового размера. Размер региона определяется при запуске от 1 МБ до 32 МБ. G1 также использует стратегию сбора поколений, чтобы разделить кучу на Eden, Survivor, Old и т. д. , но только логически разделенный, каждый регион логически принадлежит к региону поколения и физически прерывист. Когда старый регион собран, он станет новым доступным регионом и может стать следующим регионом Эдема. Когда запрошенный объект больше половины размера региона, он будет помещен в Humongous Region (гигантский регион). Когда регион пуст, он называется доступным регионом или новым регионом.

На картинке E означает Eden, S — Survivor, H — Humongous, O — Old, а пустая область — доступный раздел.

CardTable

Поскольку G1 повторно использует только часть региона, ему необходимо знать, какие другие объекты региона ссылаются на его собственные объекты региона при переработке.Поскольку используемый алгоритм копирования требует перемещения объекта, необходимо обновить ссылку на новый адрес объекта. То же самое верно и для централизации.В коллекции поколений молодое поколение собирает записи, которые требуют ссылок от старого поколения к молодому поколению, которое обычно называют запоминаемым набором (RS для краткости). CardTable — это запоминаемый набор. Карта представляет собой диапазон памяти. В настоящее время для представления карты используется 512 байт. Cardtable — это массив байтов. Каждый регион имеет свою собственную таблицу карт. Сохранение запомненного набора требует, чтобы поток-мутатор уведомлял сборщик, когда он может изменять ссылки между регионами. Этот метод обычно называется барьером записи (в отличие от барьера памяти в GC). Каждый поток будет иметь свой собственный журнал запомненного набора, который Эквивалент собственного В дополнение к буферу буфера измененной карты, есть также глобальный буфер.После того, как собственный буфер набора запоминания заполнен мутатором, он будет помещен в глобальный буфер, а затем будет создан новый буфер.

Только ссылки из других регионов должны быть записаны в RS, поэтому ни ссылки, ни нули внутри региона не должны быть записаны в RS.

Классификация процессов инкассации

Marking

Фаза маркировки сборщика G1 отвечает за маркировку уцелевших объектов и подсчет активности каждого Региона.
G1 использует алгоритм маркировки Snaphot-At-The-Beginning, называемый SATB, который записывает снимок графа объектов в начале маркировки, а затем новые объекты, примененные в параллельном процессе сбора, рассматриваются как живые объекты. коэффициент использования кучи превышает InitiatingHeapOccupancyPercent. После начала фазы маркировки используйте SATB для записи моментального снимка графа объектов в начале фазы маркировки.
G1 использует растровое изображение, чтобы отметить отмеченные позиции. Один бит растрового изображения представляет 8 байтов. Мы используем два растровых изображения маркировки, одно предыдущее и одно следующее. Предыдущее растровое изображение маркировки представляет собой отмеченную часть. предыдущий и следующий будут заменены
Фаза маркировки делится на несколько этапов.

Initial Marking Phase

В начале цикла маркировки очищается следующая битовая карта маркировки, которая выполняется одновременно. Затем начните начальную фазу маркировки, которая приостановит все потоки и пометит все объекты, к которым можно получить доступ непосредственно из корней сборщика мусора.Это делается попутно на этапе сбора приостановки в Young GC.

Root Region Scan Phase

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

Concurrent Marking Phase

На этом этапе G1 находит все достижимые объекты во всей куче путем трассировки. Эта фаза выполняется одновременно.

Remark Phase

Примечание: этап STW, G1 завершает всю обработку буфера SATB.

Cleanup Phase

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

процесс сбора

В отличие от общего поколенческого сбора, кроме обычного Молодежного ГК, в G1 есть еще и Смешанный ГК.

Young Garbage Collection

Когда область Эдема не может подать заявку на новые объекты (она заполнена), будет выполнен Молодой GC.Молодой GC скопирует живые объекты в регионах (называемых наборами коллекций, CSets) областей Eden и Survivor в некоторые новые регионы. (т.е. новый выживший), когда возраст GC объекта достигает порогового значения, он будет скопирован в старый регион. Поскольку используется алгоритм копирования, проблема фрагментации памяти устраняется, и отдельное сжатие больше не требуется.

Mixed Garbage Collection

Когда доля объектов кучи в старой области по отношению к общей куче превысит значение InitiatingHeapOccupancyPercent, запустится ConcurentMarking. После завершения параллельной маркировки G1 переключится с молодого GC на смешанный GC. В смешанном GC G1 может добавить несколько регионов в старый области.в CSet.
Количество смешанных GC зависит от кандидата Old CSet и

Full GC

Как и в CMS, некоторые процессы сбора G1 выполняются параллельно с приложением, поэтому восстановление может быть еще не завершено, т. к. скорость запроса памяти быстрее скорости восстановления, а новые объекты занимают все пространство, которое называется Concurrent в Ошибка режима CMS, называемая ошибкой распределения в G1, также понижена до STW fullgc.

Floating Garbage

G1 использует метод Snapshot-At-The-Begining для записи живых объектов, то есть графа объектов памяти в тот момент (когда начинается параллельная разметка всей кучи), но объекты в этом могут после этого стать мусором. называется плавающим мусором и может только ждать следующей сборки, чтобы собрать его.

Суммировать

Характеристики G1 заключаются в том, что куча делится на регионы одинакового размера и выполняется логическая генерация, большая часть маркировки выполняется одновременно, и большая часть STW использует многопоточное параллельное выполнение, а копирование используется для многопоточного параллельного сбора. .

Общие параметры настройки G1

Как и другие сборщики, настройте максимальный размер и начальный размер кучи

-XX:MaxGCPauseMillis=200

Максимальное время паузы GC, по умолчанию 200 мс

-XX:InitiatingHeapOccupancyPercent=45

Порог коэффициента заполнения кучи в начале цикла маркировки, по умолчанию 45%.Обратите внимание, что это вся куча, что отличается от коэффициента старой кучи в CMS.

-XX:G1HeapRegionSize=n

Установите размер каждого региона, который должен быть экспоненциальным размером 2 от 1 МБ до 32 МБ.

Сценарии, в которых рекомендуется G1

Лично я считаю, что замену GC или настройку можно рассматривать только как вишенку на торте, а не ключ к решению проблем с производительностью системы.При возникновении проблем с памятью следует сосредоточиться на модификации кода приложения, написании понятного GC-дружественного кода , а выбор и применение сборщиков, соответствующих сценарию, может повысить производительность системы.
Вот некоторые из ситуаций, в которых теперь рекомендуется перейти с CMS на G1:

• Более 50% кучи Java составляют живые объекты.
• Ставки размещения объектов сильно различаются
• Невыносимо долгие паузы из-за старого gc или сжатия