Какие технические проблемы и слабые стороны JVM как платформы?

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

Знаете ли вы платформу глубже уровня «Java медленная» и понимаете ли, какие ограничения реальны сегодня, а какие остались в прошлом. Следом обычно спрашивают, как вы с ними боролись у себя.

Как отвечать

Называйте проблему вместе с тем, чем её лечат:

• старт и прогрев: код сначала интерпретируется, горячие методы компилируют C1 и затем C2, пиковая скорость приходит не сразу. Для serverless и CLI это больно. Помогают CDS, AOT-кэш из проекта Leyden, CRaC или GraalVM Native Image с его ограничениями на рефлексию;
• память: заголовки объектов, боксинг в List<Integer>, нет value-типов (ими занят проект Valhalla). Кроме кучи есть metaspace, стеки потоков и direct-буферы, поэтому -Xmx не равен реальному потреблению, и контейнер ловит OOMKilled. Нужны -XX:MaxRAMPercentage и запас по памяти;
• паузы GC: по умолчанию G1, для низких задержек ZGC и Shenandoah с паузами меньше миллисекунды, но ценой CPU и памяти;
• стирание типов: в рантайме List<String> и List<Integer> один класс;
• потоки: платформенный поток дорог, это во многом сняли виртуальные потоки в JDK 21;
• нативный код: JNI сложен и опасен, ему на смену пришёл Foreign Function & Memory API.

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

Повторяют мифы десятилетней давности: PermGen, который убрали в Java 8, или апплеты. Это сигнал, что знания не обновлялись.

Говорят про безопасность через Security Manager. Его объявили устаревшим в JDK 17 и отключили в JDK 24, опираться на него нельзя.

Считают, что GC исключает утечки. Статическая коллекция, кэш без вытеснения или незачищенный ThreadLocal в пуле потоков держат объекты живыми, и сборщик их не тронет.