双fork处理僵尸进程为何仍需调用wait()？二者作用有何差异？

首先把两个疑问拆开说，本质是没搞清楚双fork场景下wait()的回收对象，以及两种方案的适用场景差异。

为什么双fork的代码里父进程还是要调用wait()？ #

这里的wait()根本不是用来回收最终执行业务的孙进程的，它的回收目标是第一次fork生成的中间子进程。
看代码逻辑就能明白：第一次fork出来的直接子进程，唯一的作用就是执行第二次fork生出孙进程，做完这件事它立刻就调用exit(0)退出了。如果父进程不对这个直接子进程调用wait()，这个生命周期只有几行代码的中间子进程，反而会变成僵尸进程占着进程表项。
这个wait()的成本极低：因为中间子进程是fork完立刻退出的，wait()调用几乎瞬间就能返回，根本不会阻塞父进程后续的业务逻辑，和等待一个长时间运行的业务子进程完全不是一回事。
而双fork规避僵尸进程的核心作用，是作用在孙进程上的：中间子进程退出后，还在运行的孙进程会变成孤儿进程，自动被PID为1的init/systemd进程收养，1号进程自带自动回收已退出子进程的逻辑，孙进程后续退出时会被1号进程自动清理，完全不需要原来的父进程操心。

既然wait()能回收进程，双fork的价值是什么？ #

wait()本身确实可以避免僵尸进程，但它有非常明显的使用限制，双fork就是用来解决这些限制的：

• 如果父进程需要持续运行自身业务，直接fork出的业务子进程又是长时间运行的任务，父进程如果用阻塞式wait()等待子进程，会直接卡在wait()调用上，没法处理自己的其他逻辑，完全失去了并发的意义。
• 如果用非阻塞的waitpid()搭配WNOHANG参数做轮询回收，父进程就得额外维护子进程列表，定期触发回收逻辑，平白增加代码复杂度和运行时开销。
• 极端场景下如果fork出的子进程生命周期比父进程还长，父进程根本等不到子进程退出的时机，更不可能提前安排wait()调用，只要父进程还活着、没调用wait()，子进程退出后就会变成僵尸。
  双fork的价值就在这里：你只需要付出一次几乎无开销的wait()，回收那个立刻退出的中间子进程，后续真正跑业务的孙进程就和原父进程彻底脱钩了。原父进程该处理自己的业务就处理，不需要轮询、不需要阻塞、完全不用关心孙进程什么时候退出，从根源上省掉了后续维护子进程状态的所有成本。

下面是加了逻辑注释的示例代码：

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <sys/wait.h>

int main()
{
    pid_t pid;

    // 第一次fork：生成临时中间子进程
    pid = fork();

    if (pid == 0)
    {
        // 第二次fork：生成真正执行业务的目标进程
        pid = fork();
        if (pid == 0)
        {
            // 孙进程执行业务逻辑，此时父进程是临时中间子进程
            printf("Grandchild pid : %d\n Child pid : %d\n",
                   getpid(), getppid());
            // 中间子进程退出后，孙进程被1号进程收养，退出时自动被回收
        }
        else
        {
            // 中间子进程完成fork任务后立刻退出
            exit(0);
        }
    }
    else
    {
        // 仅回收立刻退出的中间子进程，调用瞬间返回无阻塞
        wait(NULL);
        // 后续父进程可以自由执行自身逻辑，完全不需要关心孙进程状态
        sleep(10);
    }
}

核心结论：双fork从来不是用来替代wait()的，它的本质是把需要wait()回收的对象，从「生命周期不可控的业务进程」替换成「立刻退出的临时中间进程」，用一次极低的wait()成本，换取后续完全不用托管业务进程生命周期的自由度。

内容的提问来源于stack exchange，提问作者porki