Сначала данные: GC-логи (-Xlog:gc*) и метрики приложения — совпадают ли пики задержек с паузами вообще. Если да — частота и длительность пауз, доля времени в GC, allocation и promotion rate, живой набор после full GC. Лечить: код и размер кучи → сборщик → флаги, по одному изменению.
А ещё Часто GC ни при чём — виноват пул соединений или внешний вызов
Так подсказку видит пользователь sotto на живом собеседовании — за пару секунд, пока вы думаете вслух.
Главное в ответе — порядок, а не список флагов. Первым делом собираешь данные: unified-логи через -Xlog:gc*, плюс метрики приложения, чтобы понять, совпадают ли пики задержек с паузами вообще, — часто выясняется, что GC ни при чём и виноват пул соединений или внешний вызов. Если совпадают, смотришь четыре вещи: длительность и частоту пауз, суммарную долю времени в GC, темп аллокаций и темп продвижения в старое поколение, а также размер живого набора после полной сборки. Дальше диагнозы читаются почти однозначно. Частые короткие minor GC — приложение производит слишком много мусора, лечится в коде: лишние промежуточные коллекции, боксинг, строки в цикле. Старое поколение растёт от сборки к сборке, full GC учащаются, а живой набор после них не падает — утечка или просто маленькая куча. Много объектов уезжает в старое поколение сразу — маловат Survivor или порог tenuring. И порядок лечения: сначала код и размер кучи, потом выбор сборщика, флаги — в последнюю очередь и по одному изменению, с повторным замером.
Ключевые флаги, unified GC-логи, метрики (паузы, throughput, allocation/promotion rate) и диагностика частых проблем.
sotto слышит вопрос интервьюера и показывает короткий ответ и план, как в блоке «Коротко». Оставьте контакт — пришлём доступ и промокод.
sotto