Linux fork与写时复制：进程创建原理、返回值陷阱与工程实践

1. 先把 fork 的底牌摊开：它到底做了什么事

fork 函数是 Linux 进程模型里绕不开的一个系统调用，头文件<unistd.h>，原型就一行pid_t fork(void);，参数表空的，看着特别朴素。但就是这样一行声明，撑起了整个 Unix 进程家族的繁衍机制——shell 执行一条命令靠它，Web 服务器接一个新连接靠它，守护进程化靠它，连很多看似高级的容器运行时，底层兜兜转转也还是它。我第一次认真读它，是在一个服务半夜疯狂分配内存的场景里，监控图上 RSS 曲线像楼梯一样往上叠，最后一查，问题不在业务代码，在 fork。

说人话：fork 干的事就是"把当前进程原样复印一份"。调用它的那个进程叫父进程，被复印出来的叫子进程。复印出来的东西有自己的 PID、自己的父进程号指向调用者，但内存里的变量值、打开的文件、当前工作目录、信号处理方式，统统和父进程一模一样，从 fork 返回那一行代码继续往下跑。所以你会看到同一个printf在两份进程里各打印一次，同一个for循环在两个进程里各跑一遍。

这个东西解决的核心问题是：在 Linux 里，创建一个新进程，唯一的正规途径就是复制一个已有进程，而不是凭空造一个。没有"新建一个空进程然后往里填代码"这种接口，想跑新程序？那就 fork 一份出来，再在子进程里调用 exec 家族把新程序的映像覆盖上去。这个两步走的设计，是 Unix 系操作系统最基础的骨架之一。

适合谁看：写过 C 语言、想搞明白wait为什么老是被漏掉的同学；在写服务器、跑批脚本、做嵌入式开发，被"僵尸进程"和"内存翻倍"折腾过的朋友；还有准备面试、需要把 fork 返回值、写时复制、父子进程关系串成一条线讲清楚的人。下面我按"设计思路—内核细节—返回值陷阱—动手实操—选型对比—排错"这条线，把我知道的都说一遍。

1.1 复制了哪些东西，又刻意没复制哪些

fork 出来的一瞬间，子进程拿到的是父进程用户态地址空间的一份拷贝，包括正文段、数据段、堆、栈，变量值完全同步。文件描述符表也是复制的，注意是复制"表"，不是复制"文件"——父进程 open 了 3 号 fd 指向某个文件，子进程的 3 号 fd 也指向内核里同一个打开文件描述，两边共享同一个文件偏移量。这一点新手最容易忽略：父进程读了 100 字节，子进程接着读，是从第 101 字节开始，不是从头来。

而有些东西是明确不继承的，这块容易被忽略。子进程有自己的 PID，这是必然的；父进程号变成调用者；未决信号集被清空，父进程挂起没处理的信号，子进程一个都不接；alarm()设的定时器清零，子进程的计时从头开始；fcntl加的文件记录锁不继承，因为锁的语义是绑定到进程上的；进程组和会话如果要脱离，得自己调setsid()。

还有一类是"继承但要注意"的：信号处理函数会继承，父进程把 SIGINT 的处置设成了某个自定义函数，子进程也带着这个处置，但它带不走父进程内存里那个函数的上下文状态，所以多进程程序里，子进程往往要重新设置一遍信号；环境变量、umask、当前工作目录、资源限制setrlimit也都是继承的。我见过有服务在 fork 之后不停地往同一个日志里写，就是没意识到 umask 和工作目录是跟着走的。

提醒：写多进程程序时，fork 之后的前几行代码里，把"我期望子进程是什么状态"这件事显式地重新声明一遍，比依赖继承靠谱得多。

1.2 为什么设计成"复制"而不是"从零创建"

这个设计乍看很浪费——我想跑个ls，凭什么要先把整个 shell 的内存复制一遍？答案藏在"简单"两个字里。如果提供"创建一个空进程"的接口，那这个空进程要配什么内存布局、什么文件描述符表、什么信号状态，全得由调用者填，接口参数会爆炸，内核里也要维护两套完全不同的进程初始化路径。

而"复制现有进程"的思路，让内核只需要一条路径：copy_process()。所有新进程都从复制诞生，初始化逻辑统一，父子关系天然建立，权限继承、环境继承全都免费获得。这也是为什么 fork 之后立刻 exec 的写法虽然看起来"浪费地复制了一遍内存"，实际却非常快——因为复制是延迟的，这就是下一节要说的写时复制。

