Spring Boot 容器化部署：生命周期、镜像选型与健康检查实战

1. 这不是“打包运行”，而是重新理解 Spring Boot 的生命周期

很多人第一次接触“用 Docker 部署 Spring Boot”时，下意识把它当成一个“打包后扔进容器跑起来”的自动化收尾动作——就像把做好的盒饭装进保温箱，关上盖子就完事。但实际踩过坑、带过团队、维护过线上服务的开发者都清楚：Docker 不是运输工具，而是 Spring Boot 应用在生产环境中的新操作系统层。它彻底重构了应用的启动逻辑、资源边界、依赖加载路径、日志归集方式，甚至改变了你对“健康检查”“优雅关闭”“配置注入”的底层认知。

我带过的某高校实验室模拟项目X，最初用 Maven 打成 fat-jar 直接在 Ubuntu 服务器上java -jar启动，一切正常；但一模一样地塞进 Docker 容器后，连续三天凌晨 3:17 出现偶发性 500 错误，日志里只有一行Application run failed，没有任何堆栈。排查两周才发现，问题不在代码，而在容器启动时 JVM 参数未适配 cgroup 内存限制——Spring Boot 2.3+ 默认启用的UseContainerSupport虽然能自动识别容器内存上限，但若基础镜像未显式声明JAVA_HOME或JVM_OPTS中混入了-Xmx4g这类硬编码值，就会触发 JVM 在容器内申请超出 cgroup 允许范围的内存，直接被 Linux OOM Killer 杀掉。而这个错误不会写进 Spring Boot 的启动日志，只会留在dmesg里。

这就是为什么本课必须从“容器视角重读 Spring Boot 启动流程”开始。它不是教你怎么写Dockerfile，而是帮你建立一套新的判断坐标系：当应用在容器里表现异常时，你要问的不是“我的 Controller 写错了吗”，而是“容器是否给了它正确的内存视图？文件系统挂载是否阻断了spring.config.location的扫描？健康探针是否在应用真正 ready 前就发起了 HTTP 请求？”

关键词“Docker”“Spring Boot”“部署”背后，真正要解决的是运行时语义鸿沟——开发阶段的“本地 Java 进程”和生产阶段的“受限容器进程”，本质上是两种不同的计算实体。本课所有操作，都是为了填平这道鸿沟。适合正在从单机部署转向容器化交付的后端开发者、DevOps 初学者，以及那些已经会写docker run却总在 CI/CD 流水线里卡在健康检查失败环节的工程师。

2. 为什么不能直接FROM openjdk:17-jre-slim？基础镜像选型的三重陷阱

