С какой периодичностью сборщик мусора в JVM очищает память

Что проверяют

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

Как отвечать

Скажите прямо: сборщик не работает по таймеру, он срабатывает, когда не удаётся выделить память или когда занятость области перешла порог. Дальше разложите по поколениям:

• молодая сборка случается, когда заполняется область для новых объектов. Живые объекты переезжают, остальное освобождается скопом, поэтому она дешёвая;
• сборка старого поколения запускается по заполнению или по порогу, после которого сборщик начинает работу заранее, чтобы успеть до исчерпания памяти;
• полная сборка с остановкой всех потоков остаётся аварийным вариантом, когда освободить память иначе не вышло.

Отсюда вывод, который и хотят услышать: частота зависит от темпа выделения памяти приложением, от размера кучи и её областей, от выбранного сборщика и его настроек. Приложение, которое создаёт мусор в цикле, будет собирать молодое поколение постоянно, а спокойный сервис с большой кучей может не трогать старое поколение сутками. Уместно добавить, что смотреть на это надо по логам сборки и по паузам, а не рассуждать в теории.

Где спотыкаются

Называют интервал в секундах. Такого параметра нет ни у одного сборщика, есть цели по паузам и пороги заполнения, но не расписание.

Считают, что System.gc() гарантированно запускает сборку. Это лишь подсказка, которую виртуальная машина вправе проигнорировать, а в рабочей системе такой вызов обычно делает хуже.

Думают, что объект освобождается сразу после обнуления ссылки. Он только становится недостижимым, а память вернётся на ближайшей сборке нужной области, и полагаться на момент нельзя.