Перейти на PRO

Как и когда можно явно вызвать сборщик мусора (Garbage Collector) в C#?

Тип вопроса: Управление памятью Вероятность: 25% Категория: C# Разработчик

Ответ

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

Синтаксис вызова:

// Простой вызов сборки для поколения 0 и 1 (реже 2)
GC.Collect();

// Вызов для конкретного поколения (0, 1, 2)
GC.Collect(2); // Принудительная полная сборка

// Рекомендуемый паттерн для сценариев с финализаторами:
// 1. Запуск сборки
GC.Collect();
// 2. Ожидание завершения финализаторов для собранных объектов
GC.WaitForPendingFinalizers();
// 3. Ещё одна сборка, чтобы очистить память от самих финализированных объектов
GC.Collect();

Когда это может быть оправдано (с большой осторожностью):

  1. Профилирование и тестирование: Например, чтобы измерить "чистое" потребление памяти после выполнения определённого блока кода. 
    long before = GC.GetTotalMemory(false);
// ... выполнение исследуемого кода ...
GC.Collect(); // Принудительная уборка для точного замера
GC.WaitForPendingFinalizers();
long after = GC.GetTotalMemory(true);
Console.WriteLine($"Used memory: {after - before} bytes");
  2. Сценарии с большими, чётко ограниченными временными интервалами: Например, в симуляциях или графических редакторах, где есть явная "пауза" (например, между уровнями игры), и нужно гарантированно освободить память перед следующей ресурсоёмкой операцией.

Почему обычно не нужно вызывать GC.Collect():

  • Нарушение эвристик GC: GC сам определяет оптимальный момент для сборки, основываясь на выделении памяти и фрагментации. Ручные вызовы сбивают эти алгоритмы.
  • Снижение производительности: Полная сборка мусора (особенно поколения 2) — дорогая операция, "останавливающая мир" (stop-the-world).
  • Маскировка реальных проблем: Частая потребность в ручной сборке часто указывает на проблемы в архитектуре, такие как утечки памяти (особенно из-за неправильных подписок на события, кэшей без ограничений) или чрезмерное выделение памяти в "горячих" путях (аллокации в циклах).

Правильный подход: Вместо ручного вызова GC сфокусируйтесь на:

  • Использовании using для IDisposable объектов.
  • Избегании долгоживущих ссылок на короткоживущие объекты.
  • Профилировании памяти с помощью инструментов (dotMemory, Visual Studio Diagnostic Tools) для поиска реальных утечек.

Ответ 18+ 🔞

Да ты посмотри, какая дичь! Люди берут и вставляют GC.Collect() куда попало, будто это волшебная таблетка от всех проблем с памятью. Ну блядь, так не работает!

Смотри, в .NET этот сборщик — не дурак, он умный, как черт. Сам знает, когда пора подмести. А ты ему со своим GC.Collect() влезаешь, как сантехник с кувалдой в тонкий часовой механизм. Он там свои алгоритмы выстроил, поколения считает, а ты — хуяк! — и всё к чертям.

Вот смотри, как это выглядит в коде, если уж совсем приперло:

// Ну допустим, решил ты поиграть в бога
GC.Collect(); // Эй, мусорщик, работай!
GC.WaitForPendingFinalizers(); // Стой, дай финализаторы допиздюкаться!
GC.Collect(); // А теперь убери за этими финализаторами тоже!

Когда это хоть как-то можно выгородить? Да почти никогда, честно.

Разве что:

  1. Ты профилировщик, или тестируешь что-то. Ну типа, хочешь замерить память "по чесноку". 
    long was = GC.GetTotalMemory(false);
// ... тут твой код навалил кучу...
GC.Collect();
GC.WaitForPendingFinalizers();
long became = GC.GetTotalMemory(true);
Console.WriteLine($"Насрало на {became - was} байт, поздравляю.");
  2. У тебя есть четкие, долгие простои. Типа между загрузками уровней в игре. Вот тут, в тишине и покое, можно сказать: "А давайте-ка, сука, всю память почистим нахуй, чтобы к следующему уровню быть пушистыми".

А почему в основном НЕ НАДО? Да потому что:

  • Ты ломаешь всю его логику. GC сам умный, он видит: "О, аллокаций много пошло, поколение 0 заполнилось — ща я всё быстро почищу". А ты ему внезапно: "А НЕТ, ЧИСТИ СЕЙЧАС ВСЁ ДО ПОКОЛЕНИЯ 2!". Он тебе такой: "Ну бля... ладно". И начинает тяжелую, долгую уборку, которая всем потоки приостановит. Производительность — в пизду.
  • Ты маскируешь реальные косяки. Если тебе постоянно хочется вызывать сборку в коде — это не GC тупой. Это у тебя, скорее всего, утечка памяти, чувак. Где-то подписался на событие и не отписался. Или кеш без ограничения растёт, как на дрожжах. Или в цикле тонны объектов создаёшь. Вот ищи эту хуйню, а не дергай сборщик, как собаку на цепи.

Что делать-то нормальному человеку?

  • Используй using для всего, что реализует IDisposable. Вообще, привычка должна быть железная.
  • Не держи ссылки на объекты, которые уже не нужны. Особенно в статических полях, блядь — это могила.
  • Бери профайлер (dotMemory, да хоть штатные средства Visual Studio) и смотри, куда память реально уходит. А не гадай на кофейной гуще с вызовами Collect().

Короче, запомни: GC.Collect() — это как аварийный тормоз в поезде. Не для каждой остановки его дергать, а то все пассажиры по стеклу размажутся. Используй только если точно знаешь, что делаешь, и все другие варианты — полная хуйня.

Видео-ответы

© ХакСобесов, 2026
support@hacksobesov.com