很多教程一上来就甩出FROM openjdk:17-jre-slim，然后COPY target/*.jar app.jar，看起来干净利落。但我在某公司参与的跨平台系统迁移中，正是这个看似无害的基础镜像选择，导致上线后 CPU 使用率长期维持在 98%，监控图表像心电图一样剧烈抖动。最终定位到根源：openjdk:17-jre-slim是基于 Debian 的镜像，其默认的glibc版本与 Spring Boot 3.x 内嵌 Tomcat 的 NIO 线程模型存在隐式兼容问题——在高并发短连接场景下，epoll_wait系统调用返回异常事件数，引发线程池持续创建新线程却无法释放，形成资源泄漏。

这不是个例。基础镜像选型藏着三个常被忽略的致命陷阱，必须逐层拆解：

2.1 陷阱一：JRE vs JDK 的“瘦身幻觉”

-jre-slim镜像去掉了javac、javadoc等开发工具，体积小了 40%，但代价是缺失jstack、jmap、jstat等关键诊断工具。当容器内应用出现线程死锁或内存溢出时，你无法进入容器执行jstack -l <pid>查看线程栈，只能靠外部 APM 工具抓取快照——而 APM 往往在问题发生后才被触发，错过黄金排查窗口。

提示：生产环境务必使用*-jdk-slim镜像（如eclipse-temurin:17-jdk-jammy），它保留全部 JVM 工具且体积仅比 JRE 版大 12MB，换来的是故障时 10 分钟内定位问题的能力。

2.2 陷阱二：Linux 发行版内核特性差异

不同基础镜像基于不同发行版：

• openjdk:*-slim→ Debian（稳定但内核较旧）
• eclipse-temurin:*-jre-jammy→ Ubuntu 22.04（较新内核，支持io_uring）
• amazoncorretto:*-alpine-jdk→ Alpine（musl libc，极小体积但存在 JNI 兼容风险）

Spring Boot 3.x 默认启用io_uring异步 I/O（需 Linux kernel ≥ 5.12），若你用openjdk:17-jre-slim（基于 Debian 11，kernel 5.10），该特性将静默降级为传统 epoll，性能损失可达 35%。而eclipse-temurin:17-jdk-jammy基于 Ubuntu 22.04（kernel 5.15），原生支持。

验证方法很简单，在容器内执行：

# 进入容器 docker exec -it my-springboot-app sh # 检查内核版本 uname -r # 检查 io_uring 是否可用 ls /sys/kernel/io_uring

2.3 陷阱三：Alpine 镜像的 musl libc 兼容雷区

Alpine 因体积小（< 6MB）广受欢迎，但其采用musl libc替代通用的glibc。Spring Boot 内嵌 Tomcat 的 APR（Apache Portable Runtime）连接器依赖glibc的getaddrinfo_a异步 DNS 解析函数。一旦启用 APR（server.tomcat.additional-tld-skip-patterns=*.jar之外的配置），Alpine 镜像会抛出UnsatisfiedLinkError，且错误堆栈指向libtcnative-1.so，极易误判为 Tomcat 配置问题。

实测对比数据（QPS @ 1000 并发）：

注意：若坚持用 Alpine，必须禁用 APR 并显式配置server.tomcat.protocol=org.apache.coyote.http11.Http11NioProtocol，同时在application.yml中添加：

spring: main: web-application-type: servlet server: tomcat: additional-tld-skip-patterns: "*.jar"

选型结论很明确：生产环境首选eclipse-temurin:17-jdk-jammy。它平衡了内核新特性、工具完整性、社区活跃度与安全更新频率。jammy后缀代表 Ubuntu 22.04 LTS，官方承诺支持至 2032 年，比 Debian 11 的 2026 年支持周期更长，对需要长期维护的系统至关重要。

3.Dockerfile不是脚本，而是应用的“容器宪法”

写Dockerfile最常见的误区，是把它当成 Bash 脚本——逐行执行命令，追求“能跑就行”。但 Docker 构建过程本质是分层状态快照，每一层都是不可变的只读文件系统。RUN apt-get update && apt-get install -y curl这样的命令，会在镜像中留下apt缓存、临时文件、未清理的包列表，导致镜像体积膨胀、安全漏洞堆积、构建缓存失效。某次我们为某图像处理 Demo 构建镜像，因未清理apt缓存，单层体积达 187MB，整个镜像超 500MB，CI 流水线拉取耗时 4 分钟，远超 30 秒阈值。

真正的Dockerfile编写，应遵循“容器宪法”原则：每一条指令，都在定义应用运行所必需的、最小化的、可验证的契约。下面以 Spring Boot 项目为例，逐行解析工业级Dockerfile的设计逻辑：

# 第一层：声明基础镜像（宪法第一条：运行环境基准） FROM eclipse-temurin:17-jdk-jammy # 第二层：创建非 root 用户（宪法第二条：权限最小化） # 避免应用以 root 身份运行，防止容器逃逸后获得宿主机 root 权限 RUN addgroup -g 1001 -f spring && adduser -S spring -u 1001 # 第三层：设置工作目录与权限（宪法第三条：文件系统主权） WORKDIR /app COPY --chown=spring:spring . . USER spring # 第四层：JVM 参数固化（宪法第四条：运行时契约） # 显式声明容器内存限制，避免 JVM 自动探测失准 ENV JAVA_OPTS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=75.0 -XX:InitialRAMPercentage=50.0 -XX:+PrintGCDetails -Xlog:gc*:file=/app/logs/gc.log:time" # 第五层：暴露端口（宪法第五条：网络接口定义） EXPOSE 8080 # 第六层：健康检查（宪法第六条：存活与就绪标准） HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8080/actuator/health/readiness || exit 1 # 第七层：启动命令（宪法第七条：唯一合法入口） ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app/app.jar"]

3.1 为什么--chown=spring:spring必须写在COPY指令中？

Docker 构建时，COPY默认以 root 用户身份复制文件。若先COPY再RUN chown，会额外生成一层包含 root 权限文件的镜像层，增大体积且违反最小权限原则。--chown参数让文件在复制瞬间即归属非 root 用户，不产生冗余层。

3.2JAVA_OPTS中-XX:MaxRAMPercentage=75.0的数学依据

假设容器启动时设置--memory=1g，则 cgroup 内存上限为 1024MB。JVM 默认MaxRAMPercentage=25.0，即最多使用 256MB 堆内存，对 Spring Boot 应用明显不足。设为75.0后，最大堆为1024 * 0.75 = 768MB，留出 256MB 给元空间、直接内存、线程栈等非堆区域，符合 JVM 内存分配黄金比例（堆:非堆 ≈ 3:1）。

计算验证（容器内执行）：

# 查看 cgroup 内存限制 cat /sys/fs/cgroup/memory.max # 查看 JVM 实际堆上限 java -XX:+PrintFlagsFinal -version | grep MaxHeapSize

3.3HEALTHCHECK的start-period=5s为何不能省略？

Spring Boot 应用启动包含多个阶段：类加载 → Bean 初始化 → Web 容器启动 → Actuator 端点注册。/actuator/health/readiness端点在WebServerInitializedEvent发布后才可用。实测某项目平均启动耗时 4.2s，若start-period设为 0，健康检查会在应用完全就绪前发起，导致容器被标记为 unhealthy 并重启，陷入“启动-检查失败-重启”死循环。

经验：start-period值 = 应用平均启动耗时 × 1.5。可通过本地time java -jar app.jar多次测试取均值。

3.4ENTRYPOINT中-Djava.security.egd=file:/dev/./urandom的真实作用

Java 8u292+ 默认使用/dev/random作为熵源，但在容器内/dev/random可能因熵池不足而阻塞。/dev/./urandom是同一设备的别名，但 JVM 会绕过其阻塞检测，强制使用非阻塞模式。这是 Spring Boot 官方文档明确推荐的参数，而非民间流传的“黑科技”。

4. 配置外置化：为什么application.yml不该进镜像？

把application.yml直接COPY进镜像，是初学者最典型的反模式。它导致三个不可接受的后果：

• 镜像不可复用：同一镜像无法用于 dev/test/prod 环境，每次换环境都要重建镜像；
• 配置变更需重新构建：修改数据库密码，就得走完整 CI 流水线，发布周期从秒级拉长到分钟级；
• 敏感信息硬编码：密码、密钥明文写在 YAML 里，镜像一旦泄露，等于凭据全丢。

某导师指导的模拟项目X 就曾因此被通报：测试环境镜像被误推送到公共仓库，其中application-dev.yml包含 MySQL root 密码，虽未造成实际损失，但触发了安全审计红线。

正确做法是配置与镜像分离，通过 Docker 的三种机制实现外置化：

4.1 方式一：环境变量注入（推荐用于简单配置）

Spring Boot 原生支持环境变量覆盖application.yml。例如：

# application.yml spring: datasource: url: ${SPRING_DATASOURCE_URL:jdbc:h2:mem:testdb} username: ${SPRING_DATASOURCE_USERNAME:sa}

启动容器时传入：

docker run -d \ --name myapp \ -e SPRING_DATASOURCE_URL="jdbc:mysql://mysql:3306/mydb" \ -e SPRING_DATASOURCE_USERNAME="prod_user" \ -e SPRING_DATASOURCE_PASSWORD="p@ssw0rd" \ -p 8080:8080 \ my-springboot-app

优势：无需修改代码，零配置成本；劣势：复杂嵌套结构（如 List、Map）难以表达。

4.2 方式二：挂载外部配置文件（推荐用于复杂配置）

将配置文件放在宿主机目录，通过-v挂载进容器：

# 宿主机创建配置目录 mkdir -p /opt/myapp/config cp application-prod.yml /opt/myapp/config/ # 启动时挂载 docker run -d \ --name myapp \ -v /opt/myapp/config/application-prod.yml:/app/config/application.yml \ -e SPRING_CONFIG_LOCATION="file:/app/config/" \ -p 8080:8080 \ my-springboot-app

关键点在于SPRING_CONFIG_LOCATION环境变量，它告诉 Spring Boot 从指定路径加载配置，优先级高于 classpath 下的application.yml。

注意：挂载文件时，容器内路径/app/config/必须存在，且application.yml文件权限需为644，否则 Spring Boot 加载失败会静默跳过。

4.3 方式三：Config Server 集成（推荐用于多服务统一管理）

对于微服务架构，应引入 Spring Cloud Config Server。它作为中心化配置中心，所有服务启动时向其拉取配置。Docker 部署时，只需在application.yml中声明：

spring: cloud: config: uri: http://config-server:8888 fail-fast: true

然后通过 Docker Network 将应用容器与 Config Server 容器置于同一网络：

# 创建自定义网络 docker network create myapp-net # 启动 Config Server docker run -d \ --name config-server \ --network myapp-net \ -p 8888:8888 \ config-server-image # 启动应用（自动发现 config-server） docker run -d \ --name myapp \ --network myapp-net \ -p 8080:8080 \ my-springboot-app

此时配置变更只需更新 Config Server 的 Git 仓库，所有服务通过/actuator/refresh端点动态刷新，无需重启。

三种方式对比表：

5. 健康检查失效的七种真实原因与排查链路

健康检查（Health Check）是容器编排系统的“心跳传感器”，但 Spring Boot 应用的健康检查失败，90% 的情况并非应用本身崩溃，而是探针与应用生命周期的时序错配。我在某公司运维的某跨平台系统中，曾连续一周收到 Kubernetes 的Liveness probe failed告警，但应用日志一切正常。最终发现是探针路径/actuator/health/liveness返回DOWN，因为该端点依赖一个外部 Redis 服务，而 Redis 在应用启动时尚未就绪——这是一个经典的“依赖服务启动顺序”问题，而非代码缺陷。

以下是生产环境中最常遇到的七种健康检查失效原因，按排查难度升序排列，并附上完整的诊断链路：

5.1 原因一：Actuator 端点未启用（最常见）

Spring Boot 2.2+ 默认只暴露health和info端点。若Dockerfile中未配置management.endpoints.web.exposure.include=*，则/actuator/health/readiness返回 404。

排查链路：

1. 进入容器：docker exec -it myapp sh
2. 检查 Actuator 端点：curl -v http://localhost:8080/actuator
3. 若返回{"timestamp":"...","status":404}，确认配置缺失
4. 修复：在application.yml中添加：

   management: endpoints: web: exposure: include: "*"

5.2 原因二：Readiness 探针路径错误

/actuator/health是聚合健康状态，而/actuator/health/readiness是专门的就绪探针。若HEALTHCHECK指令写成curl http://localhost:8080/actuator/health，当数据库连接失败时，该端点返回{"status":"DOWN"}，Kubernetes 会认为服务不可用并驱逐 Pod，即使 HTTP 接口仍可响应请求。

验证方法：

# 正确的就绪探针（应返回 UP） curl http://localhost:8080/actuator/health/readiness # 错误的聚合探针（可能返回 DOWN） curl http://localhost:8080/actuator/health

5.3 原因三：容器防火墙拦截探针请求

Docker 默认启用iptables规则，若宿主机防火墙（如ufw）开启，可能拦截localhost到容器的回环请求。现象：curl http://localhost:8080在宿主机成功，但在容器内curl http://localhost:8080超时。

诊断命令：

# 在容器内检查端口监听 netstat -tuln | grep 8080 # 检查 iptables 规则 iptables -L -n | grep 8080

解决方案：在宿主机关闭 ufw，或添加放行规则：

sudo ufw allow from 127.0.0.1 to any port 8080

5.4 原因四：JVM 启动参数阻塞主线程

若Dockerfile中ENTRYPOINT写成java -jar app.jar &（后台运行），则HEALTHCHECK的curl命令会因主进程已退出而失败。Docker 要求ENTRYPOINT进程必须是前台进程，否则容器立即退出。

验证：docker ps查看容器状态，若为Up 2 seconds后迅速变为Exited (0)，即为此问题。

5.5 原因五：Actuator 安全配置拦截

若启用了 Spring Security，未对 Actuator 端点放行，curl会返回 302 重定向到登录页，HEALTHCHECK判定为失败。

修复配置：

management: endpoint: health: show-details: when_authorized endpoints: web: exposure: include: "*" endpoint: health: show-details: always # Spring Security 放行 security: basic: enabled: false management: security: roles: "*"

5.6 原因六：Liveness 与 Readiness 逻辑混淆

Liveness 探针用于判断“是否需要重启”，Readiness 用于判断“是否可接收流量”。若将数据库连接检查放在 Liveness 中，一旦 DB 临时抖动，Kubernetes 会不断重启 Pod，加剧雪崩。正确做法是：

• Liveness：检查 JVM 进程是否存活（如curl http://localhost:8080/actuator/health/liveness）
• Readiness：检查业务依赖是否就绪（如curl http://localhost:8080/actuator/health/readiness）

5.7 原因七：探针超时时间小于应用启动时间（最隐蔽）

--timeout=3s表示探针等待 HTTP 响应的最长时长。若应用启动耗时 4.5s，而--start-period=5s未覆盖此窗口，则前两次探针必失败，触发重启。

终极诊断法：

1. 在容器内手动模拟探针：

   time curl -f http://localhost:8080/actuator/health/readiness

2. 记录平均响应时间，确保--timeout> 该时间 × 1.5
3. 设置--start-period> 应用冷启动最大耗时

实战心得：在Dockerfile中固定HEALTHCHECK参数只是起点，真正的稳定性来自对应用启动曲线的测量。建议在 CI 流水线中加入启动耗时监控，当耗时增长超过 20% 时自动告警，防患于未然。

6. 日志治理：从docker logs到结构化日志管道

docker logs myapp是最原始的日志查看方式，但它在生产环境有三大硬伤：

• 日志丢失：Docker 默认使用json-file驱动，当日志量过大时，docker logs只返回最近 1MB，历史记录永久消失；
• 格式混乱：Spring Boot 的彩色日志（ANSI 转义符）在docker logs中显示为乱码，如[32m2023-10-05 10:20:30.123[0;39m；
• 检索困难：无法按 traceId、level、endpoint 等字段快速过滤，故障定位效率低下。

某导师指导的模拟项目X 在压测时出现偶发性超时，团队花了 3 小时在docker logs的滚动文本中肉眼搜索WARN关键字，而实际上日志中已包含完整的traceId和 SQL 执行耗时，只因格式混乱被忽略。

解决方案是构建结构化日志管道，分三步落地：

6.1 步骤一：应用层日志标准化（Logback 配置）

在src/main/resources/logback-spring.xml中，禁用彩色输出，启用 JSON 格式：

<configuration> <appender name="JSON_CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="net.logstash.logback.encoder.LogstashEncoder"/> </appender> <root level="INFO"> <appender-ref ref="JSON_CONSOLE"/> </root> </configuration>

需添加依赖：

<dependency> <groupId>net.logstash.logback</groupId> <artifactId>logstash-logback-encoder</artifactId> <version>7.4</version> </dependency>

效果：每条日志输出为一行 JSON：

{ "@timestamp":"2023-10-05T10:20:30.123Z", "level":"INFO", "message":"Handling GET /api/users", "traceId":"a1b2c3d4e5f67890", "spanId":"0987654321fedcba", "thread":"http-nio-8080-exec-1" }

6.2 步骤二：容器日志驱动配置（Docker Daemon 层）

修改/etc/docker/daemon.json，将日志驱动设为local（替代默认json-file）：

{ "log-driver": "local", "log-opts": { "max-size": "10m", "max-file": "3" } }

重启 Docker：sudo systemctl restart docker

local驱动优势：

• 日志以二进制格式存储，体积比 JSON 小 60%；
• 支持按时间范围精确截取：docker logs --since "2023-10-05T10:00:00" myapp；
• 不受 ANSI 转义符干扰，docker logs输出纯净。

6.3 步骤三：日志采集与分析（ELK Stack）

部署 Filebeat 作为日志采集器，将容器日志发送至 Elasticsearch：

# filebeat.yml filebeat.inputs: - type: container paths: - "/var/lib/docker/containers/*/*.log" processors: - add_docker_metadata: ~ - decode_json_fields: fields: ["message"] process_array: false max_depth: 1 output.elasticsearch: hosts: ["http://elasticsearch:9200"]

