在 Docker 容器中，业务程序通常直接成为 PID 1。看似只是进程编号发生变化，实际上它还接过了 Linux 初始化进程的一部分职责。如果程序没有正确处理子进程退出和终止信号，就可能出现僵尸进程持续堆积、容器停止缓慢，甚至无法创建新进程等问题。本文将从现象、原理、排查到修复，整理一套可直接执行的诊断流程。🔍
一、先理解 PID 1 与僵尸进程
子进程退出后，内核会暂时保留其进程描述信息和退出状态，等待父进程调用 wait() 或 waitpid() 读取。在此期间，该进程处于 Z 状态，也就是僵尸进程。它已经不再执行任务，通常也不会继续占用 CPU，但仍会占用 PID 和进程表项。
如果父进程提前退出，其尚未结束的子进程会被重新托管。在容器的 PID 命名空间中，PID 1 需要承担相关进程回收职责。然而，很多 Web 服务、脚本解释器和业务程序并不是按照 init 系统的要求设计的，成为 PID 1 后可能不会主动回收被托管的子进程。
需要注意：僵尸进程本身无法通过 kill 直接清除，因为它已经退出。真正需要处理的是未调用等待函数的父进程，或者让合适的 init 进程负责回收。
二、常见故障表现
- 容器内执行 ps 时出现 STAT 为 Z，或者命令末尾显示 <defunct>。
- 容器运行时间越长，进程数量越多，但实际业务并没有对应的并发任务。
- 程序频繁启动 shell、浏览器、转码器或定时任务后，僵尸数量持续增长。
- 执行 docker stop 后容器不能及时退出，最终只能被强制终止。
- 应用逐渐出现 fork 失败、无法创建线程或无法启动新命令等异常。
僵尸进程与停止缓慢经常同时出现，但两者不是完全等价的问题。前者通常与子进程回收有关，后者更多与 PID 1 的信号处理、入口脚本和信号转发有关，排查时应分别验证。⚠️
三、按步骤定位问题
1. 确认容器中的 PID 1
先执行 docker top 容器名 查看容器进程，也可以进入容器运行 ps -o pid,ppid,stat,cmd -e。重点确认 PID 1 到底是业务程序、shell 脚本、npm、进程管理器，还是 tini 等轻量 init。
如果看到 PID 1 是 sh、bash 或 npm，而真正的应用是其子进程，就需要检查入口命令是否引入了不必要的中间层。Dockerfile 中的 Shell 形式 CMD 会经过 shell 启动，例如 CMD node app.js；Exec 形式 CMD ["node","app.js"] 则会直接执行目标程序，通常更利于信号传递。
2. 查找 Z 状态进程及其父进程
在容器中运行 ps -eo pid,ppid,stat,etime,cmd，筛选 STAT 包含 Z 的记录。随后根据 PPID 找到父进程，判断它是否长期运行，以及它是否负责创建短生命周期子进程。
不要只统计一次数量。建议间隔数分钟重复检查：如果同一批僵尸数量保持不变，可能是偶发缺陷；如果数量持续增加，则说明父进程回收逻辑存在稳定问题，应优先处理。
3. 检查容器停止时的信号路径
执行 docker stop 容器名 时，Docker 会向容器主进程发送停止信号，并等待其退出。可以同时观察应用日志，确认 PID 1 是否收到了 SIGTERM，以及应用是否进入优雅关闭流程。
如果入口脚本通过普通方式启动业务程序而没有使用 exec，shell 仍然占据 PID 1，信号可能没有按预期传给子进程。典型修复方式是在脚本最后使用 exec 应用命令，让业务程序替换 shell，而不是成为 shell 的子进程。
4. 检查子进程创建逻辑
对于自行 fork 或启动外部命令的应用，需要检查所有执行路径是否都会调用 wait()、waitpid() 或语言运行时提供的等价接口。异步任务、超时分支、异常返回和强制取消最容易遗漏回收逻辑。
若应用通过 shell 启动后台任务，还应检查是否存在命令末尾添加 &、父脚本提前退出、子进程脱离控制等情况。多进程服务最好明确指定唯一的进程管理者，不要让多个脚本相互启动后失去父子关系。
四、推荐修复方案
方案一：运行容器时启用 init
最直接的方式是使用 docker run --init 镜像名。Docker 会在容器内加入轻量 init 进程，由它作为 PID 1 负责转发信号并回收子进程。可在 docker run 官方文档中查看 --init 参数说明。
方案二：在 Compose 中配置 init
使用 Docker Compose 时，可以在对应服务下设置 init: true。修改后需要重新创建容器，再检查 PID 1 和僵尸数量是否恢复正常。这里的 init 是容器进程初始化机制，不要与部署前执行迁移任务的“初始化容器”混为一谈。
方案三：在镜像中集成 tini
如果运行环境无法统一追加 --init，可以在镜像中安装 tini，并配置为 ENTRYPOINT，让它位于业务程序之前。tini 的作用应保持单一，不要把数据库、定时任务和多个长期服务全部塞进同一个容器。
方案四：修正应用和入口脚本
- Dockerfile 优先使用 Exec 形式的 ENTRYPOINT 和 CMD。
- 入口脚本最后使用 exec 启动主程序。
- 应用显式处理 SIGTERM，并在退出前停止接收请求、关闭连接和等待子任务。
- 创建子进程后始终读取退出状态，覆盖成功、失败、超时和取消路径。
- 不要把定期重启容器当作长期解决办法，它只能暂时清空现象。
五、修复后的验证清单
- 确认 PID 1 已变为 tini 等 init，或确认业务程序具备完整的 PID 1 行为。
- 连续运行能够高频创建子进程的业务场景，观察 Z 状态进程是否持续增加。
- 执行 docker stop，检查应用能否在预期时间内完成优雅退出。
- 确认入口脚本没有残留 shell 层，也没有无人管理的后台任务。
- 结合容器进程数、停止耗时和应用错误日志建立持续监控。
总结
Docker 的 PID 1 问题并不是简单的“加一个参数”就结束了。完整排查应同时覆盖进程树、僵尸回收、信号处理和入口脚本四条链路。对于会创建子进程的服务，优先启用轻量 init，并修正应用自身的 wait 与 SIGTERM 处理逻辑；对于单进程服务，则应减少无意义的 shell 包装，使用 Exec 形式直接启动。只有在压力场景和停止流程中都完成验证，才能确认问题真正解决。✅
