Как Сборщик мусора понимает что нужно удалить объект?

Принципы определения «живых» объектов в .NET Garbage Collector (GC)

Сборщик мусора (Garbage Collector, GC) в .NET не удаляет объекты напрямую. Вместо этого он определяет, какие объекты ещё «живы» (то есть достижимы и используются программой), а все остальные считает «мусором» (garbage) и освобождает занимаемую ими память. Этот процесс основан на концепции достижимости (reachability).

Основной механизм: достижимость через граф объектов

GC строит в памяти граф объектов, начиная с корневых ссылок (GC roots). Если от корней можно добраться до объекта по цепочке ссылок, объект считается живым. В противном случае — мусором.

Корневые ссылки (GC Roots) включают:

• Статические поля (static) всех загруженных типов.
• Локальные переменные и параметры методов в текущих стеках всех потоков (active call stacks).
• Ссылки в регистрах ЦПУ.
• Ссылки из управляемых объектов в неуправляемые (например, через P/Invoke или COM), которые отслеживаются специальной структурой — Handle Table (например, GCHandle).

Алгоритм маркировки (Marking Phase)

Процесс определения живых объектов происходит во время фазы маркировки:

// Пример для иллюстрации графа объектов
class Program
{
    static Customer _activeCustomer = new Customer("John"); // Статическое поле - КОРЕНЬ

    static void Main()
    {
        Order currentOrder = new Order(100); // Локальная переменная в стеке - КОРЕНЬ
        _activeCustomer.LastOrder = currentOrder;

        // В этот момент граф достижимости:
        // _activeCustomer (static root) -> Customer -> Order <- currentOrder (stack root)
        // Оба объекта достижимы.

        currentOrder = null; // Убираем одну корневую ссылку
        // Теперь Order достижим только через цепочку от _activeCustomer.
        // Он всё ещё жив.

        _activeCustomer = null; // Убираем последний корень
        // Теперь ни Customer, ни Order не достижимы от корней.
        // ОБА объекта становятся кандидатами на удаление GC.
    }
}

class Customer
{
    public Order LastOrder { get; set; }
    public Customer(string name) { }
}

class Order
{
    public decimal Amount { get; }
    public Order(decimal amount) { Amount = amount; }
}

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

Нюансы и важные детали

• Поколения (Generations). Куча разделена на 3 поколения (0, 1, 2) для оптимизации. Большинство объектов умирают молодыми (сборка поколения 0 происходит часто и быстро). GC может собирать только одно поколение, при этом автоматически считаются живыми все объекты в более старших поколениях, так как они достижимы по определению алгоритма.
• Финализаторы (Finalizers). Объекты с переопределённым методом Finalize() (~деструктор в C#) не удаляются сразу после первой сборки, когда они стали недостижимы. Вместо этого они помещаются в очередь финализации, и их финализатор выполняется отдельным потоком. Только после этого объект окончательно удаляется при следующем проходе GC.

  class ResourceHolder
  {
      ~ResourceHolder() // Финализатор
      {
          // Код освобождения неуправляемых ресурсов.
          // Объект будет "воскрешён" и переживёт одну сборку.
      }
  }
  

• Слабые ссылки (WeakReference). Они позволяют ссылаться на объект, не защищая его от сборки мусора. GC игнорирует слабые ссылки при построении графа достижимости. Это полезно для кешей.

  var weakRef = new WeakReference<MyObject>(myObject);
  // ... если нет других (сильных) ссылок на myObject ...
  GC.Collect();
  weakRef.TryGetTarget(out var target); // target, скорее всего, будет null
  

Практические выводы для разработчика

• GC работает автоматически, но понимание его принципов помогает избегать утечек памяти.
• Основная причина утечек в .NET — неявно сохраняющиеся ссылки на объекты, которые делают их достижимыми, хотя по логике программы они уже не нужны (например, подписки на события, статические коллекции, кеши без политики очистки).
• Явный вызов GC.Collect() требуется крайне редко и обычно вредит производительности, нарушая естественные эвристики сборщика.

Итог: Сборщик мусора понимает, что объект можно удалить, не анализируя логику программы, а через формальный алгоритм построения графа достижимости от набора корней. Любой объект в управляемой куче, до которого невозможно добраться, двигаясь по ссылкам от этих корней, считается мусором и будет удалён в процессе сборки.