Библиотека девопса | DevOps, SRE, Sysadmin: “☁️ Пора переходить на GraalVM Native Image Spring Boot на JVM стартует…”

☁️ Пора переходить на GraalVM Native Image

Spring Boot на JVM стартует 15–20 секунд и съедает ~300 МБ памяти в простое. В Kubernetes это означает полминуты бесполезного ожидания при каждом скейлинге, убитые liveness-пробы и initialDelaySeconds: 25 на каждом сервисе. А serverless с таким холодным стартом вообще не вариант.

GraalVM Native Image компилирует Java-приложение в нативный бинарник ещё на этапе сборки. Никакого JVM внутри, никакой интерпретации байткода. На выходе получаем старт за 60–90 мс и 55 МБ памяти в idle вместо 280.

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

GraalVM делает AOT-компиляцию (Ahead-of-Time). Статический анализатор проходит по всему коду и собирает в бинарник только то, что реально используется. Это называется closed-world assumption: всё, что не видно анализатору на этапе сборки, в бинарник не попадает. Мёртвый код, неиспользуемые библиотеки, весь JIT-компилятор — всё отсекается.

Отсюда же и главная проблема. Java активно использует рефлексию, динамическую загрузку классов и runtime-генерацию прокси. Статический анализатор этого не видит. Код соберётся, а в рантайме упадёт с ClassNotFoundException.

Spring Boot 3.x решает это через собственный AOT-движок: он заранее обрабатывает метаданные, подменяет динамические вызовы статическими и генерирует код регистрации бинов до компиляции.

Как собрать

В pom.xml добавляем плагин:

<build>
    <plugins>
        <plugin>
            <groupId>org.graalvm.buildtools</groupId>
            <artifactId>native-maven-plugin</artifactId>
        </plugin>
        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
        </plugin>
    </plugins>
</build>

Собираем нативный образ:

mvn -Pnative native:compile

Или через Docker (удобнее для CI/CD, не нужен локальный GraalVM):

mvn -Pnative spring-boot:build-image

Сборка занимает 3–8 минут даже для небольших сервисов. Это нормально — статический анализ и AOT-компиляция делают много работы. В пайплайне это отдельный шаг, не для быстрого фидбека.

Когда это нужно

JVM не устарела. Для сервисов с постоянной нагрузкой, где важен максимальный throughput после прогрева, обычный JVM с JIT по-прежнему лучший выбор.

GraalVM Native Image — для другого сценария: serverless-функции, сервисы, которые скейлятся до нуля ночью, event-driven обработчики с пиковой нагрузкой и долгими паузами, batch-задачи, которые запускаются раз в сутки.

➡️ Больше Java тут

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера