容器内应用进程管理的核心是确保应用成为PID 1并正确响应SIGTERM以支持优雅退出，需通过exec格式指令、tini等init系统及应用层信号处理协同实现。
容器内应用的进程管理，核心是让应用成为 1 号进程，并能正确响应系统信号（尤其是 SIGTERM），从而支持优雅退出。这不是靠“启动脚本”堆砌实现的，而是由 Dockerfile 指令组合、基础镜像选择和应用行为共同决定的。
确保应用是 PID 1
Docker 容器生命周期由 1 号进程（PID 1）完全控制。如果它不是你的应用本身，就极易导致信号丢失、僵尸进程或强制终止。
- 避免使用
CMD ["sh", "-c", "your-command"]或ENTRYPOINT ["sh", "-c", "…"]—— 这会让/bin/sh成为 PID 1，而它默认不转发SIGTERM - 始终采用 exec 格式：例如
CMD ["node", "app.js"]或ENTRYPOINT ["java", "-jar", "app.jar"]，这样应用直接作为 PID 1 启动 - 若必须用 shell 脚本做前置准备（如环境变量注入、权限设置），脚本末尾务必用
exec "$@"替换当前进程，例如：#!/bin/sh<br>set -e<br># 做一些初始化<br>exec "$@"
再通过ENTRYPOINT ["./entrypoint.sh"]+CMD ["your-app"]组合调用
引入轻量 init 系统（推荐 tini）
即使应用自身处理了信号，仍可能产生子进程（如 fork 出的 worker）。没有 init 系统时，这些子进程变成孤儿，最终成为僵尸进程。
- 在基础镜像中启用 tini：Docker 官方镜像大多已内置（如
debian:slim、node:alpine支持TINI_VERSION自动安装） - 显式声明：在 Dockerfile 中加入
ENTRYPOINT ["tini", "--"]，再接你的主命令，例如：ENTRYPOINT ["tini", "--"]<br>CMD ["python", "main.py"]
- tini 会接管 PID 1，自动回收僵尸进程，并透传信号给主应用进程树
应用层需主动处理 SIGTERM
Docker 发送 SIGTERM 后，是否等待、清理资源、关闭连接，完全取决于应用自身逻辑。
- Node.js 示例：监听
process.on('SIGTERM', () => { server.close(); process.exit(0); }) - Java 示例：注册 JVM shutdown hook，或使用 Spring Boot 的
@PreDestroy/SmartLifecycle - Go 示例：用
signal.Notify捕获os.Interrupt和syscall.SIGTERM - 关键点：收到信号后应停止接受新请求，完成正在处理的任务，再退出；避免直接
os.Exit()或无响应
验证与调试方法
写完 Dockerfile 后，不能只看容器是否“跑起来”，要验证信号通路是否完整。
- 启动容器后，进容器执行
ps -eo pid,ppid,comm,args，确认你的应用确实是 PID 1，且无多余 shell 层 - 在宿主机执行
docker stop -t 30 <container>，观察日志是否输出“正在关闭服务”类信息，而非被强行 kill - 用
docker exec <container> ps aux查看是否有残留的僵尸进程（Z状态） - 对生产镜像，建议添加
HEALTHCHECK并配合SIGUSR1等自定义信号做运行时健康探针
