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, бо саме вона ламається об інкапсуляцію модулів. Мати тести, яким довіряєш настільки, щоб повірити зеленому прогону, і оновлюватися в гілці, що збирається на обох версіях, аби міграцію можна було ревʼювити, а не переживати як обрив.