另一个隐性好处是编程模型上的：fork 之后，子进程"记得"父进程做过的一切，包括已经打开的日志文件、已经建立的数据库连接、已经加载的配置。这个特性在守护进程化、并行任务分发里非常好用。当然它也是双刃剑，连接池被复制成两份，父子同时用同一个 socket 发请求，服务端看到的就是乱序的字节流，这个坑后面会细说。

1.3 一个真实的观察：绝大多数 fork 问题都不是 fork 本身的错

我带过几个新人，初学阶段普遍有一个误区，觉得 fork 是"高级用法"，出了问题就往 fork 身上推。实际上我处理过的案例里，九成以上错在调用者对语义理解不到位，而不是内核实现有毛病：

• 父进程忘了wait，子进程退出后变成僵尸，占着进程表项不放；
• 子进程里没处理好共享的文件描述符，两边同时写同一个日志，内容交错；
• fork 之前printf没加换行或没fflush，父子各输出一份，看到重复日志以为程序跑了两遍；
• 多线程程序里调 fork，子进程只有调用线程存活，但它去抢一把已经被别的线程持有的锁，直接死锁。

所以我的建议很明确：学 fork，别只背返回值含义，要把"哪些资源是共享的、哪些是复制的、什么时候会真正分离"这三件事想透。想透了，上面这些坑一个都踩不到。

2. 写时复制：fork 的性能底气到底从哪来

很多人第一次看到 fork 的语义会本能地皱眉：复制整个地址空间，那几百兆内存的程序 fork 一下不得卡半天？早期确实是这样，那时候 fork 是实打实的内存拷贝。现代 Linux 用的是写时复制（Copy-On-Write，简称 COW），fork 调用返回得极快，因为它压根没复制内存内容，只复制了"地址映射关系"。

这个优化是 fork 能大规模使用的前提。理解 COW，你就能看懂两件事：为什么 fork 后立刻 exec 的写法并不慢；为什么父进程或子进程一旦开始大范围改写内存，RSS 会突然往上涨。

2.1 页表复制与只读标记

Linux 用分页管理内存，每个进程有一张页表，记录"虚拟地址 → 物理页框"的映射。fork 时内核做的核心动作是：给子进程新建一张页表，把父进程的页表项逐条复制过去，但把父子双方这些页表项的写权限位统统清掉，标记为只读。同时给每个物理页框的引用计数加 1，表示"这一页现在有两个使用者"。

到这里，父子进程的虚拟地址都指向同一批物理页，读操作一切正常，谁都不受影响，所以访问速度没有变化。真正的复制发生在某一方尝试写入的时候：CPU 发现要写的页是只读的，触发一个缺页异常，内核的缺页处理程序进去一看，发现这是 COW 页、引用计数大于 1，于是老老实实分配一个新物理页，把原页内容拷贝过去，更新写入方的页表项指向新页并恢复写权限，然后返回让指令重试。这一页从此就专属某一方了，父子正式分家。

关键点在于：分家是逐页发生的，谁写谁分，写多少分多少。子进程如果只是读一遍父进程的数据然后 exec 掉，那一页都不会被复制，开销几乎为零。

2.2 引用计数减少与物理页回收

有复制就有回收。当某一方进程退出，或者 exec 覆盖掉整个地址空间时，内核会把它页表里所有页的引用计数减 1，减到 0 的才真正释放回伙伴系统。这个机制保证了内存不会被重复计算，也解释了为什么free出来的可用内存，有时要等子进程退出之后才明显回升。

这里有个我实打实踩过的坑：一个后台服务定期 fork 子进程做一批数据处理，子进程处理完就退出。看监控时发现内存曲线一直缓慢上扬，重启后回落。排查下来不是内存泄漏，是 COW 的延迟效应加上父进程自己的内存池在高水位没释放。往深了看，父进程的堆里堆了大量长期存活的对象，每次 fork 子进程都会让这些页的引用计数加一，子进程只要碰了其中几页就触发复制，页表项本身也是内存开销。父进程的虚拟地址越大，每次 fork 复制页表的成本就越高，这个成本是 O(页表项数量)，不是零。

2.3 算一笔账：fork 到底花多长时间

