Docker+Java最佳实践：镜像大小减少70%的构建优化方法-java教程-PHP中文网

Docker+Java最佳实践：镜像大小减少70%的构建优化方法

紅蓮之龍

发布： 2025-09-04 18:51:01

原创

487人浏览过

多阶段构建是Java应用Docker镜像瘦身的核心，通过分离编译与运行环境，仅将编译后的JAR包复制至最小化JRE基础镜像，避免包含JDK、构建工具等冗余文件，结合slim镜像和.dockerignore优化，可显著减少镜像体积。

docker+java最佳实践：镜像大小减少70%的构建优化方法

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以上，这在部署和传输上都是巨大的负担。

ViiTor实时翻译

AI实时多语言翻译专家！强大的语音识别、AR翻译功能。

116

查看详情

最后，一些不经意的操作，比如在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
```
  登录后复制
  ）。
- 确保构建过程中产生的临时文件、测试报告等不会被带到下一阶段。
运行时（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应用。

一个更具体的例子，假设你的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包，其他一切“垃圾”都被挡在了门外。我个人觉得，这是最直接也最有效的瘦身方法。