vfork死锁本质是父子进程在共享地址空间下违反约束导致的逻辑僵持：子进程未立即调用exec或_exit，致使父进程无限等待、子进程无法退出，故不产生僵尸进程。
这个问题很典型，但关键点要拎清：vfork引发的“双重死锁”，本质不是内核卡死，而是父子进程在共享地址空间下违反使用约束导致的逻辑僵持；而所谓“僵尸残留”，其实是子进程根本没机会退出——它卡在了vfork之后、exec/exit之前，连终止都做不到，更谈不上变成僵尸。
vfork死锁的真实成因
vfork要求子进程必须立即调用exec或_exit（注意是_exit，不是exit），且**绝对不能**修改任何非局部变量、不能调用除少数async-signal-safe函数外的任何库函数。一旦违反：
- 子进程若调用printf、malloc、open等，可能破坏父进程堆栈或文件描述符表，导致父进程后续执行异常甚至崩溃
- 子进程若只是sleep、while(1)或访问未声明为volatile的全局变量，会持续占用父进程的调度权——因为vfork规定父进程必须等待子进程exec/_exit后才能恢复运行
- 此时没有SIGCHLD可发，wait()永远阻塞，子进程也动不了：这就是你看到的“双重死锁”
紧急现场处置方法
死锁发生时，父子进程都处于不可中断等待状态（D状态或类似表现），常规kill无效。需从外部干预：
- 用ps -eo pid,ppid,comm,state,tty | grep -E "(D|T)"定位疑似卡住的父子进程对（子进程PPID指向父，状态非Z非R）
- 若确认是vfork卡死，唯一可靠方式是杀掉父进程：kill -9
。父进程退出后，子进程自动变为孤儿，被init收养；init会接管其生命周期，但注意：该子进程仍处于vfork挂起态，init无法唤醒它——所以最终结果是子进程随父进程一起被内核彻底清理（不是变成僵尸，而是直接消亡） - 不要尝试kill子进程：它没有独立地址空间，信号无法投递，kill命令会返回“No such process”
代码层根治要点
预防远胜于抢救。修复必须落在应用代码上：
- 立刻停用vfork：除非在极老内核或资源极度受限的嵌入式场景，且你100%确保子进程只做execve或_exit，否则一律改用fork+exec。现代Linux的fork已广泛采用写时复制（COW），性能差距可忽略
- 若坚持用vfork，子进程中只允许做三件事：设置errno、_exit()、execve()。禁止任何其他操作，包括访问全局变量（除非显式声明volatile并确保无竞态）、调用任何glibc函数
- 在fork/vfork调用后，父子进程都应检查返回值：子进程必须严格校验是否为0，父进程必须检查是否>0或-1；错误处理分支里也要避免vfork残留逻辑
为什么不会产生传统意义上的僵尸进程
真正的僵尸进程前提是子进程已成功调用exit()并进入Z状态。而vfork卡死场景中，子进程压根没走到exit那一步——它连自己的退出流程都没启动。所以你看到的不是Z状态进程，而是两个停滞的、共享内存的进程实体。它们不消耗CPU，但会阻塞父进程调度，影响系统响应性。这种状态在ps里常表现为异常的D（uninterruptible sleep）或R（但实际不运行），而非Z。
