僵尸进程不消耗cpu或内存，但占用进程表项和pid，导致fork()失败；内核不自动清理，依赖父进程调用wait()；持续积累反映父进程缺陷，引发资源管理失序与运维成本上升。
僵尸进程本身不消耗CPU或内存，但它直接挑战Linux内核最基础的资源管理机制——进程表（process table）和PID分配系统。
进程表项是内核的关键有限资源
每个进程（包括已终止但未回收的僵尸）必须在内核进程表中保留一个条目，对应一个唯一的PID和完整的task_struct结构。这个结构虽小，却不可复用，直到父进程调用wait()显式释放。默认pid_max为32768，一旦僵尸数量接近该值，fork()系统调用就会失败，导致新进程无法创建——这不是性能下降，而是功能性瘫痪。
内核无法自动“清理”，只能被动等待
Linux内核设计上坚持“谁创建、谁负责”原则。僵尸不是错误状态，而是正常生命周期中的过渡态：子进程退出后，内核必须保留其退出码、运行时间等元数据，供父进程查询。它不会像内存页那样被LRU淘汰，也不会被后台线程扫描回收。init或systemd仅接管孤儿进程，对已存在却无人认领的僵尸完全不干预——这说明内核把资源释放责任严格绑定在用户态父子协作逻辑上。
资源泄漏暴露父进程的失控风险
持续积累的僵尸往往不是孤立现象，而是父进程深层缺陷的信号：
- 未注册或忽略SIGCHLD信号，导致回收路径从未触发
- 父进程处于阻塞等待、死循环或已被STOP挂起，回收逻辑永久停滞
- 父进程崩溃后残留，其子进程虽变孤儿，但若已在崩溃前退出，这些僵尸早已形成且无人处理
此时，PID耗尽只是表象；背后常伴随文件描述符泄漏、信号队列积压、定时器失效等连锁问题，反映整个服务的资源生命周期管理已失序。
可观测性与运维成本被隐性抬高
僵尸进程不体现在CPU、内存、IO等常规指标中，却迫使运维人员：
- 频繁执行ps aux | grep Z排查，而非基于真实负载决策
- 额外维护zombie_count监控规则，增加告警配置复杂度
- 在海量SIGCHLD日志中人工过滤，掩盖真正异常信号源
这种“静默型资源枯竭”，让问题发现滞后、定位困难，本质上是内核资源模型与用户态协作契约被打破后的系统性退化。
