Spring Boot(Kotlin)应用Docker容器无法停止的原因及PID1疑问

一、应用无法在Docker容器中停止的可能原因 #

• PID 1进程未处理终止信号：如果JVM不是容器的PID 1进程，或者PID 1进程没有把SIGTERM等终止信号转发给JVM，应用就收不到停止指令，容器无法正常退出。
• Spring Boot应用自身阻塞：应用内存在未关闭的后台线程、死循环，或者数据库连接、文件句柄等资源未释放，导致JVM无法响应终止信号，没法正常关闭。
• Restart策略干扰：你的Spring Boot服务设置了restart: on-failure，如果应用退出时返回非0状态码，Docker会自动重启容器，可能让你误以为“无法停止”——可以用docker-compose ps查看容器状态，或者docker-compose logs确认是否有重启日志。
• 多阶段构建的启动脚本问题：如果最终镜像用shell脚本启动应用，但脚本没正确处理信号（比如没使用exec命令），PID 1会是shell进程，它不会转发信号给JVM，导致应用无法停止。

二、非JVM进程成为PID 1的情况 #

会出现，常见场景：

• 用shell形式的启动命令（比如ENTRYPOINT java -jar app.jar，没加数组括号），Docker会通过sh -c执行命令，此时PID 1是shell进程，不是JVM。
• 用自定义启动脚本启动，但脚本里直接运行java ...而不是exec java ...，PID 1是脚本对应的shell进程，JVM是其子进程。
• 多阶段构建时如果不小心引入了其他初始化进程，也可能抢占PID 1，但这种情况很少见。

三、ENTRYPOINT vs CMD对PID 1和停止行为的影响 #

核心区别不是ENTRYPOINT或CMD，而是命令的执行形式：

• 用**exec形式（数组格式）**的ENTRYPOINT/CMD：比如ENTRYPOINT ["java", "-jar", "app.jar"]或CMD ["java", "-jar", "app.jar"]，JVM会直接成为PID 1，能接收Docker发送的SIGTERM信号，正常处理Spring Boot的关闭逻辑。
• 用shell形式的ENTRYPOINT/CMD：比如ENTRYPOINT java -jar app.jar，Docker会启动sh -c来执行命令，此时PID 1是shell进程，它不会转发SIGTERM给JVM，导致应用收不到停止信号，只能通过docker kill强制终止。
• 所以不管用ENTRYPOINT还是CMD，只要用exec形式，就能让JVM成为PID 1，避免停止问题。

给Docker/Gradle新手的建议 #

1. 检查Dockerfile的启动命令，改成exec形式：

   # 多阶段构建的最终阶段
   FROM openjdk:17-jdk-slim
   COPY --from=builder /app/build/libs/app.jar /app.jar
   ENTRYPOINT ["java", "-jar", "/app.jar"]
   

2. 如果用启动脚本，脚本里必须加exec来替换当前进程：

   # start.sh
   exec java -jar /app.jar
   

   然后Dockerfile里用：

   ENTRYPOINT ["/start.sh"]
   

3. 测试停止时，先执行docker-compose stop，等待30秒左右，用docker-compose ps确认容器状态；如果没停，查看docker-compose logs，看Spring Boot是否打印了关闭日志（比如Closing Spring Context），判断应用是否收到信号。
4. 若被restart: on-failure干扰，可用docker-compose down强制停止并移除容器，避免自动重启。

内容的提问来源于stack exchange，提问作者programmer