Разберите, почему вызов System.gc() не позволяет сделать вывод, что недостижимые объекты уже освобождены.
System.gc() — это только запрос к JVM на проведение сборки мусора, а не обязательная команда немедленно освободить память. JVM может проигнорировать запрос, отложить сборку или выполнить цикл, который не освобождает всю потенциально доступную память.
Даже после фактически выполненной сборки освобождаются только объекты, недостижимые из GC Roots и подходящие под правила конкретного сборщика. Поэтому сам вызов не является надежным способом проверить момент освобождения объектов или управлять паузами приложения.
Ранние Java-приложения нуждались в совместимом с разными реализациями JVM способом попросить виртуальную машину обратить внимание на нехватку памяти. API предоставил такую возможность, не раскрывая внутреннее устройство конкретного сборщика.
Такой подход позволил одной программе работать с разными JVM и алгоритмами GC. Обратная сторона — отсутствие жесткого контракта о времени запуска сборки, ее длительности и объеме освобожденной памяти.
Разработчик может вызвать System.gc() перед измерением производительности, после закрытия большого объекта или при обработке запроса с надеждой немедленно вернуть память операционной системе. Это приводит к нестабильным задержкам, лишним паузам и ошибочным выводам о причинах утечек.
Кроме того, недостижимые объекты не обязаны исчезнуть из памяти сразу после запроса. Их обработка может быть отложена, а часть памяти может остаться внутри уже выделенных регионов или арен JVM и не вернуться операционной системе.
Вызов передает JVM рекомендацию выполнить сборку мусора. Реализация может учитывать текущую нагрузку, выбранный сборщик, состояние Java-потоков и внутреннюю политику управления памятью. Некоторые конфигурации позволяют полностью отключить реакцию на явные запросы или изменить их влияние на выбранный сборщик, поэтому поведение нельзя переносить между JVM без проверки.
Сборщик начинает с поиска объектов, достижимых от GC Roots: активных стеков потоков, статических ссылок, JNI-ссылок и других корней, определяемых JVM. Объект может быть освобожден только после того, как он перестал быть достижимым по правилам используемого сборщика; сам факт вызова System.gc() не меняет граф ссылок.
Сборка может быть частичной или конкурентной. В конкурентном цикле работа приложения продолжается параллельно с GC, поэтому между вызовом и фактическим освобождением конкретного объекта проходит неопределенное время. Даже завершение цикла не означает обязательного возврата соответствующих страниц операционной системе.
Для диагностики утечек лучше использовать heap dump, анализ удерживающих ссылок и профилирование, а не принудительные вызовы GC. Для производительности следует измерять приложение в условиях, близких к рабочим, и не маскировать проблему ручными сборками.
Сервис формирует большой временный отчет. После его отправки разработчик добавляет System.gc(), чтобы уменьшить RSS перед следующим запросом. На тестовом стенде паузы становятся заметными, а RSS почти не меняется.
Вариант с регулярным вызовом GC прост, но создает непредсказуемые задержки и не гарантирует возврат памяти ОС. Вариант с увеличением heap уменьшает вероятность частых сборок, но не устраняет удерживающие ссылки и может увеличить общий объем процесса.
Правильное решение — сначала проверить heap dump и убедиться, что отчет действительно недостижим: например, его не удерживают кэш, очередь, статическое поле или незавершенная задача. Затем подбирают размер heap и параметры сборщика по метрикам пауз и пропускной способности, не используя System.gc() как механизм управления памятью. Результатом становится предсказуемая работа без искусственных глобальных сборок.
Да. Это необязательный запрос, и JVM вправе его проигнорировать. На поведение также могут влиять параметры запуска и политика конкретной реализации JVM, поэтому наличие вызова в коде не доказывает, что GC начался.
Нет. Потеря достижимости только делает объект кандидатом на сборку. Он будет освобожден во время подходящего цикла GC, а время этого цикла зависит от сборщика, текущей нагрузки и его эвристик.
Не обязательно. Сборщик может повторно использовать освобожденные области внутри heap, не отдавая их ОС. Поэтому уменьшение живого набора объектов, размера занятого heap и RSS — разные наблюдения, которые нужно анализировать отдельно.