在 Kibana 中创建索引模式filebeat-*，即可用 KQL 语句精准查询：

• traceId : "a1b2c3d4e5f67890"→ 追踪单次请求全链路
• level : "ERROR" and message : "Timeout"→ 定位超时错误
• host.name : "prod-node-01" and service.name : "user-service"→ 按节点和服务过滤

经验：结构化日志的价值在故障复盘时才真正显现。建议在项目初期就集成 Logback + Filebeat，不要等到线上出问题再补课。一次完整的日志管道建设，可将平均故障定位时间（MTTR）从 45 分钟缩短至 8 分钟。

7. 优雅关闭：为什么docker stop有时像拔电源？

docker stop默认发送SIGTERM信号给容器主进程，期望其在 10 秒内自行关闭。但 Spring Boot 应用若未正确处理该信号，会直接被SIGKILL强杀，导致：

• 正在处理的 HTTP 请求被中断，客户端收到Connection reset；
• 数据库连接未正常关闭，连接池泄漏；
• Kafka 消费者未提交 offset，消息重复消费。

某公司某图像处理 Demo 上线后，每天凌晨定时任务执行到一半就被docker stop中断，日志里只有Killed二字，毫无上下文。

根本原因是：Spring Boot 默认不监听SIGTERM。它只响应 JVM 的Runtime.addShutdownHook，而docker stop发送的信号需由应用主动捕获。