拿个典型数值估算一下。假设父进程虚拟地址空间 1 GB，页大小 4 KB，那就是约 26 万个页，页表项按 8 字节算，光页表就 2 MB 左右，fork 时需要复制这些页表项。现代服务器上复制 2 MB 连续内存的耗时在几十微秒量级，加上内核里创建task_struct、复制文件描述符表、建立父子链表的固定开销，一次 fork 的实测耗时通常落在几十微秒到一两百微秒之间。

对比一下"复制 1 GB 数据"：哪怕按 10 GB/s 的内存带宽算，也要 100 毫秒。这就是 COW 带来的三个数量级的差距，也是为什么"fork + exec"这个看起来笨拙的组合能一直活到今天。

但如果你的程序 fork 完不 exec，而是父子同时跑业务逻辑，那情况就变了。父子一旦各自开始写，被写到的页就开始复制，物理内存消耗会往"父进程内存 + 子进程实际写入量"靠拢。有次我压测一个图像处理服务，每个请求 fork 一个子进程去解码大图，并发一上来机器直接 OOM。原因就是子进程解码时疯狂写内存，几乎把所有 COW 页都复制了一遍，等于每个请求都真的复制了一份父进程的大堆内存。后来改成预创建进程池，问题才消掉。

心得：fork 的性能假设只在"子进程很快 exec 或者几乎不写内存"时成立。子进程要大量写数据，就得掂量一下是不是该换成进程池或者线程池。

3. 返回值：一次调用、两次返回的玄机与陷阱

fork 最反直觉的地方就在这儿：它是唯一一个"一次调用、两次返回"的函数。父进程从 fork 返回一次，子进程也从 fork 返回一次，两者各自往下执行，但返回值的含义不同。这个设计很巧妙，也很容易写错。

3.1 三种返回值的准确含义

标准里写得很清楚：

失败时常见的 errno 有三个：EAGAIN，说明进程数或线程数达到上限，或者调用者的 RLIMIT_NPROC 用完了；ENOMEM，内核内存不足，分配task_struct或页表失败；ENOSYS，当前平台根本不支持 fork，某些精简内核或特殊运行环境会遇到。这三种里，EAGAIN在生产环境最常见，通常是系统级参数kernel.pid_max或者 systemd 给服务设的TasksMax卡住了。

为什么子进程返回 0 而不是它自己的 PID？因为子进程要拿到自己的 PID，一句getpid()就够了，不需要 fork 告诉它；但父进程管理一堆子进程时，必须知道每个子进程的编号，才能waitpid精确回收。这个不对称设计是刻意的：信息只给需要的人。

3.2 正确的判断顺序长什么样

新手常犯的错是先判断pid == getpid()，或者把if (pid > 0)写在if (pid == 0)后面。正确的模板我建议直接背下来：

pid_t pid = fork(); if (pid < 0) { perror("fork"); return -1; /* 失败路径，父进程继续 */ } else if (pid == 0) { /* 子进程分支：这里 getpid() 是自己，getppid() 是父进程 */ child_work(); _exit(0); /* 子进程用 _exit，别用 exit */ } else { /* 父进程分支：pid 就是子进程的编号 */ parent_work(pid); }

两个细节值得掰开说。第一，子进程结束用_exit()而不是exit()。exit()会刷 stdio 缓冲区、执行atexit注册的函数，而那个缓冲区是从父进程复制过来的，里面可能有父进程还没写出去的数据，子进程一刷就多写一份。_exit()直接走内核的退出路径，不做这些用户态收尾。第二，失败分支一定要处理，perror之后要决定是继续跑还是退出，我在线上见过 fork 失败但代码当成功往下走，结果子进程分支永远不执行、父进程还在等一个不存在的子进程。

3.3 父子谁先跑？别做任何假设

这个问题问得最多：fork 之后是父进程先执行还是子进程先执行？答案是：调度器说了算，理论上两者都有可能，实际表现取决于内核版本、CPU 核数、系统负载。老版本 Linux 倾向于让子进程先跑（为了让 exec 尽快完成，减少 COW 复制），新版本在 CFS 调度器下更倾向于让父进程先跑（为了尽早填满 CPU）。

所以任何依赖顺序的代码都是错的。比如：

int flag = 0; pid_t pid = fork(); if (pid == 0) { flag = 1; /* 只改子进程自己的副本 */ } if (flag == 1) { /* 父进程永远进不来，因为 flag 是各自独立的副本 */ }

这个例子里父子各有一份flag，不管谁先跑，父进程看到的永远是 0。要在进程间传递状态，得用管道、共享内存、信号或者文件，普通变量不行。这条规律看着基础，但每年都有人栽在上面，尤其是从多线程思维切过来的人，会下意识觉得"子进程改了父进程应该能看到"。

