В проде выросли задержки, подозрение на GC. Опиши порядок диагностики — от сбора данных до вывода.

Главное в ответе — порядок, а не список флагов. Первым делом собираешь данные: unified-логи через -Xlog:gc*, плюс метрики приложения, чтобы понять, совпадают ли пики задержек с паузами вообще, — часто выясняется, что GC ни при чём и виноват пул соединений или внешний вызов. Если совпадают, смотришь четыре вещи: длительность и частоту пауз, суммарную долю времени в GC, темп аллокаций и темп продвижения в старое поколение, а также размер живого набора после полной сборки. Дальше диагнозы читаются почти однозначно. Частые короткие minor GC — приложение производит слишком много мусора, лечится в коде: лишние промежуточные коллекции, боксинг, строки в цикле. Старое поколение растёт от сборки к сборке, full GC учащаются, а живой набор после них не падает — утечка или просто маленькая куча. Много объектов уезжает в старое поколение сразу — маловат Survivor или порог tenuring. И порядок лечения: сначала код и размер кучи, потом выбор сборщика, флаги — в последнюю очередь и по одному изменению, с повторным замером.