把一个Spring Boot应用放进Docker容器里跑起来，听起来只要写个Dockerfile、打个jar包就完事了。但实际操作中，很多人会发现构建出来的镜像动辄七八百兆，本地构建一次要等好几分钟，部署到线上后又频繁出现内存溢出或者健康检查失败的问题。容器化部署并不是简单地执行一下docker build，它涉及镜像分层设计、JVM在容器中的运行特性、镜像体积优化以及容器编排平台的多方面配合。这篇文章就从Dockerfile的编写讲起，一步步把Spring Boot容器化部署中的关键环节讲透。
一、编写分层优化的Dockerfile
Dockerfile的写法直接决定了镜像的构建速度和体积。先看一个很多初学者会写的版本：
FROM openjdk:17 COPY target/app.jar /app/app.jar ENTRYPOINT ["java", "-jar", "/app/app.jar"]
这个写法虽然能跑通，但存在明显问题。首先是openjdk:17这个基础镜像本身就有六百多兆，包含了大量编译工具和不必要的系统组件。其次是分层策略太粗糙，每次代码改了一行，整个jar包都会重新复制进镜像，Docker的层缓存完全失效，构建时所有层都要重新传输，CI/CD流水线会变得非常慢。
更好的方案是利用Spring Boot自带的分层能力。从Spring Boot 2.3开始，打包出来的可执行jar默认支持分层解压，执行java -Djarmode=layertools -jar app.jar extract命令，jar会按照依赖关系解压成几个目录：dependencies存放第三方依赖，spring-boot-loader是类加载器，snapshot-dependencies存放SNAPSHOT依赖，application才是我们自己的业务代码。基于这个特性，Dockerfile可以这样写：
FROM eclipse-temurin:17-jre-alpine AS builder WORKDIR /app COPY target/app.jar . RUN java -Djarmode=layertools -jar app.jar extract FROM eclipse-temurin:17-jre-alpine WORKDIR /app COPY --from=builder /app/dependencies/ ./ COPY --from=builder /app/spring-boot-loader/ ./ COPY --from=builder /app/snapshot-dependencies/ ./ COPY --from=builder /app/application/ ./ ENTRYPOINT ["java", "org.springframework.boot.loader.launch.JarLauncher"]
这个多阶段构建的核心思路是：变化频率低的依赖放在前面的层，变化频率高的业务代码放在后面的层。只要依赖没变，依赖层就命中缓存，每次构建只需要重新打包业务代码那一层，构建速度能提升数倍。注意上面用的基础镜像是eclipse-temurin:17-jre-alpine，它只包含JRE而不包含JDK，基于Alpine Linux构建，体积比完整的openjdk镜像小了很多，最终镜像往往能控制在两百兆以内。
有一点需要注意，如果你的Spring Boot版本是3.2之前，启动类名是org.springframework.boot.loader.JarLauncher，3.2及之后才移到了org.springframework.boot.loader.launch.JarLauncher包下，写错了容器会直接启动失败，报找不到主类的错误。
二、容器环境下的JVM内存配置
把JVM放进容器里跑，最容易踩的坑就是内存分配。早期的JVM并不感知容器，它看到的内存是宿主机的总内存。假设宿主机有64G内存，容器限制了2G，JVM默认按照宿主机内存的四分之一来设置最大堆，就会申请远超容器限制的内存，最终被内核的OOM Killer杀掉，日志里只能看到进程莫名其妙消失，排查起来非常痛苦。
从JDK 8u191和JDK 10开始，JVM加入了容器感知能力，默认开启UseContainerSupport，能够正确识别容器的内存上限。但仍建议显式配置参数来精确控制：
ENTRYPOINT ["java", \ "-XX:MaxRAMPercentage=70.0", \ "-XX:InitialRAMPercentage=70.0", \ "-Xss512k", \ "-XX:MaxMetaspaceSize=256m", \ "-XX:+UseG1GC", \ "org.springframework.boot.loader.launch.JarLauncher"]
这里用MaxRAMPercentage代替传统的-Xmx，好处是JVM会按照容器实际内存的百分比来动态计算堆大小。配置成70%左右是给堆外内存留出空间，因为一个Java进程的实际内存占用除了堆，还包括元空间、线程栈、直接内存等，如果堆设置为100%，这些堆外内存就会超出容器限额，触发OOM被杀。
另外建议加上-XX:+ExitOnOutOfMemoryError参数。当发生内存溢出时让JVM直接退出，配合容器编排平台的重启策略，应用能自动拉起恢复，比带着异常状态继续半死不活地服务要好得多。
三、Kubernetes部署的关键配置
镜像构建好之后，部署到Kubernetes集群还有几项配置不可忽视。第一个是资源配额，建议requests和limits保持一致，CPU和内存都明确声明：
apiVersion: apps/v1
kind: Deployment
metadata:
name: springboot-app
spec:
replicas: 3
template:
spec:
containers:
- name: app
image: registry.ippipp.com/springboot-app:1.0.0
resources:
requests:
cpu: "500m"
memory: "1Gi"
limits:
cpu: "1000m"
memory: "1Gi"
livenessProbe:
httpGet:
path: /actuator/health/liveness
port: 8080
initialDelaySeconds: 60
periodSeconds: 10
readinessProbe:
httpGet:
path: /actuator/health/readiness
port: 8080
initialDelaySeconds: 30
periodSeconds: 5
lifecycle:
preStop:
exec:
command: ["sleep", "10"]健康检查方面，Spring Boot的Actuator在Kubernetes环境下会自动暴露liveness和readiness两组端点，两者职责完全不同。liveness探测失败会导致容器被重启，readiness探测失败只是把Pod从Service的端点列表中摘除。如果把它们混用同一个端点，一旦出现数据库抖动导致readiness失败，容器会被误杀重启，反而加剧服务不可用。
优雅停机也是容易被忽略的环节。Pod被删除时，Kubernetes会先发送SIGTERM信号，然后等待terminationGracePeriodSeconds（默认30秒）再强制杀掉。Spring Boot 2.3以后配置server.shutdown=graceful即可让应用停止接收新请求并等待存量请求处理完。preStop的sleep 10则是给负载均衡器留出刷新端点缓存的时间，避免流量继续打到即将关闭的Pod上。
最后别忘了在配置文件中激活容器感知的profile，Spring Boot默认通过spring.config.activate.on-profile结合环境变量就能实现多环境切换，在Deployment中通过环境变量注入SPRING_PROFILES_ACTIVE=prod即可，让同一个镜像可以在不同环境间复用，这也是容器化倡导的一次构建到处运行理念的落地。
Spring Boot 容器化DockerfileKubernetes部署修改时间：2026-09-09 15:47:20