僵尸进程产生的主要原因是父进程未调用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/ 里的 State: Z 和 PPid: 字段，比盯着 top 的 zombie 计数更有诊断价值。
