Приходилось ли смотреть логи GC в Java

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

Работали ли вы с JVM под нагрузкой или знаете про сборщик мусора только по учебнику. Вопрос отделяет тех, кто открывал лог на проде во время инцидента, от тех, кто пересказывает главу про поколения.

Как отвечать

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

Как включали. В свежих JVM это единое логирование, например -Xlog:gc*:file=gc.log:time,uptime,level,tags. Флаги -XX:+PrintGCDetails и -XX:+PrintGCDateStamps остались от восьмой версии, и формат вывода у них другой.

Что смотрели в логе:

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

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

Опыта нет, так и скажите, но покажите, куда смотреть и что включить.

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

Называют флаги восьмой версии как текущие. Инструменты разбора тоже разошлись: парсер старого формата не прочитает единое логирование, и наоборот.

Вторая ошибка: «добавили памяти, и стало лучше». Больше куча, длиннее полная сборка, а если это утечка, она просто отодвигается. Диагноз здесь дают дамп кучи и график живых данных, а не размер кучи.

Третья: заученная история с процентами прироста. Спросят, чем меряли и на каком перцентиле, и ответа нет. Лучше назвать конкретную величину: длительность самой долгой паузы и долю времени, проведённого в сборке.