Когда инициируется сборка мусора?

Механизм инициирования сборки мусора (Garbage Collection) в .NET

Сборка мусора (Garbage Collection, GC) в .NET — это автоматический процесс управления памятью, который освобождает объекты, более не используемые приложением. Точный момент инициирования GC не детерминирован и контролируется средой выполнения CLR (Common Language Runtime) на основе сложных эвристик. Однако можно выделить ключевые условия и триггеры.

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

1. Нехватка памяти в управляемой куче (Managed Heap)
   Наиболее частый сценарий. CLR отслеживает выделение объектов в поколениях кучи (Generation 0, 1, 2). При попытке выделить новый объект, если в текущем поколении (особенно в Gen 0) недостаточно свободного места, автоматически запускается сборка мусора для этого поколения.

2. Вызов GC.Collect() вручную
   Хотя это крайне не рекомендуется для production-кода (так как нарушает оптимизированную стратегию CLR), разработчик может явно запросить сборку мусора:

   // Принудительная сборка для всех поколений
   GC.Collect();
   
   // Сборка для конкретного поколения
   GC.Collect(0, GCCollectionMode.Optimized);
   

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

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

4. Нехватка физической памяти (системное давление)
   Если операционная система сигнализирует о высокой загрузке памяти, сборщик мусора может активироваться в аварийном режиме, даже если в управляемой куче ещё есть свободное пространство. Это часть механизма адаптации к ограничениям среды.

5. Приостановка работы приложения
   В некоторых случаях CLR может запустить GC при приостановке потока или переходе в состояние ожидания, если система сочтёт это эффективным моментом.

6. Работа с большими объектами (Large Object Heap — LOH)
   Объекты размером ≥ 85 000 байт размещаются в LOH. Сборка LOH происходит реже (обычно вместе с Gen 2), но может быть инициирована при нехватке памяти в этом регионе.

Стратегия поколений (Generations) как ключевой фактор

GC использует поколенческую модель, что напрямую влияет на частоту инициирования:

• Gen 0: Молодые объекты. Сборка происходит чаще всего (примерно каждые несколько сотен мегабайт выделений в 64-битных системах).
• Gen 1: Промежуточные объекты, пережившие одну сборку. Сборка происходит реже, обычно после очистки Gen 0.
• Gen 2: Долгоживущие объекты. Сборка наиболее затратна и происходит реже, часто при нехватке памяти или явном вызове.

Влияние режима работы GC

Тип сборки (Workstation vs. Server) и режим (фоновый/нефоновый) также определяют поведение:

• Workstation GC: Оптимизирован для отзывчивости UI, сборки короткие и частые.
• Server GC: Оптимизирован для пропускной способности, использует отдельные потоки и более агрессивные стратегии.
• Фоновая сборка (Background GC): Для Gen 0 и Gen 1 выполняется параллельно с работой приложения, не блокируя потоки надолго. Для Gen 2 выполняется в фоне, уменьшая паузы.

Пример наблюдения за триггерами GC

using System;

class Program
{
    static void Main()
    {
        // Мониторинг сборок мусора через события
        GC.RegisterForFullGCNotification(10, 10);
        Task.Run(() => WaitForGCNotification());

        // Имитация нагрузки для триггера GC
        var list = new List<byte[]>();
        for (int i = 0; i < 1000; i++)
        {
            // Выделение 10 МБ может спровоцировать сборку Gen 0/1
            list.Add(new byte[10 * 1024 * 1024]);
            Console.WriteLine($"Выделено: {(i + 1) * 10} МБ");
        }
    }

    static void WaitForGCNotification()
    {
        while (true)
        {
            if (GC.WaitForFullGCApproach() != GCNotificationStatus.Succeeded)
                continue;
            Console.WriteLine("### GC приближается (нехватка памяти) ###");
            
            if (GC.WaitForFullGCComplete() != GCNotificationStatus.Succeeded)
                continue;
            Console.WriteLine("### GC завершён ###");
        }
    }
}

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

• Не полагайтесь на явные вызовы GC.Collect() — CLR лучше управляет памятью в большинстве сценариев.
• Учитывайте паттерны выделения памяти: частые аллокации мелких объектов провоцируют сборки Gen 0.
• Используйте профилировщик памяти (dotTrace, Visual Studio Diagnostic Tools) для анализа триггеров GC в вашем приложении.

Инициирование сборки мусора — это баланс между использованием памяти и производительностью, который CLR поддерживает динамически, адаптируясь к поведению приложения и доступным ресурсам системы.