7.1 正确的优雅关闭实现

在application.yml中启用优雅关闭：

server: shutdown: graceful spring: lifecycle: timeout-per-shutdown-phase: 30s

server.shutdown=graceful会：

• 接收SIGTERM后，停止接受新请求；
• 等待正在处理的请求完成（最长timeout-per-shutdown-phase时间）；
• 关闭 Web 容器、销毁 Bean、释放资源。

7.2 验证优雅关闭是否生效

1. 启动应用容器；
2. 发起一个长耗时请求（如curl "http://localhost:8080/sleep?seconds=20"）；
3. 在另一终端执行docker stop -t 30 myapp；
4. 观察日志：应看到Graceful shutdown initiated，且请求在 20 秒后正常返回，而非立即中断。

7.3 进阶：自定义关闭钩子处理异步任务

若应用中有@Async方法或 Kafka Listener，需确保它们也参与优雅关闭。在配置类中添加：

@Configuration public class ShutdownConfig { @Bean public ThreadPoolTaskExecutor taskExecutor() { ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor(); executor.setCorePoolSize(5); executor.setMaxPoolSize(10); executor.setQueueCapacity(25); executor.setThreadNamePrefix("async-"); // 关键：设置 await-termination-seconds executor.setAwaitTerminationSeconds(30); executor.setWaitForTasksToCompleteOnShutdown(true); return executor; } }

setWaitForTasksToCompleteOnShutdown(true)确保shutdown()调用时，线程池会等待队列中任务执行完毕。

提示：docker stop的-t参数（超时时间）必须 ≥spring.lifecycle.timeout-per-shutdown-phase，否则 Docker 会在 Spring Boot 完成前强杀进程。建议统一设为 30 秒。

8. 本地调试与远程调试：容器不是黑盒

很多开发者认为“进了容器就只能靠日志”，这是巨大误解。Docker 容器完全支持远程调试，且配置比本地调试更规范。

8.1 本地调试：docker run直连 IDE

在Dockerfile中添加调试端口：

EXPOSE 8080 5005 ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005 -jar /app/app.jar"]

IntelliJ IDEA 中配置 Remote JVM Debug：

• Host:localhost
• Port:5005
• 点击Debug，IDE 会自动连接容器内 JVM。

优势：断点、变量查看、线程栈与本地开发完全一致，无需修改代码。

8.2 远程调试：生产环境安全接入

生产环境不能暴露5005端口，需通过 SSH 隧道安全接入：

# 在本地执行（假设生产服务器 IP 为 192.168.1.100） ssh -L 5005:localhost:5005 user@192.168.1.100

然后在 IDEA 中连接localhost:5005，流量经 SSH 加密传输。

注意：-agentlib:jdwp参数中address=*:5005的*表示监听所有网卡，生产环境必须改为address=127.0.0.1:5005，再配合 SSH 隧道，杜绝公网暴露。

8.3 容器内诊断：jcmd与jstat实时分析

当无法连接远程调试时，可进入容器执行 JVM 诊断命令：

# 进入容器 docker exec -it myapp sh # 查看 JVM 进程 ID jps -l # 查看 GC 统计 jstat -gc <pid> 1s 5 # 查看线程状态 jstack -l <pid> | head -50 # 生成堆转储（需提前挂载 /tmp 目录） jmap -dump:format=b,file=/tmp/heap.hprof <pid>

这些命令要求基础镜像包含 JDK（而非 JRE），再次印证了eclipse-temurin:17-jdk-jammy的必要性。

9. CI/CD 流水线：从docker build到镜像可信分发

手工执行docker build