Когда Сборщик мусора начинает свою работу?

Обзор запуска сборщика мусора (GC) в .NET

Сборщик мусора (Garbage Collector, GC) в .NET — это недетерминированный механизм, который запускается автоматически при определенных условиях. Точное время запуска управляется самой средой выполнения (CLR) и зависит от нескольких факторов.

Основные триггеры запуска GC

1. Нехватка памяти в управляемой куче (Managed Heap) Наиболее частая причина. Когда приложение запрашивает выделение памяти через оператор new, а в текущем поколении (generation) недостаточно свободного пространства, CLR инициирует сборку мусора для этого поколения.

// При частых созданиях объектов может запустить GC
for (int i = 0; i < 100000; i++)
{
    var obj = new MyClass(); // Если память заполняется → возможен запуск GC
}

2. Явный вызов программиста Можно принудительно запросить сборку с помощью GC.Collect(). Однако это крайне не рекомендуется для production-кода, так как нарушает оптимизированную работу GC и может снизить производительность.

// Явный вызов (использовать с осторожностью!)
GC.Collect();
GC.WaitForPendingFinalizers(); // Ожидание финализаторов

3. Выгрузка домена приложения (AppDomain) При выгрузке домена приложения сборщик мусора выполняется для очистки всех объектов, связанных с этим доменом.

4. Нехватка физической памяти (низкая доступная RAM) Операционная система может уведомить CLR о критической нехватке физической памяти через механизм памяти с низким уровнем доступности (low memory notification). В ответ CLR может запустить агрессивную сборку.

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

Как работает управление памятью и поколения (Generations)

GC использует поколения (Generation 0, 1, 2) для оптимизации. Большинство объектов умирают молодыми (слабый принцип поколений).

• Generation 0: Короткоживущие объекты (например, локальные переменные). Сборка здесь происходит чаще всего и является самой быстрой.
• Generation 1: Буферная зона между Gen0 и Gen2.
• Generation 2: Долгоживущие объекты (например, статические поля, кэши). Сборка здесь наиболее затратна и происходит реже.

// Пример, демонстрирующий поколения
var shortLived = new object(); // Скорее всего попадет в Gen0
GC.Collect(0); // Сборка только для Gen0
Console.WriteLine(GC.GetGeneration(shortLived)); // Может показать поколение

Типы сборок мусора

• Фоновая сборка (Background GC): Выполняется в фоновом потоке для Gen2, позволяя потокам приложения продолжать работу. Не блокирует приложение надолго.
• Полная блокирующая сборка (Blocking Full GC): Останавливает все потоки приложения (STW — Stop The World). Происходит в критических ситуациях, например, при нехватке памяти или явном вызове GC.Collect().

Настройка и мониторинг

Поведение GC можно настраивать через режимы работы:

• Workstation (с фоновой сборкой или без) — для клиентских приложений.
• Server — использует несколько выделенных потоков GC, оптимизирован для серверных многопроцессорных сред.

Мониторинг можно выполнять через:

• Счетчики производительности (.NET CLR Memory).
• События ETW (события Windows).
• Диагностические API (GC.GetTotalMemory, GC.CollectionCount).

Практические рекомендации

1. Не вызывайте GC.Collect() явно — доверьтесь алгоритмам CLR.
2. Осторожно с финализаторами — объекты с финализаторами переживают дополнительный цикл сборки, что увеличивает нагрузку.
3. Используйте using и Dispose() для неуправляемых ресурсов.
4. Следите за утечками — даже в управляемом коде можно удерживать ссылки на объекты (например, в статических коллекциях), предотвращая их сборку.

Заключение

Сборщик мусора начинает работу автоматически при нехватке памяти в управляемой куче или в ответ на системные события. Его алгоритм, основанный на поколениях и различных типах сборки, оптимизирован для баланса между производительностью и использованием памяти. Понимание этих принципов позволяет писать более эффективные и стабильные приложения на C#.