僵尸进程产生的根源是父进程未回收子进程退出状态。常见原因包括父进程完全遗漏回收逻辑、回收逻辑存在缺陷、父进程失能，以及特殊场景下的责任错位。
僵尸进程产生的根源，不是子进程“没死透”，而是父进程“没收尸”。只要子进程退出后，父进程没调用 wait() 或 waitpid() 读取其退出状态，内核就只能保留它的 PID、退出码和运行时间等极小元数据，进程表项卡在 Z 状态——这就是僵尸。
父进程压根没写回收逻辑
这是最常见也最直接的原因。尤其在简单脚本或初学者 C 程序中，fork() 后只关注子进程执行，完全遗漏了父进程端的清理义务。比如：
- Shell 脚本里用
command &启动后台任务，却没配wait或trap 'wait' EXIT - C 程序中
fork()成功后，父进程分支直接继续往下走，没加waitpid(pid, &status, 0) - Python 中用
subprocess.Popen启动子进程，但既没调.wait()，也没用.communicate()或上下文管理器
父进程写了回收，但逻辑有缺陷
看似有 wait，实则形同虚设。典型问题包括：
- 只在某条成功路径里调用
wait，错误处理分支或异常退出前跳过了回收 - 用了阻塞式
wait()，而父进程此时正卡在 I/O、sleep 或计算循环中，根本轮不到执行那行 - 信号处理函数注册了
SIGCHLD，但 handler 里只调了一次waitpid(-1, &status, WNOHANG)，多个子进程退出时会漏掉其余几个
父进程失能：挂起、崩溃或被强制终止
即使原本逻辑正确，父进程也可能在子进程退出后、执行到 wait 前就失去响应：
- 陷入死锁、长时间阻塞（如等待一个永不就绪的文件描述符）
- 发生段错误、被
kill -9强杀，或因 OOM 被系统干掉 - 本身是某个更大进程树中的一环，上级控制逻辑紊乱，导致它长期闲置不调度
特殊场景下的责任错位
有些情况看似“父进程没问题”，实则责任归属出了偏差：
- 子进程退出时，父进程正忙于处理其他信号，
SIGCHLD被延迟或丢失（尤其未设SA_RESTART时） - 双 fork 实现守护进程时，第一层子进程未及时
exit()，或第二层子进程启动失败，导致中间层滞留为僵尸 - 父进程是 systemd 服务单元，但 Unit 文件中未配置
Restart=on-failure或未正确声明子进程生命周期，导致子进程退出后无人接管
