容器环境中偶尔会出现一些状态显示为Z的进程，它们不消耗CPU和内存，却会占据进程号资源。如果放任不管，最终可能导致容器内无法再启动新进程。这类进程就是所谓的僵尸进程，它的产生和容器内PID 1的特殊角色密切相关。

僵尸进程是怎么产生的

要理解僵尸进程，必须先清楚Linux进程的退出流程。一个进程结束时，内核并不会立刻回收它的所有资源，而是保留一个最小的进程描述符，里面存放着退出状态、CPU时间统计等信息，等待它的父进程通过wait或waitpid系统调用来获取这些信息。这个阶段进程的状态就是Z，也就是僵尸。父进程拿到退出状态后，内核才会彻底释放这个描述符，进程才真正消亡。

正常编写程序时，如果父进程比较忙碌，没有及时调用wait，子进程就会短暂停留在僵尸状态。但只要父进程最终调用了wait，僵尸就会被清理。问题在于，如果父进程是一个长期运行的服务，比如Web服务器，它可能fork出很多子进程处理请求，却从不调用wait，那么每个结束的子进程都会变成僵尸，越积越多。

很多人误以为僵尸进程会占用内存，其实僵尸进程不占用户空间内存，也不占CPU时间，但它会占用一个进程号（PID）。Linux系统的PID数量是有限的，默认上限通常是32768。如果僵尸进程堆积到几万个，新的进程就无法创建，系统看起来像卡死了一样。所以僵尸进程的危害主要是耗尽PID资源，而不是直接拖慢系统。

容器环境让僵尸进程问题更突出

在传统的物理机或虚拟机上，操作系统启动的第一个进程是init（例如systemd或SysV init），它的PID为1。init进程有一个重要的职责：收养所有孤儿进程。当一个进程的父进程先退出，这个进程就会变成孤儿，内核会自动把它交给PID 1的init进程。init进程通常有一个循环不断调用wait来回收这些孤儿进程，因此即使某个服务的父进程没有正确处理子进程，这些子进程变成孤儿后也会被init接管并回收，僵尸不会堆积。

容器改变了这个局面。在Docker或Kubernetes的Pod中，容器内部的PID命名空间是隔离的，容器启动的第一个进程成为PID 1。这个进程通常不是你熟悉的systemd，而是你的业务主进程，比如一个Node.js应用、一个Python脚本，或者一个Java服务。这些业务进程在设计时不会考虑充当init角色，它们不会处理SIGCHLD信号，也不会调用wait来回收子进程。如果这个业务进程恰好会fork子进程（例如某些Web服务器、任务调度器、或者使用subprocess模块执行外部命令），当这些子进程退出时，父进程不回收，它们就变成僵尸。更糟的是，如果父进程先于子进程退出，子进程变成孤儿后被内核交给容器内的PID 1，但PID 1就是那个没有回收逻辑的业务进程，于是这些孤儿进程也变成僵尸。结果就是容器内僵尸进程一旦产生，几乎永远不会被清理，除非容器重启。

另外，容器内PID 1还有一个特殊的信号处理问题。在Linux内核中，PID 1进程默认忽略SIGTERM和SIGKILL以外的很多信号，而且它必须显式注册信号处理函数才能接收信号。如果你的业务进程没有正确处理SIGCHLD，内核根本不会通知它子进程退出的消息，它自然也不会去调用wait。这进一步加剧了僵尸进程的积累。

解决僵尸进程的常见方案

明白了原理后，解决方案就围绕“让容器内的PID 1具备回收僵尸进程的能力”来展开。第一种方案是引入一个轻量级的init进程作为容器的PID 1，常见的工具有tini和dumb-init。它们的主要工作就是转发信号并回收所有子进程。使用方式很简单，在Dockerfile中安装tini，然后把ENTRYPOINT设置为tini，后面跟上你的业务命令。例如：

FROM ubuntu:22.04
RUN apt-get update && apt-get install -y tini
ENTRYPOINT ["/usr/bin/tini", "--"]
CMD ["/your-app"]

这样启动容器后，tini作为PID 1运行，你的应用程序变成它的子进程。当你的应用fork出子进程并退出时，tini会收到SIGCHLD信号并调用wait回收它们，僵尸进程问题就解决了。dumb-init功能类似，使用方式也差不多。

第二种方案是直接使用Docker自带的init功能。从Docker 1.13开始，docker run命令支持--init参数。添加这个参数后，Docker会在容器内部启动一个名为docker-init的进程作为PID 1，这个进程实际上就是tini的一个变体。使用方式如下：

docker run --init -d your-image

对于Kubernetes用户，Pod的spec中有一个字段shareProcessNamespace可以控制是否共享进程命名空间，不过这和init进程无关。在Kubernetes中通常需要在镜像层面处理，或者通过设置terminationGracePeriodSeconds等参数来辅助，但核心还是依赖init进程。很多团队选择在基础镜像中预装tini，这样所有业务容器默认都具备僵尸回收能力。

第三种方案是在应用程序代码中主动处理SIGCHLD信号并回收子进程。如果你的应用完全可控，并且你知道它会创建子进程，那么可以在代码里注册信号处理函数，调用waitpid来回收。下面是一个Python示例：

import signal
import os
import errno
def reap_children(signum, frame):
    while True:
        try:
            pid, status = os.waitpid(-1, os.WNOHANG)
            if pid == 0:
                break
        except OSError as e:
            if e.errno == errno.ECHILD:
                break
signal.signal(signal.SIGCHLD, reap_children)
# 业务代码继续运行
# 例如启动一个子进程
pid = os.fork()
if pid == 0:
    # 子进程逻辑
    os._exit(0)

这段代码在收到SIGCHLD信号后使用非阻塞的waitpid循环回收所有已退出的子进程，直到没有子进程为止。这种方案不依赖外部工具，但要求开发者对信号处理有充分理解，并且所有可能产生子进程的路径都要覆盖到。如果应用使用了第三方库或者框架创建子进程，自己处理信号可能会有冲突。

避免僵尸进程的实践建议

根据不同的应用场景，选择最合适的方案能事半功倍。对于大多数无状态微服务，如果它们自己不会fork子进程，其实不需要特别处理。但是很多应用会通过系统调用执行外部命令，比如Python的subprocess、Node.js的child_process，甚至某些ORM框架在底层也会调用其他进程。这些场景下，推荐统一在镜像中添加tini或dumb-init，这是一种一劳永逸的做法，对应用代码无侵入。

判断一个容器是否会产生僵尸进程，可以进入容器运行ps aux查看是否存在状态为Z的进程。如果已经出现了僵尸，通常意味着PID 1没有正确回收。此时可以检查容器的启动命令，确认PID 1是业务进程还是init工具。排查时注意，如果使用docker exec进入容器，看到的PID 1可能并不是你预期的，因为exec会启动新的进程，但PID 1始终是容器启动时那个进程。

另一个容易忽略的地方是：即使使用了tini，如果业务进程在处理SIGCHLD时存在bug，例如调用waitpid后没有正确循环，偶尔还是会有僵尸残留。所以除了依赖init进程，最好在应用层面也遵循良好的子进程管理习惯。例如在Python中优先使用subprocess.run而不是os.system，因为前者会等待子进程结束并回收；在Node.js中监听exit事件。好的编程实践加上合适的init工具，僵尸进程问题基本可以杜绝。

最后提醒一点：不要在容器内运行完整的systemd作为PID 1，虽然它能解决僵尸进程，但会引入大量额外组件，违背容器轻量化的初衷。tini和dumb-init正是为此设计的，它们的体积只有几十KB，功能单一，非常适合容器场景。