多阶段构建是Java应用Docker镜像瘦身的核心，通过分离编译与运行环境，仅将编译后的JAR包复制至最小化JRE基础镜像，避免包含JDK、构建工具等冗余文件，结合slim镜像和.dockerignore优化，可显著减少镜像体积。
Docker和Java的组合，在镜像大小这事儿上，确实是个老大难问题。想要把镜像体积一下子缩减70%，听起来像是在吹牛，但以我的经验来看，这完全是可行的。核心秘诀在于“精打细算”和“分而治之”——也就是我们常说的多阶段构建，再加上一些细节上的优化，就能让你的Java应用镜像成功“瘦身”。这其中没有太多黑魔法，更多的是工程实践中的一点点“心机”和耐心。
要让Java应用的Docker镜像大幅瘦身，我的经验是，多阶段构建（Multi-Stage Builds）绝对是基石，没有之一。传统的做法，你可能把所有编译环境、运行时环境一股脑儿塞进一个镜像，结果自然是臃肿不堪。而多阶段构建，就是把构建过程和运行过程彻底分离开来。
具体来说，它就像是工厂里的两条流水线：一条专门负责生产产品（编译Java代码，打包成JAR/WAR），另一条则负责把产品装箱发货（运行你的应用）。
构建阶段： 在这个阶段，我们会使用一个包含完整JDK和构建工具（比如Maven或Gradle）的镜像。这个镜像可以很大，没关系，因为它只是个“临时工”。我们在这里完成所有的编译、测试、打包工作，最终得到一个干净的、可执行的JAR或WAR文件。
运行时阶段： 这是真正用于部署的镜像。我们会选择一个尽可能小的基础镜像，通常只包含JRE（Java Runtime Environment），甚至可以是更精简的
jre-slim版本，或者像
distroless这样几乎不带任何额外Linux工具的镜像。然后，我们只把上一个阶段生成的JAR/WAR文件复制过来。这样，运行时镜像里就只包含了运行应用所需的最少组件。
举个例子，一个简单的Spring Boot应用，我们可能会这样写Dockerfile：
立即学习“Java免费学习笔记（深入）”；
# 第一阶段：构建应用 FROM maven:3.8.5-openjdk-17 AS builder WORKDIR /app COPY pom.xml . # 这一步是为了利用Docker的层缓存，如果pom.xml不变，依赖就不需要重新下载 RUN mvn dependency:go-offline -B COPY src ./src RUN mvn package -DskipTests # 第二阶段：运行应用 FROM openjdk:17-jre-slim AS runner WORKDIR /app # 只复制构建好的JAR文件 COPY --from=builder /app/target/*.jar app.jar ENTRYPOINT ["java", "-jar", "app.jar"]
你看，通过这种方式，构建阶段的Maven、JDK、源码、临时文件等统统都不会出现在最终的运行时镜像里。这一下子就能省下好几百兆的空间。
为什么我的Java Docker镜像总是比别人家的胖一圈？
说实话，这几乎是所有刚接触Docker化Java应用开发者都会遇到的问题。我个人觉得，主要原因有几个。首先，Java生态本身就比较“重”。一个完整的JDK环境，随随便便就是几百兆。如果你直接用
openjdk:latest或者
openjdk:17-jdk这样的基础镜像，那它里面包含了开发工具、文档、示例代码等等，这些东西在生产环境运行时是完全不需要的。
其次，构建工具的“贡献”也不小。Maven或者Gradle在构建过程中会下载大量的依赖包，生成各种中间文件。如果这些东西没有在构建完成后被清理掉，或者没有采用多阶段构建来隔离，它们就会无情地堆积在你的最终镜像里。
还有就是，很多时候我们打包的JAR/WAR文件本身就包含了项目所有的依赖，也就是所谓的“胖JAR”。这本身没问题，但如果再叠加上一个“胖”基础镜像，那整个镜像自然就成了“巨无霸”。我见过最夸张的，一个简单的微服务镜像能跑到1GB以上，这在部署和传输上都是巨大的负担。
最后，一些不经意的操作，比如在Dockerfile里复制了整个项目目录（包括
.git、
target、
node_modules等），或者没有有效利用
.dockerignore文件，都会让镜像无形中增肥。这些都是经验之谈，踩过坑才知道。
如何巧妙运用多阶段构建，让Java应用镜像“瘦身”成功？
多阶段构建的核心思想，我前面简单提了一下，但要真正用好，里面还是有些门道的。它不仅仅是简单地把
FROM写两次，更重要的是理解每个阶段的职责，以及如何高效地在阶段间传递成果。
最常见的实践模式是：
-
构建（Build）阶段：
- 选用一个包含完整JDK和构建工具（如Maven、Gradle）的基础镜像。
maven:3.8.5-openjdk-17
或者gradle:7.5-jdk17
都是不错的选择。 - 将
pom.xml
或build.gradle
文件单独复制到镜像中，并提前执行依赖下载命令（如mvn dependency:go-offline
或gradle dependencies
）。这一步非常关键，它能充分利用Docker的层缓存。只要你的依赖没有变化，这一层就不会重新构建，大大加快了后续构建速度。 - 复制源代码，然后执行实际的编译和打包命令（如
mvn package -DskipTests
）。 - 确保构建过程中产生的临时文件、测试报告等不会被带到下一阶段。
- 选用一个包含完整JDK和构建工具（如Maven、Gradle）的基础镜像。
-
运行时（Runtime）阶段：
- 选择一个最小化的JRE基础镜像。
openjdk:17-jre-slim
是我的首选，它只包含了运行Java应用所需的最基本组件。如果你对极致的体积和安全性有追求，可以考虑gcr.io/distroless/java17-debian11
这类无操作系统的基础镜像，但调试起来会稍微麻烦点，这是个取舍。 - 设置工作目录。
- 最重要的一步：使用
COPY --from=builder /path/to/your/app.jar .
命令，精确地从构建阶段复制你需要的最终产物（通常是那个“胖JAR”或“瘦JAR”）。注意，这里只复制JAR/WAR，其他任何东西都不要带过来。 - 配置
ENTRYPOINT
或CMD
来启动你的Java应用。
- 选择一个最小化的JRE基础镜像。
一个更具体的例子，假设你的Spring Boot应用叫
my-app.jar：
# 构建阶段 FROM eclipse-temurin:17-jdk-focal AS builder # 用一个轻量级JDK构建镜像 WORKDIR /app # 复制Maven项目文件，利用缓存 COPY pom.xml . RUN mvn dependency:go-offline -B # 预下载依赖 # 复制源代码并构建 COPY src ./src RUN mvn package -DskipTests # 运行时阶段 FROM eclipse-temurin:17-jre-focal # 选用一个轻量级JRE运行时镜像 WORKDIR /app # 从构建阶段复制最终的jar包 COPY --from=builder /app/target/my-app.jar . # 暴露应用端口 EXPOSE 8080 # 启动应用 ENTRYPOINT ["java", "-jar", "my-app.jar"]
通过这种方式，我们能确保最终的运行时镜像只包含JRE和你的应用JAR包，其他一切“垃圾”都被挡在了门外。我个人觉得，这是最直接也最有效的瘦身方法。
除了多阶段构建，还有哪些“黑科技”能让Java Docker镜像更轻巧？
多阶段构建是基础，但如果你想追求极致的瘦身效果，或者遇到一些特殊场景，还有一些进
