GraalVM与Native Image详解：原理、Spring Boot样例与编译/运行镜像选型

前言

Java 应用启动慢、吃内存、还要预热，放在 Serverless 和弹性伸缩的场景里很难受。GraalVM 的 Native Image 用 AOT 编译解决了这个问题：毫秒启动、内存省一半、连 JVM 都不要了。代价是反射要登记、构建要等几分钟、生态要适配。这篇把原理讲清、把 Spring Boot 3 的样例跑通，重点记录一下我在容器化时踩坑最多的部分：编译镜像和运行镜像怎么选。

1、GraalVM 是什么

GraalVM 是 Oracle 开源的高性能 JDK 发行版，两块东西：

1. Graal JIT 编译器：用 Java 写的 JIT，普通 JVM 模式下就能用，零改造白拿性能提升
2. Native Image：把 Java 应用 AOT（提前）编译成本地可执行文件，这篇的主角

2、原理：封闭世界假设

AOT 编译的时候没有运行时信息，GraalVM 从 main 入口做静态可达性分析，分析到的代码才编译进二进制，这就是封闭世界假设（Closed World）。带来的限制和对策：

好消息是主流框架（Spring Boot 3、Quarkus、Micronaut、Hibernate 6）都做了 AOT 适配，构建期自动生成这些元数据，业务代码基本不用手动写 json。

3、样例一：纯 Java CLI

1
2
3
4
5

public class HelloNative {
    public static void main(String[] args) {
        System.out.println("Hello from native! args=" + String.join(",", args));
    }
}

1
2
3
4

javac HelloNative.java
native-image -Ob HelloNative hello      # -Ob 快速构建（开发期）
./hello                                 # 没有 JVM，直接跑
file hello                              # ELF 64-bit LSB executable

有反射的时候登记元数据：

1

native-image -H:ReflectionConfigurationFiles=reflect-config.json HelloNative hello

1
2
3
4

[
  { "name": "com.example.Bean", "allDeclaredConstructors": true,
    "allPublicMethods": true }
]

4、样例二：Spring Boot 3 原生编译

Spring Boot 3 起官方支持 AOT，框架在构建期自动生成反射配置和代码，业务代码不用动：

1
2
3
4
5
6

# 前置：本机要 GraalVM JDK 21 + C 编译链（gcc/xcode）
sdk install java 21.0.5-graalce      # GraalVM Community

mvn -Pnative native:compile          # Maven（Gradle 是 gradle nativeCompile）
# 构建要 2~5 分钟，第一次更久，产出 target/demo-web
./target/demo-web                    # 启动 0.1~0.3 秒，内存 80MB 左右

pom 里加插件：

1
2
3
4

<plugin>
    <groupId>org.graalvm.buildtools</groupId>
    <artifactId>native-maven-plugin</artifactId>
</plugin>

同一个简单 Web 服务我实测的对比：jar 模式启动 2.1s、内存 380MB；native 启动 0.2s、内存 85MB。弹性伸缩和 Serverless 场景下这个差距就是钱。

5、编译镜像和运行镜像的选型

容器里做 native 编译有个矛盾：构建环境要 GraalVM 加 C 工具链（2~4GB），运行却只要一个几 MB 的可执行文件。所以必然是多阶段构建，两段分开选。

5.1 编译镜像（builder）怎么选

两点提醒：新版 GraalVM 的 native-image 已经默认内置（老版本要 gu install native-image）；编译很吃内存，CI 的 build 容器给到 6~8G，不然 OOMKilled。

5.2 运行镜像怎么选：glibc 和 musl 是分水岭

native 二进制不是扔哪个 Linux 都能跑：glibc 环境编译的放 alpine（musl）必挂。两条路线：

5.3 完整 Dockerfile（glibc 路线，可直接用）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# ---------- 编译阶段 ----------
FROM ghcr.io/graalvm/native-image-community:21 AS builder
WORKDIR /build
COPY .mvn/ mvnw pom.xml ./
RUN ./mvnw dependency:go-offline          # 先拉依赖，吃层缓存
COPY src ./src
RUN ./mvnw -Pnative native:compile \
    -DskipTests && \
    mv target/demo-web /build/app

# ---------- 运行阶段 ----------
FROM gcr.io/distroless/base-debian12
COPY --from=builder /build/app /app
EXPOSE 8080
ENTRYPOINT ["/app"]

同一个 Spring Boot Web 应用的体积实测：

5.4 我的建议

• 默认走 glibc + distroless，兼容性最好，Spring Boot 零额外配置
• 追极致体积或者边缘部署再上 musl 静态，留出调试兼容性的时间
• 编译层把「依赖下载」和「源码编译」拆成两层 COPY+RUN，CI 缓存能省很多时间
• 不想写 Dockerfile 的 Spring 团队直接 pack build app --builder paketobuildpacks/builder-jammy-buildpacks

6、什么场景该用

折中方案还有 CRaC：JVM 模式下做快照恢复，也能秒启、保留 JIT 的峰值性能，适合不想做 AOT 改造的长驻服务。两条路线可以并存，按服务挑。

总结

Native Image 用「封闭世界」换来毫秒启动和一半内存，Spring Boot 3 之后业务代码基本零改造，要花心思的是镜像：编译用 graalvm/native-image-community（或者 buildpacks），运行默认 glibc + distroless，追体积再上 musl 静态。冷启动敏感就 AOT，峰值性能敏感就留在 JVM 上配 CRaC，按服务来定。

相关阅读

• OpenJDK厂商选型（Liberica 发行版）
• JDK 8到21迁移指南
• Kubernetes学习路径与实用工具箱（容器运行环境）
• docker镜像清单与梳理（graalvm 镜像）