Каковы поколения в сборке мусора?

Ответ 1

Из понимания сборки мусора в .NET

Поколения

Сборщик мусора поколений собирает недолговечные объекты чаще, чем долгоживущие. Короткоживущие объекты хранятся в первом поколении, поколение 0. Долгоживущие объекты вытесняются в старшие поколения, 1 или 2. Сборщик мусора работает чаще в более низких поколениях, чем в более высоких.

Когда объект создается впервые, он помещается в поколение 0. Когда поколение 0 заполняется, вызывается сборщик мусора. Объекты, которые выживают при сборке мусора в первом поколении, переносятся в следующее поколение более высокого поколения, поколение 1. Объекты, которые выживают при сборке мусора в поколении 1, переводятся в следующее поколение и поколение 2. Это алгоритм эффективно работает для мусора. Коллекция объектов, как это быстро. Обратите внимание, что поколение 2 - это самое высокое поколение, которое поддерживается сборщиком мусора.

Сборка мусора в .NET

Поколения

Хотя выделение памяти в управляемой куче происходит быстро, сам GC может занять некоторое время. С учетом этого было сделано несколько оптимизаций для улучшения производительности. GC поддерживает концепцию поколений, основанную на предположении, что чем дольше объект находится в куче, тем дольше он, вероятно, будет оставаться там. Когда объект размещается в куче, он принадлежит поколению 0. Каждая сборка мусора, которую этот объект сохранил, увеличивает его генерацию на 1 (в настоящее время наибольшее поддерживаемое поколение - 2). Очевидно, что быстрее искать и собирать мусор подмножество всех объектов в куче, поэтому GC имеет возможность собирать только объекты поколения 0, 1 или 2 (или любую комбинацию, которую выберет, пока не будет достаточно памяти). Даже собирая только более молодые объекты, GC также может определить, есть ли у старых объектов ссылки на новые объекты, чтобы гарантировать, что он случайно не проигнорирует используемые объекты.

Ответ 2

В "Pro С# 2008" есть приятное описание:

• Генерация 0 идентифицирует вновь созданный объект, который никогда не был помечен для коллекции
• Поколение 1 идентифицирует объект, который пережил GC (помечен для коллекции, но не удален, потому что было достаточно места для кучи)
• Генерация 2 идентифицирует объект, который пережил более одного развертки GC.

Ответ 3

Мой первый блог, Generations of Garbage Allocation, отвечает на ваш вопрос:

Сборщик мусора (GC) - это сборщик мусора поколений, также известный как сборщик мусора.

У него три поколения:

Поколение 0:

Он содержит все вновь созданные объекты, которые никогда не проверяются GC.

Поколение 1:

При инициализации CLR выбирает размер бюджета в килобайтах для поколения 0. Если создание объекта приводит к тому, что поколение 0 превышает его бюджет, запускается сборка мусора. Объекты, которые не собраны в поколении 0, перемещаются в поколение 1, а поколение 0 очищается. Допустим, бюджет поколения 0 равен размеру 5 объектов. Итак, поколение 0 будет выглядеть ниже до создания объекта 6:

После создания объекта 6 начинается распределение мусора, которое освобождает объекты мусора 1, 3 и 5 и перемещает 2 и 4 рядом друг с другом в поколении 1.

Размер бюджета поколения 1 также выбирается CLR при инициализации. Создание объекта 11 приводит к тому, что ГХ запускается снова, что может переместить еще несколько объектов в поколение 1.

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

Поколение 2:

В течение нескольких поколений сбора 0 поколение 1 может превысить свой бюджетный предел, что заставляет GC собирать мусор из обоих поколений. В этом случае выжившие поколения 1 повышаются до поколения 2, выжившие поколения 0 повышаются до поколения 1, а поколение 0 пусто.

Допустим, объект размещения 21 вызывает сборку мусора и бюджет первого поколения.

Таким образом, куча будет выглядеть, как показано ниже, с объектом, который выжил в Поколении 1, продвинутым до поколения 2.

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

Мы знаем, что CLR выбирает бюджеты для всех трех поколений, но может изменять их, поскольку GC является самонастраивающимся сборщиком. Если GC видит, что после сбора поколения 0 остается очень мало выживших объектов, он может решить уменьшить бюджет поколения 0, чтобы была выполнена меньшая работа. С другой стороны, если GC собирает поколение 0 и видит, что сохранилось много объектов, в сборке мусора не было много памяти. В этом случае сборщик мусора вырастет бюджет поколения 0s. GC также изменяет бюджеты поколений 1 и 2 соответственно.