Senior Java Backend — Вопросы на собеседовании Java разработчика

Как диагностировать утечку памяти в долгоживущем JVM-сервисе?

Сначала убедиться, что это утечка: смотреть heap после полной сборки на протяжении часов, потому что пила, возвращающаяся к базовой линии, утечкой не является. Затем снять heap dump и открыть в MAT — он покажет дерево доминаторов, то есть объекты с наибольшей удерживаемой памятью и того, кто на них ссылается. Обычные ответы: неограниченный кеш, ThreadLocal, не очищенный на пуловом потоке, или слушатели, которые регистрируются и никогда не отписываются.

Когда выбрать Saga вместо распределённой транзакции?

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

Что меняет Project Loom в написании конкурентного кода?

Виртуальные потоки делают блокировку дешёвой: поток, ожидающий ввод-вывод, больше не занимает поток ОС, поэтому модель «поток на запрос» масштабируется без реактивной обвязки. Практическое следствие — цепочки CompletableFuture и реактивные стеки, взятые исключительно ради неблокирующего кода, теряют смысл. Не меняется то, что synchronized может «пришпилить» виртуальный поток, а пулы, рассчитанные под потоки ОС, становятся неверной абстракцией.

Как выбрать между тюнингом GC и исправлением аллокаций?

Сначала измерить скорость аллокации. Если приложение выделяет гигабайты в секунду, никакие настройки сборщика не спасут, и чинить надо код — мусор в горячем цикле, боксинг, защитные копии. Тюнинг GC уместен, когда аллокации разумны, но паузы не укладываются в целевую задержку, и тогда выбор обычно между G1 с целью по паузе и ZGC, если куча настолько большая, что G1 уже не справляется.

Команда хочет разрезать монолит на микросервисы. Что спросите до согласия?

Какую проблему это решает, которую не решает граница модуля. Независимые деплои и независимое масштабирование — настоящие ответы, «микросервисы это современно» — нет. Дальше, готовы ли они к распределённым данным: никаких джойнов между сервисами, согласованность в конечном счёте и Saga вместо того, что раньше было одной транзакцией. И потянет ли эксплуатация, потому что десять сервисов с одним пайплайном и без трейсинга хуже монолита.

Как держать большую Java-кодовую базу пригодной к обновлению между LTS?

Держать зависимости близкими к актуальным постоянно, а не отдельным проектом раз в три года — стоимость растёт быстрее линейной от того, насколько вы отстали. Избегать рефлексии во внутренности JDK, потому что именно она ломается об инкапсуляцию модулей. Иметь тесты, которым доверяешь настолько, чтобы поверить зелёному прогону, и обновляться в ветке, собирающейся на обеих версиях, чтобы миграцию можно было ревьюить, а не переживать как обрыв.