fork、wait、exec这三个系统调用是Linux进程控制的基石。无论你是做嵌入式开发、写后台服务、维护运维脚本还是准备Linux岗位的面试都绕不开它们。这篇文章我会从最基础的概念讲起用手写C代码的方式把进程创建、回收、替换这三个核心环节彻底拆开每一段代码都给注释、给原理、给坑点。没有废话每一节都是可以直接拿去用的实操内容。适合刚接触Linux编程的新手也适合复习进程相关面试题的开发者对照查漏。1. 先搭好进程的底层认知框架1.1 进程不是程序而是运行中的上下文很多入门资料一上来就扔fork但我始终认为在写第一行fork之前得先把进程到底是什么这件事弄清楚。程序是磁盘上的二进制文件是一堆指令和数据的静态集合进程是程序被加载到内存、开始执行之后内核为它维护的一整套运行时状态。这套状态具体包括什么页表映射、文件描述符表、信号处理函数表、当前工作目录、环境变量、资源限制、累计CPU时间、进程IDPID和父进程IDPPID等等。你可以把进程理解成程序在运行中的快照 上下文。举一个生活化的例子程序就像一本菜谱静态地躺在抽屉里进程则是你照着菜谱在灶台上炒菜的全过程——火候、油温、加了哪几样调料、当前炒到第几步这些就是上下文。同一本菜谱可以开两个灶台同时炒对应同一个程序可以运行多个进程彼此互不干扰。理清这一点后面理解fork、exec就会顺畅很多。1.2 进程控制的三个核心动作创建、等待、替换Linux下的进程控制表面上看系统调用很多但归纳起来就是三个核心动作创建子进程用fork()或者更现代的posix_spawn。它让一个进程分裂成两个几乎一模一样的进程。等待子进程结束用wait()或waitpid()。父进程负责收尸回收子进程的退出状态和资源。替换进程映像用exec家族函数。它在不创建新进程的前提下把当前进程正在运行的代码替换成另一个程序PID不变但干的事完全不同。三者通常协同工作父进程先fork()一个子进程子进程内部调用exec去加载一个全新程序父进程则用wait等待子进程结束并检查它的退出状态。这就是Shell执行外部命令的底层逻辑也是所有多进程服务的基本套路。搞清楚这三件事Linux下面90%的进程相关代码你都能看懂了。下面开始逐一拆解。2. fork一次调用两次返回的魔法2.1 fork的基本行为复制当前进程先看最经典的fork代码#include stdio.h #include unistd.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork error); return 1; } else if (pid 0) { printf(我是子进程PID%d父进程PID%d\n, getpid(), getppid()); } else { printf(我是父进程PID%d子进程PID%d\n, getpid(), pid); } return 0; }编译运行后屏幕上会输出两行内容一行属于父进程一行属于子进程。这里的核心知识点是fork()调用一次却返回两次。父进程接收的返回值是子进程的PID子进程接收的返回值是0。至于谁先执行由调度器决定不要假设任何顺序。为什么是这种设计因为返回值的差异是进程区分我是父还是子的唯一途径。父进程拿到子进程PID才能在下文执行waitpid(pid)精准等待子进程拿到0则知道自己是被复制出来的那个通常会直接进入exec替换掉自己。fork成功之后子进程几乎是父进程的克隆体代码段、数据段、堆、栈、文件描述符表、环境变量、信号处理设置全部复制。但注意几个不会被复制的关键点子进程有自己的PID、自己的父进程ID即创建它的父进程、自己的挂起信号队列、自己的时间计数器。这些细节在面试里常被考记住它们比背一堆概念有用。2.2 写时复制机制fork为什么没那么贵很多初学者以为fork就是完整地把父进程的内存复制一份给子进程。如果父进程占用了2GB内存fork一次就要复制2GB这显然太浪费了。实际上的Linux实现是写时复制Copy-On-Write简称COW。fork刚完成时父子进程的物理内存页面还是同一份页表也都指向这些共享页面但被标记为只读。当任何一方尝试写入某个页面时触发缺页异常内核才把这一页真正复制一份并更新对应的页表映射。这样一来fork的开销大大降低没有写操作时几乎不复制内存只复制页表和描述进程的内核数据结构。这个机制告诉我们一个实战结论fork本身并不贵贵的是父子进程各自大量改写内存。所以先fork再exec的组合拳在性能上是非常合理的——fork几乎没有复制成本紧接着exec直接把子进程的地址空间整个替换掉前面的复制根本不会发生。这也是为什么vfork()在现代Linux上已经很少需要用了COW已经把它的优势吸收殆尽。2.3 实操用fork写出第一个多进程程序光看不练等于白看。我们写一个父进程和两个子进程并行干活的例子#include stdio.h #include unistd.h #include sys/wait.h static void do_work(const char *name, int loops) { for (int i 0; i loops; i) { printf(%s: 第%d次干活\n, name, i 1); usleep(200000); // 模拟耗时操作 } } int main(void) { pid_t pid1 fork(); if (pid1 0) { perror(fork1); return 1; } if (pid1 0) { do_work(子进程1, 3); return 0; } // 父进程继续创建第二个子进程 pid_t pid2 fork(); if (pid2 0) { perror(fork2); return 1; } if (pid2 0) { do_work(子进程2, 3); return 0; } // 父进程等待两个子进程 waitpid(pid1, NULL, 0); waitpid(pid2, NULL, 0); printf(父进程两个子进程都干完了\n); return 0; }这里面有几个值得注意的细节。第一子进程里千万不要继续调用fork去生一大堆后代除非你明确要做进程树否则容易养成混乱的习惯。第二子进程的return 0和exit(0)在这里效果类似但在更深层的代码里子进程应该用_exit()可能更安全因为它不会冲刷父进程复制过来的stdio缓冲区。第三父进程在fork之后创建的变量、打开的文件子进程看不到——因为子进程是fork那个瞬间的复制品之后两者各走各的路。3. wait与waitpid别让子进程变成僵尸3.1 僵尸进程是怎么来的先了解一个Linux进程的生命周期。子进程退出时内核并不会立刻把它的task_struct等数据全部销毁而是让它进入Z状态——僵尸态。之所以保留这些数据是因为父进程或之后的init进程需要读取子进程的退出状态码判断它到底是正常退出、被信号杀死还是被信号停止。只有父进程调用wait()或waitpid()成功回收之后僵尸进程残存的最后一点数据才会被彻底释放。如果一个父进程创建了子进程却从不调用wait子进程退出后就会一直停留在僵尸状态。僵尸进程不占CPU、不占内存但它会占用内核进程表中的槽位。如果僵尸进程积累太多进程表被填满系统就没法再创建新进程了——这是生产中非常典型的事故现场。举个例子一个常驻后台的服务程序每来一个请求就fork一个子进程处理但忘了wait。高峰期产生几百个请求就留下几百个僵尸进程。如果服务运行几年不重启进程表满后fork直接返回失败服务就卡死了。所以我平时排查线上问题时看到ps输出里成片的Z状态进程第一反应就是去检查父进程的wait逻辑。3.2 wait与waitpid的参数和对比先看最简单的wait()#include sys/wait.h pid_t wait(int *status);它阻塞当前进程直到任意一个子进程退出然后返回那个子进程的PID同时把退出状态写入status指向的变量。wait()的问题是它没法指定等谁也不知道到底有几个子进程还没退出。于是更精确的waitpid()出场了pid_t waitpid(pid_t pid, int *status, int options);pid参数的三种典型用法pid 0等待PID等于该值的特定子进程。pid -1等待任意子进程等价于wait。pid 0等待与调用进程同组的任意子进程。options参数最常用的是WNOHANG如果没有任何子进程退出立即返回0而不是阻塞。这是实现非阻塞回收、配合事件循环的标配。重点学习如何解析status。status不是简单的退出码它是一个位掩码必须用宏来解析千万别自作聪明地直接打印。我见过不少新手把status当int直接printf结果看到一串莫名其妙的数值其实那是信号编号和退出码的拼接体。推荐记得最常用的三个宏WIFEXITED(status)子进程是否正常退出通过exit或return。WEXITSTATUS(status)正常退出时拿到退出码只在WIFEXITED为真时有意义。WIFSIGNALED(status)子进程是否被信号终止。3.3 实操循环回收所有子进程如果一个父进程fork了多个子进程简单调用两次wait不一定靠谱因为你不知道子进程退出的先后顺序。最稳妥的写法是循环wait直到返回-1#include stdio.h #include unistd.h #include sys/wait.h int main(void) { for (int i 0; i 5; i) { pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { // 子进程做点事然后退出退出码和循环下标挂钩 _exit(i 1); } } // 父进程循环回收 int status; pid_t child; while ((child wait(status)) ! -1) { if (WIFEXITED(status)) { printf(子进程 %d 正常退出退出码 %d\n, child, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(子进程 %d 被信号 %d 杀死\n, child, WTERMSIG(status)); } } perror(wait); // 此时errno是ECHILD表示没有子进程了 return 0; }这段代码有个小知识点最后那个perror(wait)一定会执行因为循环退出的唯一条件就是wait返回-1而这里没有子进程时errno会被设为ECHILD。所以errnoECHILD在业务代码里不应该当成错误它是正常终止循环的条件。这也是面试里常考的细节如何判断所有子进程都已经回收完毕。4. exec家族让进程换一个程序运行4.1 exec六兄弟l、v、p、e都是什么意思exec不是一个单独的函数而是一族函数的总称标准的有六个execl、execlp、execle、execv、execvp、execv。后四个加上execvpe是GNU扩展。记忆方法就两个字字母决定参数形式。带llist参数以列表形式逐个传入最后一个必须用NULL结束。execl(/bin/ls, ls, -l, NULL)。带vvector参数以字符串数组传入。char *argv[] {ls, -l, NULL}; execv(/bin/ls, argv);带ppath表示会在环境变量PATH中自动搜索命令路径。比如execlp(ls, ls, -l, NULL)不需要写全路径。带eenviron可以自定义环境变量数组传给新程序通常和v组合成execve。这六个函数底层都归结到同一个系统调用execve()。其余五个都是它的包装。这里要特别提醒不要用execvp(ls, argv)就默认万事大吉因为带p的版本在找不到命令时会按PATH逐个目录尝试如果同时传了自定义环境变量要格外小心避免环境变量污染新程序的行为。exec家族函数有一个非常反直觉的特征它们几乎不可能返回成功。如果exec执行成功当前进程的代码、堆、栈、数据段全部被新程序替换控制流直接跳进新程序的入口永远回不到exec调用点。所以exec一旦返回了返回的必然是-1是一个失败信号。写代码时exec调用之后的那几行基本全是错误处理execl(/bin/ls, ls, -l, NULL); // 走到这里说明exec失败了 perror(execl); exit(127); // 127在shell中表示命令找不到的惯例4.2 exec的几个大坑第一个坑是路径问题。使用不带p的exec族时如果传的是相对路径比如execl(ls, ls, NULL)它会直接在当前工作目录找ls而不是去PATH里找。正确做法要么写绝对路径/bin/ls要么用execlp。第二个坑是argv和程序名的关系。Unix的传统是argv[0]通常是程序自身的名字但这个值是可以伪造的。比如你执行execl(/bin/echo, nice, hello, NULL)程序虽然跑的是echo但它看到的argv[0]是nice。很多命令行工具会根据argv[0]改变行为比如busybox就是这样这个特性既是灵活也是坑。第三个坑是文件描述符。exec成功后会关闭FD_CLOEXEC标志的文件描述符没设置该标志的描述符会被新程序继承。这会导致新程序意外持有你不希望它持有的打开文件、socket连接带来严重的安全和资源泄漏问题。实操建议很明确所有不需要继承给子进程的fd从创建那一刻就设置O_CLOEXEC或FD_CLOEXEC。比如socket()、open()带有O_CLOEXEC标志或者之后用fcntl(fd, F_SETFD, FD_CLOEXEC)。4.3 实操forkexec组合拳下面的例子模拟一个父进程指挥子进程执行外部命令的完整流程。父进程创建子进程子进程exec/bin/echo输出一段文本父进程负责回收并检查退出码#include stdio.h #include unistd.h #include sys/wait.h #include stdlib.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { // 子进程直接换程序 execl(/bin/echo, echo, hello from exec, NULL); // 如果走到这里说明exec失败了 perror(execl); _exit(127); } // 父进程等待子进程结束 int status; if (waitpid(pid, status, 0) -1) { perror(waitpid); return 1; } if (WIFEXITED(status)) { printf(子进程正常退出退出码%d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(子进程被信号%d杀死\n, WTERMSIG(status)); } return 0; }这段代码我在实际项目中反复使用几乎可以当成模板。核心要点子进程里exec失败后要_exit而不是return因为子进程可能已经改写了文件描述符、缓冲区的状态直接return可能导致父进程环境被污染。另外父进程的waitpid不要用wait()代替明确指定pid才能确定回收的是哪个子进程避免多个子进程时张冠李戴。5. 综合实战一个稳定的进程控制模板5.1 完整代码与逐步解读把上面几个知识点组合成一个稍微完整的例子父进程fork一个子进程子进程用execvp执行一个用户指定的命令父进程回收并汇报退出状态。这段代码可以直接作为写命令行工具时的骨架#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h #include string.h int run_command(char *const argv[]) { pid_t pid fork(); if (pid 0) { perror(fork); return -1; } if (pid 0) { // 子进程执行命令failure时立即退出 execvp(argv[0], argv); perror(execvp); _exit(127); } // 父进程等待 int status; if (waitpid(pid, status, 0) -1) { perror(waitpid); return -1; } if (WIFEXITED(status)) { return WEXITSTATUS(status); } else if (WIFSIGNALED(status)) { fprintf(stderr, 进程被信号 %d 终止\n, WTERMSIG(status)); return 128 WTERMSIG(status); // 模拟shell的退出码惯例 } return -1; } int main(int argc, char *argv[]) { if (argc 2) { fprintf(stderr, 用法: %s 命令 [参数...]\n, argv[0]); return 1; } // argv结构argv[1]是命令名argv[1:]是它的参数 char **cmd argv[1]; int ret run_command(cmd); printf(捕获到 [%s] 的退出码: %d\n, cmd[0], ret); return ret; }这里面有个隐藏亮点char **cmd argv[1]直接把命令行参数借给execvp用不用再造数组。因为execvp要求的就是以程序名开头、NULL结尾的argv结构而C main的argv天然就是这样的结构只是多了argv[0]是当前程序名。这种复用argv的写法简洁又不容易出错推荐给读者收藏。信号终止时返回128信号编号也是Shell的约定。比如一个进程被SIGKILL信号9杀死shell通常报137。我在脚本里处理子进程退出状态时用这个约定能跟shell行为对齐排查问题少绕很多弯。5.2 面试高频题与易错点作为经常整理面试题的人我把Linux进程控制这个主题下的高频考点列一下对着复习效率很高。fork返回值的完整语义为什么父进程收到子进程PID、子进程收到0以及如何使用返回值分流控制流。fork之后变量是否共享答案是初始相同、物理独立父子的内存是复制关系不是共享关系改一方不影响另一方。如果要共享必须用共享内存或mmap。fork与缓冲区的经典坑如果父进程在fork前已经向stdout写入了内容但没冲刷比如printf没加换行复制到子进程的缓冲区里也有一份子进程exit时会把它再输出一遍导致内容重复。我实测过的解决方法是fork前fflush(NULL)刷新所有输出流。exec成功不返回的原理地址空间已经替换原进程的返回路径不存在了。僵尸进程vs孤儿进程僵尸进程是已退出但未被wait回收的进程孤儿进程是父进程先退出而被init或子reaper收养的进程。别把两者混为一谈。wait与waitpid的WNOHANG配合如何在不阻塞的情况下查询子进程状态这是实现事件驱动服务的关键。面试答题有个通用套路先说定义再说代码层面怎么用最后说生产中遇到过什么问题。把上面每一点都配上我实际遇到过的经历比死记硬背有效得多。6. 常见问题与排查技巧实录6.1 排查僵尸进程的现场方法查僵尸进程最快的命令是ps -eo pid,ppid,stat,comm状态列里看到Z就是僵尸。或者用top命令在进程列表的S列也会看到Z。确认僵尸进程之后下一步是看它的PPID是谁。如果PPID是1init说明它的父进程已经退出init会负责回收只是有时需要点时间。如果PPID是一个正常运行的业务进程那几乎可以肯定父进程没有正确调用wait或waitpid。这时候的处理办法通常是修代码在父进程里补上wait循环如果情况紧急先把父进程重启僵尸进程会被init重新收养。其实很多服务框架已经封装好了进程回收逻辑但自己手写多进程服务时最容易漏掉的就是子进程意外退出时父进程没有及时回收。我踩过最严重的一次线上事故就是一个常驻任务进程每处理一个任务就fork一次处理完不wait半年后进程表满了新任务连fork都失败服务直接瘫痪。从那以后我写任何fork代码第一件事就是把wait循环写好甚至先写完回收逻辑再写业务逻辑。还有个隐蔽问题父进程自己没退出但也没有任何子进程时wait()会一直阻塞。所以只要不是明确的等下一次子进程退出语义我都会用waitpid(-1, status, WNOHANG)轮询。后者成为非阻塞回收的标配姿势。6.2 信号、孤儿进程与守护进程的补充最后补充三个边界场景。第一子进程被信号杀死是常态不只是崩溃。比如用户按CtrlC内核把SIGINT发给整个前台进程组所有前台子进程都会收到信号。父进程在waitpid返回后应该用WIFSIGNALED判断一下不要把被信号杀死当成异常之外的情况简单忽略。第二孤儿进程也不要害怕。父进程退出后孤儿进程会被内核送给最近的subreaper或init进程收养由收养者负责wait回收。所以孤儿进程本身不会变成僵尸真正的僵尸一定有一个还没来回收它的活着的父进程。理解这点对排查非常有用。第三守护进程的常规做法离不开fork第一次fork后子进程调用setsid()创建新会话、脱离控制终端有时会再fork一次防止重新获得终端最后chdir(/)并把标准输入输出重定向到/dev/null。虽然现在很多人用systemd的Typeforking或直接前台运行但了解这套从fork演化出来的流程能帮你理解为什么很多传统服务的启动脚本长那样。说到底进程控制的知识点拉通起来就是一条线创建时用fork换程序时用exec回收时用wait。把这条线上的每个系统调用的返回值、状态解析、错误处理都摸透你再去看任何多进程服务、Shell实现、嵌入式daemon的代码都会轻松得多。我每次带新人也都是先从这三个函数入手因为他们确实是Linux并发编程的第一道门槛跨过去了后面的线程、锁、通信才能盖得稳。