在容器化部署Java应用时，镜像体积往往是一个被忽视却影响深远的问题。一个基于标准JDK基础镜像构建的Spring Boot应用，最终镜像动辄超过600MB，而其中真正被运行时使用的代码可能不到整体体积的十分之一。这种臃肿不仅浪费存储资源，还会拖慢镜像拉取、构建推送以及滚动发布的速度。理解JRE精简的原理和方法，是每个追求工程效率的Java开发者都应该掌握的技能。
为什么默认的Java镜像如此臃肿
一个典型的openjdk:17镜像体积通常在470MB左右，而eclipse-temurin:17-jdk更是接近500MB。这些镜像包含了完整的JDK工具链：编译器javac、调试工具jdb、性能监控工具jstat、jmap、jstack，以及完整的JRE运行时环境。但对于生产环境中的容器化应用来说，代码编译已经在CI阶段完成，容器内只需要运行时环境，那些开发工具完全是多余的负担。
进一步拆解JRE本身的构成，标准JRE包含了约70多个模块，而一个典型的Spring Boot应用实际依赖的模块可能不超过15个。像java.desktop（AWT和Swing相关组件）、java.corba、java.scripting等模块在大多数Web应用中根本不会被调用。此外，JRE目录下还附带了man手册页、头文件、调试符号等非运行必需的文件，这些加起来也有数十兆的空间浪费。
镜像臃肿带来的实际影响远比想象中大。过大的镜像不仅消耗镜像仓库的存储空间，还会显著拖慢镜像拉取速度。在Kubernetes集群中做滚动更新时，每个Pod拉取镜像的时间可能从秒级变成分钟级。更小的镜像意味着更快的冷启动、更少的攻击面（减少不必要的工具链意味着更少的潜在安全漏洞），以及更低的存储和带宽成本。在Serverless场景下，镜像体积更是直接决定了冷启动延迟。
使用jlink构建自定义JRE
jlink是JDK 9引入的模块化工具，它可以根据应用实际依赖的模块，将JRE裁剪为只包含必要组件的最小运行时。其核心原理是分析模块依赖图，从$JAVA_HOME/jmods目录中提取所需模块，生成一个自包含的、可定制的JRE镜像。与简单删除文件不同，jlink在模块层面进行裁剪，确保运行时的完整性和模块间的依赖关系不被破坏。
确定应用需要哪些模块是关键步骤。可以使用jdeps工具自动分析jar包的模块依赖关系，它会扫描字节码中的import语句，输出应用依赖的JDK模块列表：
jdeps --module-path libs --print-module-deps --ignore-missing-deps myapp.jar
需要注意的是，反射调用和动态代理可能不会被jdeps检测到，因此对于使用Spring等大量依赖反射的框架，需要手动补充模块。常见的补充模块包括java.management（JMX监控）、java.naming（JNDI支持）、java.net.http（HTTP客户端）等。建议在裁剪后进行充分的集成测试，确保运行时不会因为缺少模块而抛出ClassNotFoundException。
jlink提供了多个裁剪选项进一步压缩体积。--strip-debug移除调试信息，通常可节省20%左右的体积；--no-header-files和--no-man-pages排除头文件和手册页；--compress=2使用最高级别的压缩。组合使用这些参数，一个仅包含基础模块的自定义JRE可以压缩到40至50MB，相比标准JRE的200MB以上大幅缩减。下面是一个完整的jlink命令示例：
jlink \ --no-header-files \ --no-man-pages \ --compress=2 \ --strip-debug \ --module-path "$JAVA_HOME/jmods" \ --add-modules java.base,java.logging,java.sql,java.naming,java.management,java.net.http \ --output /custom-jre
多阶段构建与镜像分层优化
多阶段构建是Docker镜像瘦身的核心策略。其思路是在构建阶段使用完整的JDK环境完成编译和jlink裁剪，然后在运行阶段只将产物复制到一个极小的基础镜像中。这样最终镜像中不会包含Maven缓存、源代码、编译工具等临时文件。构建阶段产生的所有中间层都不会出现在最终镜像中，从而保证最终镜像的精简。下面是一个经过优化的完整Dockerfile示例：
FROM maven:3.8-openjdk-17-slim AS builder WORKDIR /app COPY pom.xml . RUN mvn dependency:go-offline COPY src ./src RUN mvn package -DskipTests FROM eclipse-temurin:17-jdk AS jre-builder RUN jlink \ --no-header-files \ --no-man-pages \ --compress=2 \ --strip-debug \ --module-path "$JAVA_HOME/jmods" \ --add-modules java.base,java.logging,java.sql,java.naming,java.management,java.net.http \ --output /custom-jre FROM debian:bookworm-slim COPY --from=jre-builder /custom-jre /opt/jre COPY --from=builder /app/target/myapp.jar /app/app.jar ENV PATH="/opt/jre/bin:$PATH" ENTRYPOINT ["java","-jar","/app/app.jar"]
基础镜像的选择同样关键。运行阶段不建议使用alpine作为基础镜像，因为glibc和musl libc的差异可能导致Java原生库出现兼容性问题，尤其是在使用JNI或某些底层网络库时。推荐使用debian:bookworm-slim或ubuntu:jammy作为基础，它们体积约80MB且兼容性良好。如果追求极致精简，可以尝试Google的distroless镜像，它甚至不包含shell和包管理器，安全性更高，但调试时需要借助docker exec配合临时容器。
分层策略的优化也不容忽视。将变化频率低的层放在前面，变化频率高的层放在后面，可以最大化利用Docker构建缓存。基础镜像和自定义JRE层几乎不变，应放在最前；应用jar包每次构建都会变化，放在最后。此外，Spring Boot 2.3+提供了分层索引功能，可以将依赖库和应用代码分离为不同层，进一步优化缓存命中率。通过spring-boot-jarmode-layertools工具可以提取分层后的jar结构，配合多阶段构建实现更精细的缓存控制。经过以上优化组合，一个中等规模的Spring Boot应用镜像完全可以控制在100MB以内。