AOT-кэш и Project Leyden

Project Leyden — проект OpenJDK, сокращающий время старта и прогрева Java-приложений за счёт переноса части работы JVM на более ранний этап: «тренировочный» запуск. Итог тренировки сохраняется в AOT-кэш, который переиспользуют все последующие запуски. В отличие от компиляции в нативный бинарь это остаётся тот же HotSpot: полная совместимость с рефлексией, динамической загрузкой классов и агентами, пиковая производительность JIT никуда не девается. Функциональность выходит порциями: JEP 483 (Java 24) кэширует загрузку и линковку классов, JEP 514 (Java 25) сводит создание кэша к одной команде, JEP 515 (Java 25) добавляет в кэш профили методов, а JEP 516 (Java 26) делает формат кэша совместимым с любым сборщиком мусора, включая ZGC.

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

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

java -XX:AOTCacheOutput=app.aot -cp app.jar com.example.Main

# обычный запуск с кэшем
java -XX:AOTCache=app.aot -cp app.jar com.example.Main

Старт ускоряется без единого изменения кода — в демонстрациях JEP типовые приложения стартуют в два-три раза быстрее. Профили методов из JEP 515 дополнительно убирают долгий прогрев: JIT сразу компилирует горячие методы в оптимизированный код, не тратя первые минуты работы на повторный сбор статистики. Если кэш не подходит текущей конфигурации — другая версия JDK, другой classpath — JVM просто игнорирует его и стартует обычным путём, деградации не происходит.

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

• Микросервисы, serverless и любые сценарии, где холодный старт на счету.
• Автоскейлинг и частые рестарты: каждая новая реплика поднимается заметно быстрее.
• Когда GraalVM Native Image слишком дорог по ограничениям (рефлексия, агенты, отладка): Leyden даёт ускорение без смены модели выполнения. После того как Oracle сместила фокус GraalVM и для обычных JVM-приложений продвигает именно Leyden, AOT-кэш — основной путь AOT-оптимизаций внутри самой платформы.

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

• Нерепрезентативная тренировка: если тренировочный запуск не прошёл по боевым код-пасам, в кэше не окажется нужных классов и профилей, и выигрыш будет минимальным.
• Считать кэш переносимым артефактом: он привязан к версии JDK, classpath и платформе — пересобирайте его в CI на каждый релиз.
• До Java 26 — создавать и использовать кэш с разными сборщиками мусора: формат был GC-зависимым, а ZGC не поддерживался вовсе (исправлено в JEP 516).
• Ждать от Leyden эффекта native-image по памяти: AOT-кэш ускоряет старт и прогрев, но не уменьшает потребление памяти работающего приложения.

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

• JIT-компиляция
• Загрузчики классов
• Память JVM
• GraalVM Native Image