Компромиссы нативного образа

Нативный образ даёт большие возможности, но не бесплатно. Он жертвует адаптивностью JVM во время выполнения ради быстрого запуска и низкого потребления памяти. Понимание этих компромиссов поможет Вам решить, когда переход на нативный образ оправдан.

Главное преимущество. Нативный двоичный файл пропускает загрузку классов, проверку байткода и прогрев динамической компиляции. Он может запускаться за несколько миллисекунд вместо сотен при запуске JVM — это особенно важно для интерфейсов командной строки и бессерверных функций.

Отсутствие JIT-компилятора и структур профилирования, а также заранее вычисленная куча образа означают, что нативный процесс использует гораздо меньше RAM. Это позволяет размещать больше экземпляров в каждом контейнере и значительно уменьшать масштаб.

Ключевой компромисс. JIT оптимизирует код с использованием актуальных профилей среды выполнения, поэтому длительно работающая JVM может достичь более высокой пиковой пропускной способности, чем AOT-бинарный файл, оптимизированный вслепую во время сборки. Для длительных интенсивных нагрузок JVM всё ещё может оказаться лучше.

GraalVM сокращает разрыв в пропускной способности с помощью PGO: создайте инструментированный образ, выполните характерную для приложения нагрузку, чтобы собрать профили, а затем пересоберите образ с их использованием. AOT-бинарный файл после этого будет похож на разогретый JIT-компилятор для такой нагрузки.

Сборка нативного образа выполняется медленно и требует много памяти — для больших приложений она занимает минуты CPU и гигабайты RAM. Это увеличивает длительность конвейеров по сравнению с быстрой сборкой jar.

Рефлексия, прокси и ресурсы требуют метаданных, как описывалось ранее. Код, который активно использует загрузку классов во время выполнения или генерацию байткода, может быть трудно или невозможно полностью преобразовать в нативный без внесения изменений.

Некоторые инструменты JVM работают в нативном режиме иначе. Стандартные агенты JVMTI и некоторые профилировщики не подключаются тем же способом; вместо этого используются специализированные средства мониторинга или выборки для нативного образа. Планируйте стратегию наблюдаемости соответствующим образом.

Нативный образ поставляется со своими сборщиками мусора: простым последовательным сборщиком и G1 в некоторых редакциях. Для очень больших куч полный набор сборщиков мусора JVM может обеспечивать меньшие задержки. Выбирайте сборщик мусора с учётом размера кучи и допустимой длительности пауз для вашей нагрузки.

• Бессерверные функции, масштабируемые до нуля.
• Инструменты CLI, где время запуска имеет решающее значение.
• Микросервисы в плотно размещаемых контейнерах.
• Краткоживущие пакетные задания.

• Длительно работающие службы, критичные к пропускной способности, где важна пиковая производительность JIT.
• Приложения с активной динамической загрузкой классов или генерацией байткода.
• Нагрузки, зависящие от инструментов на основе JVMTI.

Проверьте, насколько Вы понимаете компромиссы нативного образа.

Вы рассмотрели компромиссы нативного образа:

• Преимущества: запуск за миллисекунды и небольшой объём используемой памяти.
• Издержки: потенциально меньшая пиковая пропускная способность, медленная сборка, метаданные для динамических возможностей и отличия в инструментах.
• PGO сокращает разрыв в пропускной способности благодаря пересборке на основе профилей.
• Нативный образ подходит для CLI, бессерверных приложений и плотно размещаемых микросервисов.
• JVM подходит для длительно работающих приложений, критичных к пропускной способности и активно использующих динамические возможности.