Как можно управлять GC вручную?

Сборка мусора (Garbage Collection, GC) — это автоматический процесс управления памятью, который освобождает объекты, больше не используемые программой. В языках с автоматическим управлением памятью (Java, C#, Python, Go, JavaScript) GC работает в фоновом режиме, и прямое "ручное" управление им обычно не предусмотрено дизайном языка, так как это может нарушить оптимизации и привести к непредсказуемым паузам.

Косвенное влияние на GC

Разработчики могут давать подсказки (hints) сборщику или влиять на его поведение:

• Java: Метод System.gc() или Runtime.getRuntime().gc() — это запрос к JVM запустить сборку мусора, но JVM может его проигнорировать. Использовать в продакшене не рекомендуется.
• .NET (C#): Метод GC.Collect() принудительно запускает сборку. Его можно использовать в узких сценариях, например, при тестировании или в точках, где известно, что освободится много памяти.
• Python: Модуль gc предоставляет функции gc.collect() для ручного запуска и gc.disable()/gc.enable() для отключения/включения GC. Это полезно в реальном времени или при работе с циклическими ссылками.
• Go: Пакет runtime позволяет вызвать runtime.GC() для принудительной сборки, а также настроить процент CPU для GC через debug.SetGCPercent().

Пример кода на C#

// Принудительный запуск сборки мусора для поколения 0 и 1
GC.Collect(0, GCCollectionMode.Forced);
// Ожидание завершения финализаторов (опционально)
GC.WaitForPendingFinalizers();
// Сборка для всех поколений
GC.Collect();
// Освобождение неуправляемых ресурсов вручную — ключевой паттерн
using (var resource = new FileStream("test.txt", FileMode.Open))
{
    // работа с ресурсом
} // Dispose вызовется автоматически, помогая GC

Языки с ручным управлением памятью

В C, C++ и Rust нет встроенного GC. Разработчик полностью контролирует жизненный цикл объектов:

• C: malloc() и free().
• C++: Операторы new/delete и умные указатели (std::unique_ptr, std::shared_ptr), которые автоматически освобождают память при выходе из области видимости.
• Rust: Система владения (ownership) и заимствования (borrowing) гарантирует безопасность памяти без GC.

Вывод: Прямое управление GC требуется редко, в основном для тонкой оптимизации в высоконагруженных приложениях (игры, реальное время) или при работе с неуправляемыми ресурсами. В обычных приложениях лучше полагаться на автоматический GC, а для контроля использовать профилировщики памяти.