Какие бывают утечки памяти?

Утечки памяти в C# и управляемых языках

Утечки памяти в контексте C# и других управляемых языков с автоматической сборкой мусора (Garbage Collection, GC) — это ситуации, когда объекты остаются в памяти, несмотря на то, что они уже не используются приложением. Хотя GC в .NET обычно эффективно освобождает память, существуют несколько категорий утечек, которые могут привести к постепенному росту потребления памяти и даже к аварийному завершению приложения.

Основные типы утечек памяти в C#

1. Утечки из-за сохранения ссылок на объекты

Это классический случай в управляемых языках. Объект остается в памяти, если на него существует хотя бы одна "живая" ссылка из активного контекста (например, из статического поля, коллекции или корня GC).

public class MemoryLeakExample
{
    private static List<byte[]> _cache = new List<byte[]>();

    public void ProcessData(byte[] data)
    {
        // Добавляем данные в "кэш", но никогда не очищаем
        _cache.Add(data);
        // Если метод вызывается часто, _cache будет бесконечно расти
    }
}

Основные причины:

• Статические коллекции или поля, которые аккумулируют объекты без механизма очистки.
• События и делегаты: если объект регистрируется как обработчик события и не отписывается, издатель события сохраняет ссылку на него.
• Коллекции как кэши без политики удаления (например, Dictionary, List).
• Неявные ссылки через захваченные переменные в лямбда-выражениях или замыканиях.

2. Утечки из-за неуправляемых ресурсов (Unmanaged Resources)

Объекты, которые используют неуправляемую память (через P/Invoke, внешние библиотеки, системные ресурсы), могут вызывать утечки, если не освобождаются правильно.

public class UnmanagedLeak
{
    private IntPtr _unmanagedHandle;

    public UnmanagedLeak()
    {
        _unmanagedHandle = NativeMethods.AllocateResource();
    }

    // Проблема: если класс не реализует IDisposable и не вызывает Dispose,
    // неуправляемый ресурс никогда не освободится
    // даже после сборки мусора управляемого объекта
}

Стандартное решение: реализация интерфейса IDisposable и использование паттерна Dispose или Finalizer.

public class SafeUnmanagedResource : IDisposable
{
    private IntPtr _handle;
    private bool _disposed = false;

    public void Dispose()
    {
        Dispose(true);
        GC.SuppressFinalize(this);
    }

    protected virtual void Dispose(bool disposing)
    {
        if (!_disposed)
        {
            if (disposing)
            {
                // Освобождаем управляемые ресурсы
            }
            NativeMethods.FreeResource(_handle); // Освобождаем неуправляемый
            _disposed = true;
        }
    }

    ~SafeUnmanagedResource() { Dispose(false); }
}

3. Утечки из-за "корней" GC (GC Roots)

GC не может собрать объекты, которые имеют активные корни. Корни включают:

• Статические поля
• Локальные переменные в активных методах (в стеке)
• Параметры методов
• Объекты в финализационной очереди (если есть финализатор)
• Ссылки из других неуправляемых объектов

4. Утечки в многопоточных контекстах

• Блокировки или ожидания, которые приводят к тому, что объекты остаются в памяти, пока поток жив (например, объекты в ThreadLocal данных, которые не очищаются).
• Неправильное использование ThreadStatic атрибутов.

5. Утечки из-за "больших объектов" (Large Object Heap, LOH)

Объекты размером более 85 000 байт размещаются в LOH. LOH не компактируется при обычной сборке мусора (до .NET 4.5.1), что может привести к фрагментации и эффективной утечке, если большие объекты постоянно создаются и освобождаются.

6. Утечки в графических интерфейсах (WinForms, WPF)

• Неотписанные обработчики событий UI элементов.
• Привязки данных (Bindings), которые не удаляются.
• Контролы, которые добавляются динамически и не удаляются из визуального дерева.

Методы диагностики и предотвращения

Диагностика:

• Использование профайлеров памяти (Visual Studio Diagnostic Tools, JetBrains dotMemory, PerfView).
• Анализ снимков памяти (snapshots) для сравнения состояния памяти в разные моменты времени.
• Мониторинг счетчиков Performance Counter (.NET CLR Memory).
• Логирование создания/удаления объектов в критических участках.

Превентивные меры:

• Строгое управление жизненным циклом объектов, особенно тех, которые хранятся в коллекциях.
• Использование WeakReference для ссылок, которые не должны препятствовать сборке мусора (например, в кэшах).
• Реализация IDisposable для классов с неуправляемыми ресурсами и использование using.
• Отписка от событий при уничтожении объектов.
• Ограничение размера кэшей и использование политик вытеснения (LRU, timeout).
• Регулярная проверка статических и глобальных коллекций.

Пример обнаружения через профайлер

В Visual Studio можно использовать Diagnostic Tools во время выполнения:

1. Запустить приложение с профилированием памяти.
2. Сделать снимок (Take Snapshot) в начале и после операции, которая может вызывать утечку.
3. Сравнить два снимка, анализируя рост количества объектов определенных типов.
4. Исследовать путь ссылок (Path to Root) для объектов, которые не были освобождены, чтобы понять, почему GC не может их собрать.

Утечки памяти в .NET — часто следствие логических ошибок в архитектуре приложения, а не прямых ошибок GC. Понимание механизмов сборки мусора и строгий контроль за жизненным циклом объектов — ключ к созданию стабильных приложений без утечек памяти.