容器运行一段时间后，偶尔会出现进程数量持续增长、无法创建新进程，甚至停止容器时长时间卡住的情况。🔍 这类问题往往与僵尸进程堆积以及容器内 PID 1 未正确承担进程回收、信号处理职责有关。理解 Linux 进程生命周期，并确认容器的主进程是谁，是定位问题的关键。

一、什么是僵尸进程？

子进程退出时，内核会保留它的 PID、退出状态等少量信息，等待父进程通过 wait() 或 waitpid() 读取。如果父进程迟迟未执行回收操作，子进程就会进入 Z 状态，也就是僵尸进程。它通常显示为 <defunct>。

僵尸进程已经停止执行，通常不会继续消耗 CPU，也不会占用大量业务内存，但会占据进程表槽位和 PID。少量、短暂出现的僵尸进程未必是故障；如果数量持续增长，则可能耗尽容器或宿主机允许的进程数量，导致 fork、exec 或线程创建失败。⚠️

二、为什么 Docker 容器更容易暴露 PID 1 问题？

普通 Linux 系统通常由 systemd 等初始化系统担任 PID 1，而容器中的 ENTRYPOINT 或 CMD 主进程通常直接成为 PID 1。Docker 的官方文档指出，容器主进程需要管理其启动的其他进程；如果它不能妥善回收子进程，可以使用 --init 插入轻量级 init 进程。

PID 1 具有特殊地位：当孤儿进程被重新托管后，它需要负责等待并回收这些进程。同时，作为容器生命周期的入口，它还必须正确处理 SIGTERM、SIGINT 等信号。很多业务程序只按普通应用进程设计，并未考虑自己会成为 PID 1，因此容易出现两个问题：孤儿子进程退出后无人回收，以及停止信号没有按预期传递给实际工作进程。

常见风险场景

• 使用 Shell 脚本启动应用，但脚本没有通过 exec 替换自身。
• 应用频繁创建 worker、定时任务或外部命令，却没有调用 wait 系列接口。
• 父进程提前退出，遗留的子进程随后被 PID 1 接管。
• 容器内同时运行多个服务，却没有可靠的进程管理机制。
• 应用没有注册 SIGTERM 处理逻辑，无法完成连接关闭、任务落盘等清理工作。

三、如何确认容器内是否存在堆积？

首先查看容器中的进程状态：

docker exec 容器名 ps -eo pid,ppid,stat,comm,args

重点检查 STAT 列包含 Z 的记录，并观察其 PPID。也可以从宿主机执行：

docker top 容器名 -eo pid,ppid,stat,comm,args

如果镜像非常精简，没有 ps 命令，可以读取 /proc 下的进程状态，或临时使用具备诊断工具的调试容器进入同一 PID 命名空间。排查时不要只看某一时刻的数量，建议间隔采样，确认僵尸进程是否不断新增。

推荐排查顺序

1. 确认 PID 1：执行 ps -p 1 -o pid,ppid,stat,args，判断它是应用、Shell 脚本还是 init 程序。
2. 追踪父子关系：根据 PPID 找到未执行回收的直接父进程，并结合进程树判断启动链路。
3. 检查启动配置：查看 Dockerfile 的 ENTRYPOINT、CMD，以及 Compose 中的 command 和 entrypoint。
4. 测试停止行为：执行 docker stop，并同步观察日志，确认应用能否收到 SIGTERM 并在宽限期内退出。
5. 检查进程限制：查看容器的 PIDsLimit、宿主机 PID 使用情况以及相关告警，评估是否已接近上限。

四、Shell 入口为何经常导致信号丢失？

假设入口脚本直接运行 ./server，Shell 会保持为 PID 1，而 server 成为它的子进程。docker stop 默认向容器主进程发送停止信号，此时信号先到 Shell；如果 Shell 没有转发，server 就无法执行优雅退出逻辑。

对于只负责启动单个前台程序的脚本，应使用：

exec ./server

exec 会让应用替换 Shell 进程，使应用直接成为 PID 1，避免多余的信号转发层。不过，这只能解决启动链和部分信号问题；如果应用会产生需要托管的孤儿进程，它仍应正确调用 wait，或者交由专用 init 进程处理。

五、使用 --init 处理回收与信号转发

最直接的改进方式是在启动容器时添加 --init：

docker run --init -d --name myapp 镜像名

启用后，Docker 会在容器内插入轻量级 init 作为 PID 1，由它负责转发信号并回收被托管的僵尸进程。对于会创建子进程、使用第三方程序或无法方便修改业务代码的镜像，这种方案通常简单有效。🛠️

在 Docker Compose 中可为服务配置 init: true。若运行环境不支持该选项，也可以在镜像中显式使用 Tini、dumb-init 等轻量级 init。通常不建议仅为进程回收而在单服务容器内启动完整的 systemd，因为这会增加镜像复杂度和运行维护成本。

六、修复后如何验证？

• 持续采样 Z 状态进程，确认数量不再单向增长。
• 执行 docker stop，检查容器是否能在预期时间内退出，而不是最终依赖 SIGKILL。
• 验证应用日志中是否出现收到 SIGTERM、停止接收请求、关闭连接等记录。
• 进行多轮启动、停止和子任务压力测试，避免问题只在长时间运行后再次出现。
• 为容器进程数、停止耗时和异常退出建立监控，而不是仅依赖人工执行 ps。

总结

Docker 僵尸进程问题的本质并不是“容器产生了特殊进程”，而是应用被放到 PID 1 位置后，没有完整承担子进程回收和信号处理职责。排查时应围绕 PID 1、PPID、Z 状态、启动脚本与停止信号逐层定位。✅ 对单应用入口优先使用 exec；对会派生子进程或行为不可控的程序，使用 --init 或轻量级 init；同时让应用显式处理 SIGTERM，并通过持续监控验证修复效果，才能从根源上避免僵尸进程长期堆积。