Как работает сборщик мусора (GC) в .NET: поколения, LOH, финализация?

#Зачем нужен GC и как он находит мусор

В C# вы пишете new, но никогда не пишете delete. Памятью управляет сборщик мусора — часть CLR. Он периодически останавливает (частично или полностью) управляемые потоки и определяет, какие объекты ещё нужны.

Алгоритм — mark & compact:

1. Mark (пометка). GC начинает с корней (roots) и обходит граф ссылок. Всё, до чего удалось дойти, — живое.
2. Plan / Sweep. Всё непомеченное — мусор. GC решает, выгоднее ли уплотнить кучу или просто запомнить свободные промежутки.
3. Compact (уплотнение). Живые объекты сдвигаются друг к другу, ссылки на них обновляются. Освобождённая память становится одним непрерывным блоком — поэтому следующая аллокация в .NET стоит почти как инкремент указателя.

#Поколения: почему не собирать всю кучу сразу

Обходить весь граф объектов при каждой сборке дорого. Поэтому .NET опирается на гипотезу поколений: большинство объектов умирает молодыми (DTO запроса, строки, временные списки), а те, что выжили, скорее всего проживут долго (синглтоны, кэши).

Ключевое правило: сборка поколения N собирает и все младшие поколения. Gen 2 GC — это full GC.

#Как старшие поколения ссылаются на младшие

Если при сборке Gen 0 обходить только Gen 0, как узнать, что на молодой объект ссылается старый объект из Gen 2? Для этого есть card table: при каждой записи ссылки в поле объекта JIT вставляет write barrier, который помечает «карту» (участок памяти) как грязную. При сборке Gen 0 GC дополнительно просматривает только грязные карты старших поколений.

#Large Object Heap (LOH)

Объекты размером 85 000 байт и больше (обычно массивы: byte[], большие string, List<T> с большим внутренним массивом) размещаются в отдельной куче — LOH.

• LOH собирается только при Gen 2 GC.
• Копировать большие объекты дорого, поэтому по умолчанию LOH не компактируется, а управляется списком свободных блоков. Итог — фрагментация: свободной памяти много, но непрерывного куска нужного размера нет, и процесс растёт.
• Частые аллокации больших буферов (чтение файлов, сериализация, MemoryStream.ToArray()) → частые full GC.

// Плохо: каждый запрос создаёт новый буфер 1 МБ → LOH → частые Gen 2 GC
var buffer = new byte[1024 * 1024];

// Хорошо: берём буфер из пула и возвращаем после использования
var pooled = ArrayPool<byte>.Shared.Rent(1024 * 1024);
try
{
    int read = await stream.ReadAsync(pooled.AsMemory(0, 1024 * 1024), ct);
    Process(pooled.AsSpan(0, read));
}
finally
{
    ArrayPool<byte>.Shared.Return(pooled);
}

// Разовое уплотнение LOH при следующем full GC (применять осознанно)
GCSettings.LargeObjectHeapCompactionMode = GCLargeObjectHeapCompactionMode.CompactOnce;
GC.Collect();

Для потоков вместо MemoryStream используйте RecyclableMemoryStream (пакет Microsoft.IO.RecyclableMemoryStream) — он переиспользует блоки и не создаёт больших массивов.

#Финализация

Финализатор (~MyClass() в C#) — метод, который CLR вызывает перед освобождением памяти объекта. Он нужен как страховка для освобождения неуправляемых ресурсов, если разработчик забыл вызвать Dispose().

Цена финализатора высока:

1. При создании объект регистрируется в finalization queue — аллокация уже дороже.
2. На первой сборке объект признан мёртвым, но вместо освобождения переносится в f-reachable queue и тем самым воскрешается вместе со всем, на что ссылается.
3. Единственный поток финализатора вызывает Finalize(). Порядок не гарантирован, время — тоже.
4. Только на следующей сборке (уже старшего поколения!) память освобождается.

Если финализатор зависнет или будет медленным — очередь растёт, память утекает.

public sealed class NativeBuffer : IDisposable
{
    private IntPtr _ptr = Marshal.AllocHGlobal(4096);
    private bool _disposed;

    public void Dispose()
    {
        if (_disposed) return;
        Marshal.FreeHGlobal(_ptr);
        _disposed = true;
        GC.SuppressFinalize(this); // объект уходит из очереди финализации — без лишней сборки
    }

    ~NativeBuffer() // страховка, если Dispose забыли вызвать
    {
        if (!_disposed) Marshal.FreeHGlobal(_ptr);
    }
}

#Режимы работы GC

<PropertyGroup>
  <ServerGarbageCollector>true</ServerGarbageCollector>
  <ConcurrentGarbageCollection>true</ConcurrentGarbageCollection>
  <!-- Ограничение кучи в контейнере: 70% от лимита памяти -->
  <GCHeapHardLimitPercent>0x46</GCHeapHardLimitPercent>
</PropertyGroup>

#Как посмотреть на GC вживую

dotnet-counters monitor -p <PID> --counters System.Runtime
# gc-heap-size, gen-0-gc-count, gen-2-gc-count, time-in-gc, loh-size ...

dotnet-gcdump collect -p <PID>   # снимок кучи → открыть в Visual Studio / PerfView

Тревожные признаки: % time in GC стабильно выше 10–20%, быстрый рост gen-2-gc-count, растущий loh-size.

#Типичные ошибки

• Большие буферы на каждый запрос → LOH и частые Gen 2 сборки. Решение: ArrayPool, RecyclableMemoryStream, стриминг.
• Финализатор без GC.SuppressFinalize в Dispose — каждый объект переживает лишнюю сборку.
• Статические коллекции и события, которые удерживают объекты навсегда — «утечка» в управляемой памяти (GC не соберёт то, что достижимо).
• Думать, что Dispose освобождает память. Нет: Dispose освобождает ресурсы, память объекта освободит GC.

#Вопросы на засыпку

#Итог

GC в .NET быстрый, если ему помогать: меньше аллокаций на горячих путях, пулы для больших буферов, Dispose/using вместо финализаторов, никаких бесконечно растущих статических коллекций. На собеседовании достаточно уверенно нарисовать путь объекта Gen 0 → Gen 1 → Gen 2, объяснить LOH и две сборки для объекта с финализатором.