根本原因是父进程收到SIGCHLD信号后未调用wait/waitpid清理子进程，导致僵尸进程持续累积；需通过ps监控PPID、/proc/PID/status检查信号队列与屏蔽状态、strace跟踪信号处理及wait调用行为，并重点修复未循环回收、信号重注册等编码缺陷。
这种情况本质是父进程“收尸机制失灵”：它收到了子进程退出的 SIGCHLD，却没调用 wait() 或 waitpid() 清理子进程描述符，导致每个退出子进程都卡在僵尸状态。排查需聚焦信号处理逻辑与系统调用行为，而非仅看进程列表。
确认僵尸是否持续新增且集中归属同一父进程
先验证现象是否符合“无限增殖”特征：
- 运行 watch -n 1 'ps -eo stat,ppid,pid,comm | awk '\''/^[Zz]$/ {print $2}'\'' | sort | uniq -c | sort -nr | head -5' —— 每秒刷新，观察是否有某个 PPID 对应的僵尸数持续上升
- 若某 PPID（如 1234）反复出现在输出前列，且计数每秒+1或+2，基本锁定该进程为元凶
- 同时执行 ps -p 1234 -o pid,comm,state,etime,cmd 确认它仍在运行、未挂起（State 不为
T或D）
检查父进程的 SIGCHLD 信号是否被阻塞或未正确处理
即使父进程在运行，也可能因信号配置异常而“视而不见”子进程退出：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 查看其当前信号队列和屏蔽状态：cat /proc/1234/status | grep -E 'SigQ|SigBlk'
-
SigQ 值远大于 0（如 10+），说明大量
SIGCHLD积压未处理 -
SigBlk 十六进制值中包含
0000000000000002（对应SIGCHLD=17的 bit 17），说明该信号被显式屏蔽 - 进一步确认：cat /proc/1234/status | grep CapEff 若有效能力含
cap_sys_ptrace，可继续用 strace 跟踪
用 strace 实时捕获父进程对 SIGCHLD 的响应行为
这是定位“重复捕获却不 wait”的关键一步：
- 执行 strace -p 1234 -e trace=signal,wait4,waitpid,wait,rt_sigaction 2>&1 | grep -E '(SIGCHLD|wait|sigaction)'
- 正常情况：子进程退出 → 触发
SIGCHLD→ 父进程内rt_sigaction显示已注册 handler → handler 内调用wait4()成功返回 - 异常模式（即你遇到的问题）：
SIGCHLD频繁到达，但wait4/waitpid调用极少或返回-1 ECHILD（表示无可用子进程），说明 handler 被反复触发却未真正清理 - 若看到大量
rt_sigaction(SIGCHLD, {...}, ...)重注册，说明代码中存在重复signal()或sigaction()调用，干扰了信号处理链
定位并修复常见编码缺陷
以下几类实现极易引发该问题，需重点审查父进程源码或启动脚本：
- C/C++ 程序中使用
signal(SIGCHLD, handler)后，在 handler 内未调用waitpid(-1, &status, WNOHANG)循环回收所有已退出子进程（只调一次会漏掉并发退出的多个子进程） - Shell 脚本中用
trap 'handler' CHLD，但 handler 函数内只写wait $!（仅等最后一个后台进程），未用wait -n或循环wait处理全部子进程 - Python 中用
signal.signal(signal.SIGCHLD, handler)，但 handler 内调用os.wait()而非os.waitpid(-1, os.WNOHANG)循环，或未设signal.siginterrupt(signal.SIGCHLD, False)防止中断系统调用 - Java 应用通过
ProcessBuilder启动子进程后，未在destroy()或waitFor()后主动调用getInputStream().close()和getErrorStream().close()，导致子进程残留管道阻塞，间接影响 wait 行为