真需要顺序控制的时候，用管道做同步最省事：父进程先写一个字节点进去，子进程read阻塞等着，读到才继续，天然形成"父 → 子"的顺序；反过来也能做"子 → 父"。

4. 手把手实操：从最小例子到批量进程管理

理论说完，上手跑一遍才算数。这一节我给几个可以直接编译运行的示例，每个都配着我实际调试时记下的现象和解释，你可以照抄，也可以改成自己的场景。

4.1 最小示例：看清两次返回

先写个最短的，把父子进程的 PID 关系打出来：

#include <stdio.h> #include <unistd.h> #include <sys/types.h> #include <sys/wait.h> int main(void) { pid_t pid = fork(); if (pid < 0) { perror("fork"); return 1; } else if (pid == 0) { printf("child : pid=%d, ppid=%d, fork() returned 0\n", getpid(), getppid()); _exit(0); } else { printf("parent: pid=%d, fork() returned %d\n", getpid(), pid); waitpid(pid, NULL, 0); } return 0; }

编译命令很朴素，gcc -Wall -O0 -o forkdemo forkdemo.c，跑./forkdemo你会看到两行输出。子进程打印的ppid就是父进程的pid，父进程打印的返回值恰好等于子进程的pid，这两组数字对上了，说明你对父子关系的理解就没跑偏。

有个小实验很能说明问题：把waitpid那行注释掉再跑，你会发现终端提示符有时会先于子进程输出出现，因为父进程先退出了，子进程被系统托管。这时候子进程的ppid会变成 1 或者某个更上层的进程，具体取决于你机器上的初始化进程是谁。这个小现象直观展示了"孤儿进程"是怎么产生的。

4.2 缓冲区复制：那个经典的"输出两遍"

这个坑几乎所有人都踩过：

#include <stdio.h> #include <unistd.h> int main(void) { printf("hello"); /* 注意：没有 \n，也没有 fflush */ fork(); return 0; }

按重定向到文件跑./bufdemo > out.txt，out.txt里是hellohello。原因很明确：printf写到终端时是行缓冲，遇到换行就刷；但重定向到文件时变成全缓冲，hello只是躺在了用户态的 stdio 缓冲区里没交出去。fork 把这整块缓冲区复制了一份，父子进程退出时各自exit()刷一次，于是落盘两份。

修法有三种，按场景选：写完立刻fflush(stdout)；给字符串加\n让它触发行缓冲（但重定向场景不可靠）；子进程分支里调用_exit()绕开 stdio 清理。我一般推荐最后一种配合显式fflush，两条保险一起上。

这个问题在日志系统里杀伤力更大。父子进程都用fprintf(log_fp, ...)往同一个FILE*写，如果这个FILE*是从父进程继承来的，两边共享同一个文件偏移量，但各有各的用户态缓冲区，输出极可能交织成半行半行的碎片。稳妥做法是：子进程里别复用父进程的日志流，重新fopen一个，或者干脆用write()直接写不带缓冲。

4.3 文件描述符继承：共享偏移量这件事要当心

写段代码验证一下"共享偏移量"这个语义，比看十遍文档都管用：

#include <fcntl.h> #include <unistd.h> #include <stdio.h> #include <sys/wait.h> int main(void) { int fd = open("shared.txt", O_RDWR | O_CREAT | O_TRUNC, 0644); write(fd, "ABCDEFGHIJ", 10); pid_t pid = fork(); if (pid == 0) { char c; lseek(fd, 0, SEEK_SET); read(fd, &c, 1); printf("child read: %c\n", c); /* A */ _exit(0); } waitpid(pid, NULL, 0); char c; read(fd, &c, 1); /* 从偏移 1 读，得到 B */ printf("parent read: %c\n", c); close(fd); return 0; }

父进程读到B而不是A，说明两边确实共享文件偏移。但如果把上面那行lseek挪到 fork 之前，父子读的就都是A了——偏移是由两边共同推进的，谁 lseek 都会影响另一方。

这个语义在父子进程"分工读同一个文件"时很有用，在"父子各自独立处理同一批数据"时就是灾难。我建议的做法是：fork 前把不需要共享的 fd 关掉，或者给子进程用dup复制一份独立的描述，再或者干脆把每个子进程的输入全部走管道喂进去，别让它们去碰同一个文件对象。

