在长期运行的 Docker 容器中，如果进程列表不断出现 Z 状态或 <defunct> 项，通常说明子进程已经退出，却没有被父进程正确回收。少量僵尸进程未必立即影响 CPU 或内存，但它们会占用进程表条目，持续堆积后可能导致容器无法创建新进程，甚至出现任务执行失败、健康检查异常等问题。🧟
一、僵尸进程为什么会出现在容器中
Linux 子进程退出时，内核会暂时保留其进程号和退出状态，等待父进程调用 wait 或 waitpid 获取结果。在父进程完成回收之前，该进程就处于僵尸状态。如果父进程没有实现回收逻辑，僵尸进程便可能长期留在进程表中。
容器里的第一个进程会成为 PID 1。传统 Linux 系统通常由专门的 init 系统承担这个角色，而容器为了保持轻量，往往直接让 Java、Node.js、Python 程序或启动脚本成为 PID 1。许多业务程序只关注自身功能，并未针对孤儿进程回收和信号转发进行设计，这正是问题的常见根源。
常见触发场景
- 应用频繁创建子进程，但没有等待并读取子进程的退出状态。
- 父进程提前结束，遗留的孤儿进程被交给 PID 1，而 PID 1 没有执行回收。
- 入口脚本在后台启动多个任务，却缺少 wait、trap 和退出码传递逻辑。
- 使用 sh -c 包装应用，导致 Shell 占据 PID 1，但没有正确转发终止信号。
- 任务调度器、浏览器自动化、视频处理或构建工具频繁派生短生命周期进程。
二、先确认是否真的发生堆积
可以执行 docker top 容器名 查看容器进程，也可以进入容器运行 ps -eo pid,ppid,stat,comm,args。重点检查 STAT 列中包含 Z 的进程，并记录它们的 PID、PPID 和命令名称。部分精简镜像没有 ps，可临时使用镜像自带工具，或从宿主机读取对应 PID 命名空间的信息。
发现僵尸进程后，不要只尝试 kill。僵尸进程本身已经结束，发送信号通常无法清除它，真正需要处理的是其父进程。可通过 PPID 找到父进程，再检查该程序为何未调用 wait。若大量僵尸进程的 PPID 为 1，通常应重点排查容器入口进程是否具备 init 能力。
提示：一次快照只能证明“当前存在僵尸进程”，不能证明“正在持续堆积”。建议间隔观察进程数量，并结合业务任务触发时间、容器日志和进程创建失败记录判断趋势。🔍
三、检查 PID 1 和启动方式
执行 docker exec 容器名 ps -p 1 -o pid,ppid,stat,comm,args，确认 PID 1 究竟是业务程序、Shell 脚本，还是 Tini 等轻量 init。随后使用 docker inspect 容器名 检查 Entrypoint、Cmd 和启动参数，避免只查看 Dockerfile，因为部署平台可能覆盖镜像中的默认配置。
如果启动命令采用 Shell 形式，例如由 sh -c 间接拉起服务，应检查脚本末尾是否使用 exec 替换 Shell。合理使用 exec 能让业务进程直接接收 Docker 发出的 SIGTERM，但它并不能自动解决所有子进程回收问题。业务确实会派生多个子进程时，仍建议配置专用 init。
四、启用 Docker 的 init 进程
使用命令行启动容器时，可添加 docker run --init。Docker 会在容器中加入轻量 init 进程，使其成为 PID 1，负责转发信号并回收孤儿子进程。相关参数可参考 Docker 容器运行命令文档。
使用 Compose 时，可在对应服务下配置 init: true，然后重新创建容器。仅修改配置但不重建旧容器，不会改变现有容器的 PID 1。需要注意，Compose 中用于启动前置任务的 init container，与负责 PID 1 回收的 init: true 并不是同一个概念，排查时不要混淆。
如果运行环境不能使用 --init，可以在镜像中安装 Tini 或 dumb-init，并把它设置为 ENTRYPOINT，再由它启动业务程序。此方案适合需要跨平台统一镜像行为的场景，但应固定可信版本、校验下载文件，并确认 init 后的参数和退出码能够正确传递。
五、配置完成后的验证步骤
- 重新创建容器，确认 PID 1 已经变为预期的轻量 init。
- 重复执行会派生子进程的真实业务任务，观察 Z 状态数量是否继续增长。
- 执行 docker stop，确认应用能够收到终止信号并在超时前正常退出。
- 检查容器退出码、重启策略和健康检查，避免 init 掩盖业务程序自身异常。
- 继续修复应用或脚本中的 wait 逻辑，不要把 init 当成替代代码治理的万能方案。
六、容易踩到的排查误区
重启容器只能暂时清空当前 PID 命名空间，无法消除产生僵尸进程的原因；提高进程数限制也只是延后故障。另一个误区是把完整的 systemd 塞进单一服务容器，这会增加权限、配置和维护成本。多数场景使用轻量 init 即可，Docker 也更推荐通过容器重启策略管理服务生命周期，相关说明可查看 官方重启策略文档。
总结
Docker 容器僵尸进程堆积的核心，并不是进程仍在运行，而是退出状态没有被父进程回收。排查时应沿着“确认 Z 状态、定位 PPID、识别 PID 1、检查入口脚本、启用 init、重复业务验证”的顺序推进。对于会频繁创建子进程的长期服务，配置 --init、Compose 的 init: true 或可信的轻量 init，可以显著降低进程回收和信号处理风险；同时修复应用自身的子进程管理逻辑，才能从根本上保持容器稳定。✅
