Расскажите об опыте настройки размера heap в Java и используемых параметрах

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

Есть ли у вас опыт эксплуатации, а не заученный список флагов. Хороший ответ начинается не с параметров, а с того, как вы поняли, что памяти не хватает или что настройки мешают. Заодно проверят, понимаете ли вы, что куча это не вся память процесса.

Как отвечать

Начните с диагностики: логи сборщика мусора включаются унифицированным логированием, -XX:+HeapDumpOnOutOfMemoryError вместе с путём для дампа спасает расследование, дальше дамп разбирается в анализаторе. Смотреть надо на живой объём после полной сборки: именно он говорит, сколько памяти приложению реально нужно.

Дальше параметры. -Xms и -Xmx часто ставят равными, чтобы не платить за постепенное расширение кучи и получить предсказуемое поведение сборщика. Метапространство ограничивается отдельно, прямые буферы тоже живут вне кучи. В контейнере абсолютное значение задавать неудобно: -XX:MaxRAMPercentage считает долю от лимита контейнера, и при изменении лимита ничего не надо переписывать.

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

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

Считают, что -Xmx ограничивает память процесса. Метапространство, стеки потоков, кэш скомпилированного кода и прямые байтовые буферы находятся вне кучи, поэтому контейнер спокойно убивает процесс по лимиту памяти при формально свободной куче.

Лечат ошибку нехватки памяти увеличением -Xmx. Если объекты удерживаются ссылками, большая куча просто отодвигает падение и удлиняет паузы. Сначала дамп и поиск того, что держит память, потом настройки.

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