顺带说一个相关的问题：孤儿 fd。父进程 open 了一堆连接然后 fork，子进程跑完不关、直接_exit，内核在进程退出时会关掉这些 fd，引用计数减到零的文件才真正释放，看起来不会有泄漏。但如果父进程长期持有这些 fd，子进程又多，那连接本身是一直被占着的。所以我的习惯是：子进程里显式close掉所有它用不上的 fd，干净利落。

4.4 批量 fork：waitpid 与超时的正确姿势

真正干活的时候往往要 fork 一批。简单的 for 循环容易写出问题，我一般这么写：

#include <stdio.h> #include <unistd.h> #include <sys/wait.h> #include <errno.h> #define WORKERS 8 static int do_work(int idx) { return idx * 2; } int main(void) { pid_t pids[WORKERS]; int i, status; for (i = 0; i < WORKERS; i++) { pid_t pid = fork(); if (pid < 0) { perror("fork"); pids[i] = -1; continue; } if (pid == 0) { _exit(do_work(i) & 0xff); /* 退出码只有低 8 位有效 */ } pids[i] = pid; } for (i = 0; i < WORKERS; i++) { if (pids[i] <= 0) continue; pid_t r = waitpid(pids[i], &status, 0); if (r < 0) { fprintf(stderr, "waitpid %d failed: %d\n", pids[i], errno); continue; } if (WIFEXITED(status)) printf("child %d exited with %d\n", pids[i], WEXITSTATUS(status)); else if (WIFSIGNALED(status)) printf("child %d killed by signal %d\n", pids[i], WTERMSIG(status)); } return 0; }

几个要点值得强调。退出码只有低 8 位能传到父进程，你return 256和return 0在父进程看来完全一样，要传更大的结果，用管道传。waitpid必须处理返回值小于零的情况，-1加 errno 为ECHILD说明这个子进程已经被收走了，是正常现象，别当错误抛。还有一点，如果业务上不能无限等子进程，用WNOHANG轮询配合超时，超时之后再上SIGKILL，别让父进程卡死在waitpid上。

批量 fork 还有一个老问题：如果 fork 失败了一半，前面已经 fork 出去的怎么收场？我的处理是记录每个成功的 PID，失败就标记 -1 继续往下走，最后统一回收，同时把整体结果置为失败。别在失败时立刻return——那样前面跑着的子进程就成了没人管的孤儿，虽然最终会被托管回收，但业务上的日志和资源清理全乱套。

5. fork、vfork、clone、posix_spawn 到底怎么选

标题是 fork，但真到工程里，你手边其实有好几个选项。把它们摆在一起对比，选型才不慌。

5.1 四者能力对照

vfork现在基本属于历史遗留。它当初是为了省掉 fork 的页表复制开销，让子进程先借用父进程的地址空间跑，直到 exec 或退出才还回去。代价是共享期间父进程被挂起，而且子进程绝对不能修改任何数据——包括调用printf这种会动 stdio 缓冲区的函数。我强烈建议新代码直接忽略它，用posix_spawn替代它原本的用途。

clone是底层更通用的接口，fork和线程创建在 glibc 里最终都落到它身上。你能通过CLONE_VM、CLONE_FILES、CLONE_NEWPID之类的标志精确控制共享哪些资源。容器运行时创建新的 PID、网络、挂载命名空间，靠的就是它。但它不适合日常业务代码直接调，参数一旦搞错，进程状态会很诡异。

posix_spawn是最省心的"启动一个外部程序"方案。它在内部大概率还是 fork+exec（或者更高效的实现），但对调用者屏蔽了细节，还顺带处理了一些 fork 在多线程进程里的危险情况。要跑一个git、ffmpeg或者别的外部命令，用它比手搓 fork+exec 更稳妥。

5.2 我的选型判断顺序

实际决策时我按这个顺序问自己：

第一问，我要跑的是不是"另一个可执行文件"？是的话优先posix_spawn，代码短、出错少。第二问，我要的是不是一个独立的进程去做某件已经在当前程序里实现的事？是的话用fork，配合好wait和 fd 清理。第三问，我是不是在做线程、命名空间或者需要精细控制共享资源？那才轮到clone。vfork我一律不选。

