Linux进程编程入门：fork、exec与wait全解析

做Linux系统编程的都知道多任务编程是整个领域的分水岭——前面的文件I/O、内存管理本质上还是在单线叙事里打转到了多任务这里程序开始真正地分裂和并行。这篇是系列第四弹我先从最基础的进程概念和经典的三件套fork、exec、wait展开把这几个点吃透了后面的线程、同步、通信才接得住。内容适合已经会写基本C程序、但对进程跨着门槛的读者跟着代码跑一遍比自己闷头啃APUE有效率得多。1. 程序和进程差的不只是一个活字很多人学Linux系统编程第一个绕不过去的概念就是进程但说实在的教材里定义我背得滚瓜烂熟真到程序里还是会混淆。这里我直接给一个比较好记的区分方式程序是静态的进程是动态的。程序就是你磁盘上那个ELF格式的二进制文件比如你编译出来的a.out它躺在那儿不会自己跑不占CPU简单说就是一堆指令和数据的集合。而进程是程序被内核加载到内存之后、开始执行的那一整套运行环境。同一个程序可以同时跑出多个进程每个进程都拥有自己独立的地址空间、文件描述符表、信号处理方式、当前目录等等一堆私有财产。进程在Linux内核里是靠一个叫task_struct的结构体来管理的这个结构体非常庞大里面什么都有进程IDPID、父进程IDPPID、状态、退出码、打开的文件、挂起的信号、CPU的寄存器上下文……可以说内核脑子里装着的每个进程究竟是啥情况全都在这一个结构体里。我们平时用ps -ef或者top看到的那些信息很多都是从这块结构里透出来的。进程有几个基本状态在ps输出的STAT列里能看到状态标志含义运行R正在运行或者处于可运行队列中睡眠可中断S正在等待某个事件或资源可以被信号唤醒睡眠不可中断D通常在等待I/O无法被信号打断kill不掉停止T被暂停比如收到SIGSTOP僵尸Z进程已退出但父进程还没回收它的退出状态退出X已经被回收马上要从进程表里抹掉了我见过不少初学者把D状态当成死锁拿着kill -9去杀结果发现纹丝不动然后怀疑机器坏了。实际上D状态一般出现在等待磁盘I/O这类内核态操作上不是病等I/O完成自然就醒了。另外强调一点进程在Linux里组成的结构是树状的。所有进程往上追最终的祖先都是systemdPID为1。每个进程都可以通过getppid()问自己爸爸是谁也可以用pstree拿一张整棵进程树来看这对后面排查子进程哪去了这类问题特别有用。2. fork()一场分身术背后的诸多讲究多任务编程的起点几乎毫无悬念地落在fork()身上。fork()是UNIX系统里创建进程的正统方式Linux继承了这个设计它的作用一句话就能概括以调用进程为模板创建一个几乎完全一样的子进程。#include stdio.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { perror(fork error); return -1; } else if (pid 0) { // 子进程 printf(我是子进程PID%d我爸是%d\n, getpid(), getppid()); } else { // 父进程 printf(我是父进程PID%d我儿子是%d\n, getpid(), pid); } return 0; }这段代码是每个学Linux进程的人都跑过的但这里其实隐藏着一个违背直觉的点printf居然被打印了两次。很多人第一次看到输出结果的时候都愣了——代码里明明只写了一句printf怎么能出来两行这就是fork()的经典玄机调用一次返回两次。父进程调用fork后系统复制出一个子进程然后把控制权分别交回两个进程——父进程那边拿到的是子进程的PID大于0子进程那边拿到的是0。严格来说printf那行代码本身并不存在执行两次的说法而是存在着两份进程各自都在执行各自的这一行代码只是各自的判断分支不同罢了。理解了这个返回值设计才能理解父进程和子进程后续怎么协作。父进程拿到子进程的PID才知道自己生的是谁子进程拿到0是它确认自己身份的方式。如果fork失败返回-1通常是因为进程数达到系统上限或者内存不足实测中倒也少见但错误处理必须写。再往深里说一层fork出来之后子进程是不是完整复制了父进程的所有代码和数据早期UNIX确实是这么干的直接把父进程的地址空间整个复制一遍但代价太高了。Linux现在的做法是写时拷贝Copy-On-WriteCOW——fork瞬间子进程并不是真的复制全部内存而是复用父进程的物理内存页同时把这些页标记为只读。无论父进程还是子进程谁先尝试写入谁才会真正拷贝一份属于自己的页面。这一设计极大的提升了fork的效率也让forkexec的组合拳成为可能。不过写时拷贝救得了内存救不了缓冲区。有个坑我踩过一次至今记忆犹新父进程在fork之前用printf打了一行数据没加换行符也没fflush紧接着就fork了。结果这行数据被打印了两遍。因为标准I/O库是带缓冲区的printf先写进用户空间的缓冲fork复制了整个进程的内存缓冲区里的内容也跟着变成两份最终刷新时自然输出两次。所以凡是要fork的程序前面的打印要么带\n要么显式fflush(stdout)否则就要面对这种让人挠头的输出重复问题。另外还有一个容易被忽略的事实fork之后父子进程谁先执行是不确定的。不要写任何依赖执行顺序的程序现代多核环境下调度器随便一个切换就能让先后关系大变。如果需要协调就得靠wait、信号量这些同步机制这正好是后面要聊的内容。3. exec系列给新进程换上新节目单fork能造出一个几乎和父进程一模一样的子进程但这个一模一样在多数场景下非常鸡肋——我创建子进程不是为了让它把我正在跑的逻辑再跑一遍而是希望它去执行另外一个程序。这个时候就要用到exec系列函数了。先记住一个核心结论exec系列函数成功之后当前进程的地址空间会被新的程序映像整体替换但进程的PID不变。这句话翻译一下调用exec进程它自己的皮囊PID、文件描述符等资源没换但里面跑的程序换人了。就好比同一辆出租车司机因为换班从A师傅换成了B师傅车牌还是那个车牌。exec家族一共六兄弟名字各不相同记忆法也很简单看字母后缀函数后缀含义示例execll list参数以列表形式逐个传入execl(/bin/ls, ls, -l, NULL)execvv vector参数放进指针数组execv(/bin/ls, argv)execlel e列表形式传参同时传环境变量execle(/bin/ls, ls, -l, NULL, envp)execvpv pp PATH自动去PATH环境变量里搜命令execvp(ls, argv)execlpl p列表形式 PATH搜索execlp(ls, ls, -l, NULL)最实用的是execlp和execvp因为带p的在传参时不用写全路径它会自动沿着PATH环境变量去查找可执行文件写起来像在shell里直接敲命令省心不少。看一段实际用法#include stdio.h #include unistd.h #include sys/wait.h int main() { pid_t pid fork(); if (pid 0) { perror(fork error); return -1; } else if (pid 0) { // 子进程去执行ls父进程继续跑自己的逻辑 execlp(ls, ls, -l, NULL); perror(execlp error); return -1; } else { wait(NULL); printf(子进程跑完了\n); } return 0; }这个模式就是Linux下最经典的fork exec wait三段论fork生出一个子进程子进程里用exec换成新程序父进程在wait处等着。shell本身其实就是用这个模式不断启动外部命令的。有个细节值得注意exec成功的时候调用进程不会返回。也就是说execlp后面的代码不会被执行因为地址空间已经换掉了看不到这一行了。只有当exec本身失败比如路径不存在、没有权限时它才返回-1这个时候后面的perror才派得上用场。所以写代码时要习惯性地在exec调用后补一行错误处理否则一旦exec失败子进程可能就静默地崩掉了——那是最难排查的bug之一。另外exec虽然换了程序但进程继承的某些运行时属性还留着比如当前工作目录、文件描述符、信号处理方式、环境变量如果没显式指定的话。这意味着子进程里某个已经打开的fd在exec之后的新程序里依然是打开的。这个行为有时候是特性有时候是隐患——比如父进程打开了某个日志文件子进程exec后的新程序如果不小心把这个fd当普通fd折腾就可能写崩日志内容。稳健的做法是在fork出来的子进程里、exec之前把不需要的fd一个一个close掉或者用fcntl给fd加上FD_CLOEXEC标记让内核在exec时自动关上。4. wait/waitpid给子进程体面收尸fork和exec都聊完了串起整个流程的最后一环是wait。我先说一个让无数Linux新手摸不着头脑的现象为什么子进程退出了ps里还在状态还是Z答案很简单**子进程退出时它的绝大部分资源内存、文件等都会被内核回收但PCB上还留着一条记录包括进程PID、退出状态、消耗的CPU时间等。这条记录要等着父进程来取父进程取走了这条记录才真正消失。**子进程在已经死了、但记录没被取走的这个中间态就是僵尸状态。父进程取走退出状态的这个动作就是wait做的事。如果用更惨一点的比喻来说子进程死了但没人来收尸尸体就留在停尸房里占着位置。僵尸进程不占CPU也不占内存大头但它会站着PID而PID是稀缺资源。系统里僵尸进程攒多了PID耗尽到时候连新进程都创建不出来那是真正意义上的死机前兆。wait的标准用法#include sys/wait.h #include stdio.h #include stdlib.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { perror(fork error); return -1; } else if (pid 0) { exit(42); // 子进程主动退出并带上退出码42 } else { int status; wait(status); // 阻塞在这里等子进程退出 if (WIFEXITED(status)) { printf(儿子正常退出退出码是%d\n, WEXITSTATUS(status)); } } return 0; }wait能拿到子进程的退出状态而这个状态被压缩在一个int里需要借助宏来解析WIFEXITED(status)判断子进程是否正常退出正常return或exitWEXITSTATUS(status)取具体的退出码WIFSIGNALED(status)判断是不是被信号干掉的WTERMSIG(status)拿到那个信号的编号。这些宏看着刻板但是在排查程序到底怎么死的时特别有用。wait有个局限一次只能回收一个子进程。如果你连续fork了好几个儿子就要用循环waitwhile (wait(NULL) 0);问题在于这个循环在没有任何存活子进程时会返回-1循环结束条件要写好。更灵活的方式是用waitpid它的签名是pid_t waitpid(pid_t pid, int *status, int options);参数可以精细控制pid指定要等的子进程PID填-1表示等任意一个子进程options填WNOHANG可以变成非阻塞——如果没有子进程退出立即返回0而不是死等。配合循环能实现先处理别的事回头再看有没有退出的子进程的效果。多进程编程里一个常见的脏活就是父进程搞了一堆子进程并行干活每次只wait一个但wait等人时又说不准哪个先退处理起来乱。用waitpid的第二个参数干脆可以不关心顺序谁先退出来谁先被收。真正干活时我一般习惯写一个循环反复调用waitpid(-1, status, 0)一直收到返回-1为止。这里还想提一个很多人没意识到的细节**父进程完全不wait比父进程wait了但晚一些后果不一样。**前者会让子进程变成僵尸等着父进程死了之后才被init进程PID为1收养回收后者是正常的收尸流程资源能及时释放。生产环境里那种跑几天进程数突然爆炸的bug十有八九是某个父进程fork了子进程但在某个分支上忘了wait。5. 一个稍具实战感的demo并行任务分发与回收前面几节的知识点单独拿出来都能背但组合到一起时新手经常会翻车——最常见的就是在一个for循环里fork了几次结果子进程自己没有break把父进程的for循环也跟着跑了一遍于是子子孙孙无限繁衍下去场面一度失控。这种fork炸弹前兆本质上是没搞懂fork之后父进程和子进程各自保留了一份自己的代码执行现场子进程会从fork的位置继续往下走。下面这个demo把「批量fork子进程 → 父进程等全部回收」这个常用模式完整写了出来。场景很简单有一个目录里有一堆文件要对每个文件做个模拟处理这里偷懒只打印一行把任务平分给多个子进程并行做最后父进程统计总耗时。#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h #define TASK_NUM 8 #define WORKER_NUM 4 void do_work(int task_id) { printf(子进程 %d 正在处理任务 %d\n, getpid(), task_id); usleep(200000); // 模拟耗时操作 } int main() { int i; pid_t children[WORKER_NUM]; int task_per_worker TASK_NUM / WORKER_NUM; for (i 0; i WORKER_NUM; i) { pid_t pid fork(); if (pid 0) { perror(fork error); exit(1); } else if (pid 0) { // 子进程只干自己的那一份活干完就退绝不回去继续fork int start i * task_per_worker; int end start task_per_worker; for (int t start; t end; t) { do_work(t); } exit(0); } else { children[i] pid; } } // 父进程统一回收注意要用循环wait一次回收一个 int done 0; while (wait(NULL) 0) { done; } printf(所有任务处理完毕共回收 %d 个子进程\n, done); return 0; }运行之后你会发现4个子进程各自打印两条正在处理任务的信息四条输出还可能交叠在一起这是多进程并行时的正常现象——多个进程同时在写同一个终端谁抢到打印机会完全是随机的。这里特别强调一点fork循环里的break/exit一定要安排明白。上面代码的子进程分支里直接exit(0)这样它不会回到for循环里去继续fork下一个子进程而是干完活直接退场。如果漏了这层子进程就会把i之后的循环接着跑于是第二层就出现2个进程、第三层4个……最终子孙满堂这是搞fork的人最容易踩的地雷。再者wait的返回值要处理对。父进程wait到-1才算收完while(wait(NULL) 0)这个写法在子进程全部退完之后必然退出——因为wait返回-1了。但如果你混用了非阻塞的waitpid那就要额外小心区分没子进程可等时返回-1有子进程活着但没退时返回0回收成功了返回PID三种情况逻辑要理清否则很容易写出回收没回收干净或者循环直接退出的错误逻辑。生产环境中任务分发往往不会这么直白。比如子进程干完活还要把结果写进共享文件里那就涉及到写冲突、原子写、文件锁的问题再比如父进程在等待期间如果还要响应外部信号那wait的阻塞特性就会成为一个麻烦——这个在信号处理章节再展开。6. 踩坑现场多进程编程中那些很隐蔽的坑前几节讲的基本都是正确用法但实际写代码的过程总是伴随着各种看起来对上、跑起来不对的迷惑时刻。我把自己和周围同事踩过的几个典型坑整理出来算是给大家提个醒。第一个是缓冲区重复输出。前面提到过fork前printf没带换行导致内容输出两次这种现象在归档日志里特别坑。解决方案其实不止加\n这一种还要意识到stdout在终端下是行缓冲、重定向到文件时是全缓冲两种模式下缓冲行为完全不一样。如果你fork前打过没有换行的日志重定向到文件里甚至可能一份都不输出缓冲区被复制进程退出时各自刷新也可能刷出两份。最稳妥的做法是在fork关键节点前统一fflush(NULL)把所有缓冲一次性清算干净。第二个是Zombie进程的排查与防范。我遇到过一台服务器跑着跑着进程数飙到几十万最后连ssh都登不上去。排查过程就是ps -ef | grep defunct看到一堆字段状态为defunct的僵尸进程再pstree一追发现是个C程序起了几个worker子进程但父进程自己的逻辑写着写着提前退出了分支完全没有走到wait那一步。防护措施有三子进程退出后父进程及时wait回收为SIGCHLD信号注册处理器在处理器里兜底waitpid如果父进程确实不关心子进程退出状态可以用信号里设置signal(SIGCHLD, SIG_IGN)让内核自动回收但这个做法比较粗暴不适用所有场景。第三个是多进程同时写一个文件导致内容乱序或丢失。父进程和多个子进程都往同一个日志fd里write。看似每个进程都调用了write但多进程并发写时内核不保证整个写入过程是原子的。结果就可能出现日志相互穿插的乱码严重时一个进程的write操作把另一个进程的数据覆盖掉。解决思路有两个方向一是每个write操作之前加flock文件锁锁住文件再写写完释放二是干脆让所有进程把日志内容通过管道或本地socket发给一个专职logging进程由它统一负责写文件这是比较优雅的架构方案。第四个是隐藏的fd泄漏。fork之后子进程会继承父进程所有已打开的文件描述符。假设父进程打开了一个数据库连接socket、一个日志文件、一个epoll实例然后fork出若干子进程这些子进程虽然那边跑着其他程序经过exec文件描述符却还指向这些资源。如果子进程不主动close就会导致这些资源永远得不到释放典型表现是父进程明明关闭了数据库连接数据库端却显示连接还在。解决思路在子进程代码里显式close不需要的fd或者创建fd后立刻设置FD_CLOEXEC这样exec时会自动关闭。第五个是信号与wait的纠缠。阻塞在wait里的父进程收到信号后调用可能被信号打断返回-1并设置errno为EINTR。很多人在这个位置不检查errno直接把wait失败当成子进程没了于是逻辑直接崩掉。正确写法是循环里判断errno如果是EINTR就继续waitwhile (1) { pid_t r wait(NULL); if (r 0 errno EINTR) continue; if (r 0) break; }这个写法在一些高性能服务器代码里很常见属于老司机才注意得到的分支细节。这些坑之所以隐蔽不是因为它们有多高深而是因为它们在单进程的课程练习里压根不会出现。只有当你真正把程序放进多进程并发的环境里资源竞争、原子性、继承关系这些问题才会浮出水面。多任务编程的能力很大程度上不是靠背API背出来的而是靠这一轮一轮地填坑填出来的。就我个人的体会来说多进程编程入门最大的门槛还不在于fork怎么调用、wait怎么传参而在于思维模式要转换——你不再是一个只会一路顺序执行的人而是同时要管理多个独立执行流哪个流该干什么、谁等谁、谁收谁心里都要有一盘棋。把这盘棋下明白了再去看线程、看协程你会发现底层很多思路都是相通的。