Как работает сборщик мусора (Garbage Collector) в C#/.NET?

Как работает сборщик мусора (Garbage Collector) в C#/.NET

Garbage Collector (GC) в .NET — это автоматический механизм управления памятью, который освобождает ресурсы, выделенные для объектов, когда они становятся недоступными. Это фундаментальная часть среды выполнения, обеспечивающая безопасность памяти и предотвращающая утечки. Работа GC основана на концепции "сборки мусора по поколениям" (generational garbage collection).

Основные принципы и поколения объектов

.NET GC делит объекты в управляемой heap (куче) на три поколения:

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

Идея: большинство объектов "умирают" молодыми, поэтому частые и быстрые сборки Gen0 эффективны, а редкие сборки Gen2 минимизируют overhead.

Алгоритм работы сборщика мусора

Процесс сборки можно описать следующим алгоритмическим шагам:

1. Определение "живых" объектов (Marking): GC начинает с "корней" (roots) — статических переменных, локальных переменных в активных стеках вызовов, регистров CPU и других указателей. Он проходит по графу объектов, маркируя все достижимые объекты как живые.
2. Освобождение "мертвых" объектов (Sweeping): Все не маркированные объекты считаются "мусором". Их память освобождается.
3. Компактизация памяти (Compaction): После удаления "мертвых" объектов GC может переместить живые объекты, чтобы сжать heap и избежать fragmentation (фрагментации). Это улучшает производительность будущих аллокаций.

Пример процесса в коде (концептуально):

// Пример создания временных объектов, которые могут быть собраны GC
public class ExampleClass
{
    public void ProcessData()
    {
        // Объект создается в Gen0
        var temporaryList = new List<int>(100);

        // После завершения метода temporaryList становится недоступным
        // Если нет других ссылок, он будет кандидатом на сборку в Gen0
    }
}

// Пример с явным влиянием на GC (не рекомендуется в обычном коде)
public void ForceGCExample()
{
    // Создание множества объектов
    for (int i = 0; i < 10000; i++)
    {
        var obj = new object();
    }

    // Явный вызов GC (обычно избегается)
    GC.Collect(0); // Запуск сборки только для Gen0
    GC.WaitForPendingFinalizers(); // Ожидание финализаторов
}

Ключевые особенности и оптимизации

• Автоматичность: GC запускается автоматически при аллокации нового объекта, если недостаточно памяти в текущем поколении, или по другим triggers (например, системные события).
• Фоновая сборка (Background GC): В современных .NET (особенно .NET Core/5+) для Gen2 используется фоновая сборка, которая выполняется параллельно с работой приложения, минимизируя pauses (паузы).
• Режимы работы GC: Существуют разные режимы, адаптированные для различных scenarious:

    * **Workstation GC:** Оптимизирован для клиентских приложений, минимизирует latency.
    * **Server GC:** Оптимизирован для серверных приложений с высокой throughput, использует несколько отдельных heap для каждого CPU core.

• Финализаторы (Finalizers): Объекты с финализаторами (~ClassName()) требуют особой обработки — они не удаляются сразу, а попадают в очередь финализации, что может задержать освобождение памяти.

Практические рекомендации для разработчика Unity

В Unity (используется .NET подмножество, чаще .NET Framework или Mono) GC играет критическую роль, так как паузы сборки могут вызывать просадки fps (фризы). Для оптимизации:

• Минимизируйте аллокации в цикле игры: Избегайте создания новых объектов в Update() без необходимости. Используйте пулы объектов (object pooling) для часто создаваемых/уничтожаемых элементов (например, снаряды).
• Следите за ссылочными типами в структурах: Структуры (struct) в Unity часто используются для оптимизации, но если они содержат ссылки на классы, это может увеличить нагрузку на GC.
• Используйте IDisposable для управления ресурсами: Для объектов, владеющих неуправляемыми ресурсами (например, текстуры, сетевые соединения), реализуйте IDisposable для явного освобождения.
• Профилируйте с помощью Unity Profiler: Мониторинг показателей GC (коллекций, аллокаций) в Profiler помогает находить проблемные места.

// Пример пула объектов в Unity для уменьшения аллокаций
public class GameObjectPool
{
    private Queue<GameObject> _pool = new Queue<GameObject>();
    private GameObject _prefab;

    public GameObjectPool(GameObject prefab, int initialSize)
    {
        _prefab = prefab;
        for (int i = 0; i < initialSize; i++)
        {
            var obj = Instantiate(_prefab);
            obj.SetActive(false);
            _pool.Enqueue(obj);
        }
    }

    public GameObject GetObject()
    {
        if (_pool.Count > 0)
        {
            var obj = _pool.Dequeue();
            obj.SetActive(true);
            return obj;
        }
        // Расширение пула при необходимости
        return Instantiate(_prefab);
    }

    public void ReturnObject(GameObject obj)
    {
        obj.SetActive(false);
        _pool.Enqueue(obj);
    }
}

Вывод: Сборщик мусора в .NET — мощный и сложный механизм, который в большинстве случаев работает эффективно "из коробки". Однако для высоконагруженных приложений, особенно в реальном времени как Unity игры, понимание его работы и proactive оптимизация аллокаций памяти критически важны для стабильной производительности.