还有一个容易被忽略的维度：fork 在多线程程序里是有危险的。POSIX 规定，多线程进程 fork 之后，子进程里只存在调用 fork 的那个线程，其他线程全部消失。问题在于，如果其他线程当时正好持有某个锁（比如 malloc 内部的分段锁），这个锁在子进程里就成了永远解不开的死锁状态——持有者已经不在了。子进程一旦调用malloc，就会卡在等锁上。所以多线程程序里 fork 之后，子进程能做且仅能做的事，是一小撮 async-signal-safe 函数，理想情况是直接 exec。这也是posix_spawn被推出来的重要原因，它内部会处理好这些细节。

5.3 fork 与 exec 的配合节奏

正经的"启动新程序"流程是这样的：父进程 fork → 子进程里先做 fd 重定向（dup2把管道接到 0/1/2）→ 用execvp换成新程序 → 如果 exec 成功，进程映像被替换，永远不会返回；exec 失败才返回，此时子进程用_exit(127)退出，父进程通过退出码 127 判断"启动失败"。

这里有三个必做的动作，少一个都可能出问题。第一，exec之前关掉所有不需要的 fd，尤其是监听 socket，否则新程序会莫名其妙继承一个监听端口，下次重启时报"端口被占用"。第二，dup2之后记得关掉原始的 fd，避免泄漏。第三，父进程必须wait，否则子进程退出成僵尸。这三条我写在团队的代码规范里，新人第一次写都能踩全。

6. 常见问题与排查实录：那些年我踩过的坑

理论和示例都讲完了，最后这块才是我觉得最有价值的——真实环境里出问题时的现象、定位手段和修法。

6.1 问题速查表

6.2 定位手段：三个命令解决八成问题

排查进程问题，我手边常备三条命令，按顺序用基本能锁定方向。

第一条，ps -eo pid,ppid,stat,comm,args | grep 你的程序名，重点是STAT这一列。看到Z就是僵尸，说明子进程已经退出但父进程没回收；看到S是睡眠，R是运行，D是不可中断睡眠（通常是卡在 IO 上，这种最难搞，kill -9都杀不掉）。

第二条，ls /proc/<pid>/fd | wc -l，配合ls -l /proc/<pid>/fd看具体指向。排查"子进程继承了不该继承的 fd"时，这招一抓一个准。我遇到过子进程持着数据库连接不放导致连接数打满的事，就是这么定位的。

第三条，cat /proc/<pid>/status，重点看VmRSS、Threads、SigQ。Threads能告诉你有没有意外的线程残留，VmRSS配合时间序列能看出 COW 复制的规模。

再往下就得靠strace -f -e trace=process,desc跟踪系统调用了，-f表示跟子进程，你就能清晰看到 fork、exec、wait 的完整时序。有一次某服务启动特别慢，我用strace -f -T一跟，发现 fork 之后子进程卡在 exec 前几百毫秒，原因是 exec 前的close循环遍历了几万个 fd，每次都是系统调用。改成按实际打开的最大 fd 遍历，启动时间立刻掉下来。

6.3 三条我总结出来的硬经验

第一条，fork 之后的第一件事，永远是把子进程的处境明确下来。关掉不需要的 fd、重设信号处置、清掉父进程遗留的缓冲区、断开不该共享的连接。别指望"应该没事"，继承来的状态比你想象的多。

第二条，子进程的退出路径只走_exit或者 exec，中间不要有别的分支。我见过在子进程里写exit(0)然后触发atexit函数，那个函数去操作父进程留下的全局链表，直接把程序搞崩。子进程的代码越短越好，一行_exit最干净。

第三条，父进程必须有兜底回收。哪怕业务逻辑写得再完美，异常退出、信号杀死这些情况总会发生。我的做法是装一个 SIGCHLD 处理函数，里面循环waitpid(-1, NULL, WNOHANG)把所有已退出的子进程收掉，主逻辑里该waitpid的地方照常waitpid，收到的返回是ECHILD就算了。双保险，跑一年也不会积累僵尸。

还有个小技巧：调试 fork 相关问题时，在父子进程各自的输出里都带上getpid()，一眼就能分清是哪份打印的。比用不同颜色或者加前缀靠谱得多，尤其是日志被重定向到文件的时候。

关于 fork 这件事，我个人最深的一点体会是：它简单到只有一行声明，却把进程管理里最复杂的那部分——资源隔离与共享的边界——全部暴露给了使用者。用得好，它是一个几乎零成本的并行手段；用得糙，它就是僵尸进程、内存翻倍和莫名死锁的源头。真正把语义吃透之后你会发现，大部分问题在写下fork()那一行之前就已经决定了。