Linux 僵尸进程是如何产生的？

僵尸进程产生的主要原因是父进程未调用 wait() 或 waitpid() 回收子进程退出状态，导致子进程残留 task_struct 并卡在 Z 状态；常见场景包括父进程忽略 SIGCHLD、双 fork 隔离失败、父进程崩溃等。

子进程退出后父进程没调用 wait() 或 waitpid()

这是最常见、最直接的产生原因。子进程调用 exit() 后，内核会保留它的 task_struct 和退出状态（如退出码、CPU 时间等），但释放其他资源（内存、文件描述符等）。这部分残留信息必须由父进程显式读取并清理——通过 wait() 或 waitpid() 系统调用完成。如果父进程完全不调用，或者只在某条分支里调用（比如漏了错误处理路径），子进程就会卡在 Z（zombie）状态。

• 现象：用 ps aux | grep 'Z' 或 ps -eo stat,ppid,pid,cmd | grep '^Z' 能看到状态列为 Z 的进程
• 注意：kill -9 对僵尸进程无效——它已经死了，只是没被“收尸”
• 风险：每个僵尸进程占用一个 PID 和少量内核内存；PID 耗尽（默认上限 32767）会导致新进程无法创建

父进程忽略 SIGCHLD 信号但未设为 SIG_IGN

当子进程终止，内核默认向父进程发送 SIGCHLD。如果父进程注册了自定义信号处理函数（比如用 signal(SIGCHLD, handler)），但 handler 里没调用 waitpid(-1, &status, WNOHANG)，或者只调用了一次却有多个子进程退出，就可能漏收——尤其在高并发 fork 场景下。更隐蔽的是：有些代码写了 signal(SIGCHLD, SIG_DFL) 或干脆没处理，结果信号被忽略，而内核又不会自动回收，于是僵死。

• 正确做法是：要么设为 SIG_IGN（signal(SIGCHLD, SIG_IGN)），让内核代劳回收；要么在 handler 中循环调用 waitpid() 直到返回 -1 + errno == ECHILD
• 陷阱：wait() 是阻塞的，waitpid(-1, ……, WNOHANG) 才是非阻塞且可轮询多个子进程的

双 fork 隔离失败或误用

“两次 fork”是经典规避方案：父进程 fork 出子进程 A，A 再 fork 出孙进程 B 后立即 exit()；B 变成孤儿进程，被 init（PID 1）接管，而 init 会自动 wait 所有子进程，所以 B 不会变僵尸。但这个技巧容易用错：

• 子进程 A 必须在 fork B 后立刻 exit()，不能做任何可能阻塞或崩溃的操作，否则 A 自己可能变成僵尸
• 如果父进程在 A exit() 前就退出，A 和 B 都可能被 init 接管——看似安全，但逻辑已脱离设计预期
• Go/Python 等语言的运行时可能自带子进程管理，盲目套用双 fork 可能和 runtime 冲突

父进程崩溃或长期不响应导致“收尸”中断

即使父进程原本写了正确的 wait 逻辑，若它在子进程退出后、执行到 wait 前发生段错误、被 kill -9 或死锁，那已退出的子进程就永远卡在僵尸态。此时唯一出路是让 init 接管——但前提是父进程先挂掉。而如果父进程是守护进程（如 nginx worker、systemd service），它往往设计为永不停止，这就导致僵尸进程持续累积。

• 验证方法：ps -o pid,ppid,stat,comm -C your_parent_cmd 查看父进程是否存活，再对照其子进程的 PPID 是否指向它
• 临时缓解：杀掉父进程（kill -9 ），init 通常会在几秒内回收其遗留的僵尸子进程
• 根本解法：在父进程代码中确保所有退出路径（包括信号处理、异常分支）都覆盖 wait 或设 SIG_IGN

真正麻烦的不是单个僵尸进程，而是父进程逻辑里藏着条件竞争或信号处理盲区——它可能在 99% 的情况下正常工作，直到某次高负载或特定信号序列触发漏收。查 /proc//status 里的 State: Z 和 PPid: 字段，比盯着 top 的 zombie 计数更有诊断价值。