在 Docker 容器中，业务进程通常直接成为 PID 1。平时看似正常，一旦应用频繁创建子进程，或者启动脚本没有正确处理退出状态，就可能出现大量标记为 Z 或 <defunct> 的僵尸进程。它们虽然不再执行任务，却仍占用进程表项；持续累积后，容器可能无法创建新进程，停止过程也可能变得异常。理解 PID 1 的职责，是解决这类问题的关键。🔍
一、什么是僵尸进程
Linux 子进程退出时，内核会保留少量信息，包括进程号、退出码和资源使用状态，等待父进程通过 wait() 或 waitpid() 读取。读取完成后，该进程才会从进程表中彻底移除，这一过程称为“回收”。
如果父进程没有及时执行回收，已经退出的子进程便进入僵尸状态。僵尸进程基本不消耗 CPU，也不会继续占用原来的业务内存，但会保留 PID 和进程表记录。少量、短暂出现的僵尸通常不必紧张；如果数量持续增长，则说明父进程的进程管理存在缺陷。⚠️
二、容器中的 PID 1 为什么特殊
每个 Linux PID 命名空间都有自己的 PID 1。Docker 启动容器时，Dockerfile 中 ENTRYPOINT 或 CMD 对应的主进程通常会成为容器内的 PID 1。容器生命周期也与它直接关联：PID 1 退出，容器通常随之停止。
传统主机上的 PID 1 通常由 systemd 等初始化系统承担，负责接管孤儿进程、回收退出的后代进程，并协调信号和关机流程。容器中的 PID 1 却可能只是 Java、Node.js、Python 程序或普通 Shell 脚本，这些程序未必按照 init 进程的要求设计。
当某个父进程先于其子进程退出时，孤儿进程会被重新托管给命名空间中的 init 或被设置为子进程回收者的进程。如果容器 PID 1 不执行必要的等待操作，这些进程退出后就可能长期保持僵尸状态。
三、常见成因
- 应用未回收子进程：程序调用 fork、exec 或语言运行库的子进程接口后，没有等待子进程结束。
- Shell 启动方式不当：启动脚本先拉起后台任务，却没有使用 wait，也没有通过 exec 将业务程序替换为前台主进程。
- 父进程提前退出：任务进程仍在运行时，其直接父进程已经结束，后续回收责任被转交给 PID 1。
- 进程管理器配置错误：同时运行多个服务，却没有明确退出顺序、信号转发和子进程回收策略。
- 信号处理不完整：PID 1 没有正确响应 SIGTERM，导致 Docker 停止容器时无法优雅关闭子进程。📦
四、如何排查僵尸进程
第一步是在容器内查看进程状态：
docker exec 容器名 ps -eo pid,ppid,stat,cmd
重点观察 STAT 列。状态包含 Z，或命令中出现 <defunct>，通常代表僵尸进程。随后检查其 PPID，定位没有执行回收操作的父进程。
第二步确认容器内 PID 1 的真实命令：
docker exec 容器名 ps -p 1 -o pid,ppid,stat,args
还可以从宿主机执行 docker top 容器名，持续比较僵尸数量是否增加。如果只偶发出现并迅速消失，可能是正常的短暂过渡；如果数量单向上升，就应继续检查应用代码和启动脚本。
五、优先使用 Docker 的 init 机制
对于会创建子进程、但自身不适合承担 PID 1 职责的应用，可以在启动时加入：
docker run --init 镜像名
--init 会在容器内插入轻量级 init 进程，由它担任 PID 1，负责转发信号并回收子进程。Docker 官方也建议在主进程不能妥善回收子进程时采用这种方式，详见 Docker 多进程容器文档。✅
使用 Docker Compose 时，可以在对应服务中设置 init: true。具体字段应以当前 Compose 规范中的 服务配置说明 为准。
六、正确编写入口脚本
如果脚本只负责准备环境并启动一个主程序，末尾应优先使用 exec 应用命令。这样 Shell 会被业务进程替换，Docker 发出的信号能够直接到达主程序，避免多出一层无法转发信号的父进程。
如果确实需要同时管理多个子进程，脚本必须实现 wait、退出码处理和信号转发。例如收到 SIGTERM 后，应通知所有子进程停止，再等待它们退出。仅仅把多个命令放到后台运行，并不能构成可靠的进程管理方案。
七、从应用层彻底修复
--init 是通用且有效的防护，但更根本的办法仍是修正应用：创建子进程后保存句柄，及时调用相应语言提供的等待接口；设置超时和异常清理逻辑；避免启动无人管理的后台任务；在 SIGTERM 到达时停止接收新请求、终止工作进程并等待回收完成。
对于必须运行多个长期服务的场景，应先考虑拆分为多个容器。Docker 推荐按职责分离服务，让每个容器拥有清晰的主进程和生命周期；相关原则可参考 多容器应用说明。若因兼容性限制必须放在同一容器中，再选择轻量 init 或经过正确配置的进程管理器。
总结
Docker 僵尸进程的本质并不是“进程死不掉”，而是子进程已经退出，父进程却没有读取其退出状态。容器环境放大了这一问题，因为普通应用经常被直接放到 PID 1 的位置。排查时应依次确认僵尸状态、父子关系、PID 1 命令和增长趋势；治理时优先使用 --init、修正入口脚本，并在应用层实现可靠的子进程回收与信号处理。只有让 PID 1 真正承担起进程生命周期管理职责，容器才能稳定启动、平滑停止并长期运行。🚀
