子进程退出后卡在Z状态的根本原因是父进程未调用wait()或waitpid()“收尸”，导致内核保留其元数据无法释放；常见于父进程遗漏wait、阻塞不轮询、SIGCHLD处理不当等。
为什么子进程退出后还卡在 Z 状态？
根本原因只有一个：父进程没“收尸”。子进程调用 exit() 后，内核保留其 PID、退出码、CPU 时间等少量元数据，等待父进程通过 wait() 或 waitpid() 主动读取并释放。若父进程一直不调用，该条目就永久滞留在进程表中，状态显示为 Z（zombie）。
- 常见诱因包括：父进程逻辑遗漏
wait调用；父进程忙于计算/阻塞 I/O，长期不轮询子进程；父进程注册了SIGCHLD但 handler 里忘了调用wait；或 handler 被中断导致调用失败 - 注意：
kill -9对僵尸进程完全无效——它早已不调度、无内存上下文，只剩一个内核结构体，kill找不到目标 - 孤儿进程（父进程先死）不会直接变僵尸；它会被
init（PID 1）接管，而init会自动wait所有子进程，所以孤儿进程退出后通常不会滞留为僵尸
怎么一眼看出谁是僵尸？用什么命令定位源头？
别只看 top 下的 zombie 数字——它只告诉你总量，不告诉你谁造的孽。真正要查，得用 ps 定位父进程：
ps aux | awk '$8 ~ /^Z/ { print $2,$3,$11 }'
输出形如 1234 5678 /bin/bash，其中第1列是僵尸 PID，第2列是其父进程 PID（PPID），第3列是命令名。再顺藤摸瓜查父进程：
ps -o pid,ppid,comm,state -p 5678
如果发现父进程已不存在（PPID=1 但状态不是 S），说明它曾是孤儿但已被 init 接管——此时僵尸应已被清理，若仍存在，大概率是父进程 bug 导致多次 fork 未配对 wait。
wait() 和 waitpid() 怎么选？不阻塞的写法长什么样？
二者核心区别在于是否阻塞和是否指定子进程：wait() 会挂起父进程直到任意一个子进程结束；waitpid(pid, &status, options) 可指定 PID、加 WNOHANG 避免阻塞。
- 推荐默认用
waitpid(-1, &status, WNOHANG)：-1 表示等待任意子进程，WNOHANG让它立即返回（0 表示无子进程退出，>0 表示回收成功，-1 表示出错） - 必须检查返回值！忽略返回值等于没写
wait - 若父进程是事件循环（如网络服务器），应在主循环中定期轮询，而非依赖信号——信号可能丢失，且异步信号安全函数有限，
waitpid是安全的 - 不要用
wait(NULL)——它不提供退出码，也掩盖了是否真有子进程退出
信号处理方式（SIGCHLD）有哪些坑？
设 handler 捕获 SIGCHLD 是常见做法，但极易踩坑：
-
signal(SIGCHLD, handler)在某些系统上会重置为默认行为，应改用sigaction()并设置SA_RESTART和SA_NOCLDWAIT（后者可让内核自动回收，但仅适用于你完全不关心子进程退出码的场景） - handler 中禁止调用非异步信号安全函数（如
printf、malloc），只允许write、waitpid等少数几个——否则可能死锁或崩溃 - 多个子进程几乎同时退出时，
SIGCHLD可能被合并为一次发送，所以 handler 里必须用循环调用waitpid(-1, &status, WNOHANG)直到返回 0 - 最稳妥的兜底方案：在程序启动时执行
signal(SIGCHLD, SIG_IGN)。内核会直接回收子进程资源，不发信号，也不留僵尸——前提是业务真的不需要退出码
真正难的从来不是“怎么杀僵尸”，而是“怎么让父进程不漏掉任何一个子进程的退出通知”。轮询 + WNOHANG 最可控，SIG_IGN 最省心，但都得根据是否需要退出码来权衡。别信“一键清理”脚本——强行 kill -9 僵尸只是掩耳盗铃，根源还在父进程逻辑里。
