Можно ли вызвать Garbage Collector явно?

Можно ли явно вызвать сборщик мусора (Garbage Collector) в Java/Kotlin?

Да, явно попросить JVM выполнить сборку мусора технически возможно, но это крайне не рекомендуется в production-коде, и такие вызовы не дают никаких гарантий. Это один из классических вопросов на собеседовании, который проверяет понимание работы памяти и принципов работы GC.

Как это сделать?

В стандартном API Java существуют два способа:

1. Вызов System.gc()
2. Вызов Runtime.getRuntime().gc() (внутри себя System.gc() просто делегирует вызов этому методу).

Пример на Java:

public class GCDemo {
    public static void main(String[] args) {
        // Создаем мусор
        for (int i = 0; i < 100_000; i++) {
            new Object();
        }

        // Явный "запрос" на сборку мусора
        System.gc();

        // Альтернативный вариант
        // Runtime.getRuntime().gc();
    }
}

Пример на Kotlin:

fun main() {
    repeat(100_000) {
        Any() // Создаем мусор
    }

    kotlin.system.exitProcess(0) // Прямого gc() в kotlin.stdlib нет, используем Java-метод
    // Но можно вызвать через Runtime:
    Runtime.getRuntime().gc()
}

Почему вызов не является гарантированным и не рекомендуется?

Ключевой момент: System.gc() — это не команда, а настойчивая рекомендация (hint) для JVM. Виртуальная машина имеет полное право проигнорировать этот вызов. Решение о запуске сборщика мусора и о том, какой именно GC алгоритм использовать, остается за JVM, которая руководствуется собственной эвристикой, статистикой заполненности heap'а (кучи) и выбранными параметрами запуска.

Основные причины не вызывать GC явно:

1. Нарушение работы алгоритмов JVM. Современные сборщики мусора (G1, ZGC, Shenandoah) — это высокооптимизированные, сложные системы с долгосрочной статистикой и прогнозированием. Ручные вызовы сбивают эти алгоритмы, мешая им работать оптимально. Это может привести к снижению общей производительности.
2. Высокая стоимость полной сборки. Вызов System.gc() часто запускает full GC (Major Collection), которая "стопит мир" (Stop-The-World). Это приводит к полной паузе в работе приложения на сотни миллисекунд или даже секунды, что недопустимо для интерактивных и реального времени (real-time) приложений, особенно на Android, где важен плавный UI (60 FPS).
3. Непредсказуемость. Результат вызова зависит от реализации JVM, версии, производителя (HotSpot, OpenJ9) и установленных флагов JVM. Например, флаг -XX:+DisableExplicitGC полностью отключает реакцию на вызовы System.gc(), превращая их в пустые операции.
4. Ошибки в дизайне приложения. Чаще всего желание вручную вызвать GC сигнализирует о проблемах в архитектуре: утечках памяти (memory leaks), неоптимальных циклах жизни объектов, неправильном использовании кешей или коллекций. Правильное решение — профилирование приложения с помощью Android Profiler, Memory Analyzer (MAT) или Perfetto для поиска реальных причин, а не попытки "замести мусор под ковер".

Когда (очень осторожно) это может быть оправдано?

В исключительных сценариях, не связанных с типичной разработкой под Android:

• Написание микро-бенчмарков для изоляции влияния GC на замеры (хотя для этого лучше использовать JMH).
• Специфические нативные (native) интерфейсы, где необходимо гарантировать освобождение слабых ссылок перед выполнением определенной операции.
• Диагностика и отладка памяти в контролируемых условиях, чтобы "увидеть" базовый уровень использования памяти после очистки.

Вывод для Android-разработчика

В контексте Android-разработки явной вызов сборщика мусора считается антипаттерном. Вы не контролируете среду выполнения на устройствах пользователей, а паузы в работе UI абсолютно недопустимы. Вместо этого следует:

• Профилировать память с помощью Android Studio Profiler.
• Анализировать утечки с помощью LeakCanary.
• Правильно использовать слабые (WeakReference) и мягкие (SoftReference) ссылки там, где это уместно.
• Оптимизировать жизненные циклы объектов в ViewModel, LiveData, очищать подписки (например, в onCleared()).
• Избегать ненужных аллокаций объектов в циклах и на критичных по производительности путях (например, в onDraw()).

Таким образом, хотя техническая возможность есть, профессиональный разработчик должен понимать, что реальный вызов GC остается прерогативой JVM, а задача программиста — писать код, который не создает излишней нагрузки на систему сборки мусора.