GraalVM Native Image

GraalVM Native Image компилирует Java-приложение вместе с зависимостями и нужными частями рантайма в самостоятельный нативный исполняемый файл ещё на этапе сборки (ahead-of-time). Результат стартует за миллисекунды и потребляет заметно меньше памяти, чем JVM: не надо загружать классы, интерпретировать байткод и прогревать JIT. Цена — модель «закрытого мира»: компилятор должен видеть весь достижимый код во время сборки, поэтому динамические механизмы Java — рефлексия, прокси, JNI, загрузка ресурсов — требуют явного описания.

Как это работает

Статический анализ строит граф достижимости от точек входа; всё, что в граф не попало, в бинарь не включается. Динамические обращения описываются через reachability metadata — JSON-конфиги, которые можно собрать автоматически трейсинг-агентом (-agentlib:native-image-agent), прогнав тесты или само приложение в обычном JVM-режиме. Spring Boot (начиная с 3-й версии, через AOT-processing), Quarkus и Micronaut генерируют большую часть метаданных за вас.

native-image -jar app.jar     # долгая и требовательная к памяти сборка
./app                         # старт за миллисекунды

Компромиссы: сборка занимает минуты и ест гигабайты; пиковая пропускная способность обычно ниже, чем у прогретого JIT, который оптимизирует по живому профилю; отладка и часть инструментов работают иначе; бинарь платформозависим — под каждую ОС и архитектуру собирается свой. Контекст 2025–2026: Oracle объявила об «отцеплении» GraalVM от релизного поезда Java — последним синхронным выпуском стал GraalVM for JDK 24, а для обычных JVM-приложений Oracle теперь продвигает AOT-кэш Project Leyden. Native Image продолжает развиваться как community-проект (плюс Mandrel от Red Hat для Quarkus) и остаётся стандартом там, где критичен минимальный footprint.

Когда применять

• CLI-утилиты, где секунда на подъём JVM неприемлема.
• Serverless и FaaS: холодный старт за миллисекунды, оплата за память — по минимуму.
• Контейнеры с жёстким лимитом памяти, sidecar-процессы, edge-окружения.
• Долгоживущим сервисам с упором на пиковую пропускную способность чаще выгоднее обычный JIT либо AOT-кэш Leyden — сравнивайте под свою нагрузку.

Типичные ошибки

• Рефлексия без метаданных падает только в рантайме: тестируйте именно нативный бинарь, а не только JVM-версию приложения.
• Забыть описать ресурсы, прокси и сериализацию в reachability metadata — классические «работает на JVM, падает в нативе».
• Инициализация классов на этапе сборки «замораживает» состояние: время, случайные seed или переменные окружения сборочной машины могут навсегда попасть в бинарь.
• Считать, что «нативный» значит «всегда быстрее»: выигрыш — в старте и памяти, а не в пиковом throughput.
• Не заложить время нативной сборки в CI: она на порядок дольше обычного jar-билда и требует мощного раннера.

Связанные понятия

• AOT-кэш и Project Leyden
• JIT-компиляция
• Сборка мусора
• Профилирование