3月12日我整理完这份进程管理笔记顺手把它定位成一个系列的第一篇。标题就叫《Linux C 进程管理(1) 03.12》吧里面的内容其实一点也不新就是Linux下用C语言进行进程管理时最核心的那几个API以及它们背后的运行逻辑。做嵌入式开发的人基本都会有这种经历主控进程要拉起采集、上传、心跳这些子任务还要时刻盯着它们崩了要自动重启做后端服务的人要在C代码里调用外部命令最经典的做法就是fork加exec就算只写点运维小工具也经常要批量创建子进程去处理并行任务。这些场景绕不开同一个主题进程管理。系统里最底层的C API也就是fork、exec、wait这一组函数是几乎所有上层框架的基石。把这一组函数的来龙去脉弄清楚比单纯多背几个Linux命令要值钱得多。这一篇是系列开头不急着讲特别深的内核调度我把进程从创建、运行、退出到被回收的完整路径先走一遍。你在看完之后至少能回答这几个问题fork返回值的两个分支到底怎么理解exec族那么多函数到底怎么选僵尸进程为什么会拖垮系统以及waitpid是凭什么做到精细化回收的。我还会贴一个能直接编译运行的完整示例最后附上我实际调试中踩过的坑。内容不会太长但密度不会低。1. 先想清楚进程管理到底解决什么问题1.1 从三个真实场景看进程管理的价值很多初学者一碰到进程管理的代码第一反应是“这东西能用在哪儿”。我直接说三个非常常见的场景。第一个是嵌入式设备上的任务调度。设备上电后主控进程启动它负责创建传感器采集子进程、网络上传子进程、日志记录子进程。每个子进程各干一件事主控进程通过周期性的waitpid检查它们是不是还活着如果进程退出码异常那就重新fork一个出来。这个模型在智能网关、摄像头、工业控制器里太常见了。第二个是服务端的命令调用工具。C程序需要在指定目录下执行一个外部shell命令并获取它的执行结果最常见的做法就是fork一个子进程然后在子进程里exec替换成sh或者具体命令父进程再用wait回收结束状态。其实我们自己写的shell执行一条命令时内核做的事就是这么一层套一层。第三个是测试框架的并发模拟。做压力测试时要同时生成几十上百个进程让它们各自执行一段逻辑后返回不同的退出码。父进程按顺序或按状态收集结果统计哪些通过哪些失败。这考验的正是对回收机制的掌控——谁退出、怎么退出、退出码是多少必须准确拿到。这三个场景背后其实指向同一个问题进程是有生命周期的创建、执行、退出、回收这几个环节缺一不可。C语言在Linux下的进程管理就是把这几个环节的API用对、用好。1.2 这一期我们要啃完哪些硬骨头既然是系列第一篇我把范围定得清楚一点免得你抱着“求全”的心态一头扎进来。这一期只做四件事第一建立对进程的基础认知搞明白进程和程序的区别以及Linux内核里描述进程的核心数据结构第二掌握fork调用它能创建子进程但要正确理解返回值机制还要避开缓冲区复制这个新手重灾区第三掌握exec族函数理解“fork之后通常是exec”这个组合以及每一个变体怎么选第四彻底解决进程回收的问题把僵尸进程和孤儿进程的成因、wait和waitpid的用法讲透。至于进程间通信、守护进程、线程等主题留给系列后面的篇幅。你会发现今天这一期其实是在打地基地基稳了后面讲共享内存、消息队列、信号量的时候才会顺。2. 进程是什么先建立基础认知2.1 程序是菜谱进程是那盘正在做的菜这句话是我带新人时最常用的类比。程序是一个存放在磁盘上的可执行文件它本质上是静态的指令集合什么也不做就像一本菜谱躺在书架上不会产生任何效果。进程则是程序被加载到内存之后拥有独立地址空间、独立系统资源的一个运行实体相当于厨师拿着菜谱开始洗菜、切菜、开火整个过程是动态的。同一个可执行文件可以被多次运行每次运行都会生成一个独立的进程。你在三个终端里分别运行同一个程序那就是三个完全不同的进程各自拥有独立的PID、独立的地址空间、独立的打开文件列表。它们之间即使代码完全一样运行状态也互不干扰。这一点和线程有本质区别——线程共享同一个地址空间进程是“鸡蛋各放各的篮子里”。所以当我们在C代码里调用fork之后实际上是在菜谱进行到一半的时候让一个厨师分身出另一个厨师两个厨师接着做同一道菜但各自的锅碗瓢盆是独立的。2.2 Linux眼里每个进程的“档案袋”task_structLinux内核用task_struct结构体来描述每一个进程你可以把它当成每个进程的档案袋。很多书喜欢把这本书讲得很厚但对我们写应用层的C代码来说抓住里面几个关键字段就够用了。第一个是PID和PPID。PID是进程自己的编号PPID是父进程的编号。进程的父子关系就是靠这两个字段维持的这种树状关系一直往上可以追溯到PID为1的init进程或者systemd。第二个是状态字段内核用它记录进程当前处于R、S、D、T、Z等哪个状态。第三个是内存描述符记录进程的地址空间布局包括代码段、数据段、堆、栈的位置。第四个是文件描述符表每个进程都有一张自己的文件表记录它打开的文件。我们在应用层虽然不直接操作task_struct但可以通过/proc文件系统间接查看。比如cat /proc/1234/stat或者以更容易阅读的方式看某个进程的信息cat /proc/1234/status里面会列出PID、PPID、Name、State、VmRSS等字段。排查进程问题的时候这个命令几乎必用。2.3 状态流转从R到Z再到消失Linux的进程状态常见的几种R表示运行中或就绪S表示可中断睡眠D表示不可中断睡眠通常是等待磁盘I/OT表示已停止Z表示僵尸X表示即将被销毁。对进程管理来说最需要关注的就是Z。进程从创建开始进入就绪队列等待调度得到CPU时间片后变成R等待某些资源时变成S或者D收到停止信号后变成T正常退出或者被信号杀死后并不会立刻彻底消失而是进入Z状态保留着一个“尸体”等待父进程来收尸这个尸体就是僵尸进程。只有父进程调用wait或waitpid拿到退出状态内核才会彻底把进程的记录移除。这个Z就是一系列经典问题的根源。我之前在一台运行了好几个月的服务器上执行过ps命令看到几十个僵尸进程就是因为某个服务程序没有正确处理子进程退出事件。别慌后面第5章我会给完整的解决方案。3. fork()详解复制一份自己3.1 返回值设计为什么反直觉fork大概是C语言里最让新人挠头的一个函数了。普通函数调用一次最多返回一次但fork调用一次却返回两次。原因很简单fork在调用点把当前进程复制了一份子进程从同一个位置继续往下执行。既然执行流变成了两条那就必然要有两个返回值。返回值具体的分配规则是这样pid_t pid fork(); if (pid 0) { // fork失败 } else if (pid 0) { // 这是子进程 } else { // 这是父进程pid是子进程的PID }父进程拿到的返回值是子进程的PID子进程拿到的返回值是0。很多人不理解为什么要这样设计。我换个角度说子进程自己想知道自己的PID调用getpid就行了不需要内核在fork返回时告诉它父进程则必须知道子进程的PID否则以后怎么wait它、怎么向它发信号所以父进程拿到的“子进程PID”才是真正有价值的信息。而返回0则是为了区分身份因为子进程只有通过返回值是否为0才能明确知道自己分支在哪里。需要特别注意的是fork失败的情况。常见原因是进程数达到系统上限或内存不足此时返回值是-1errno会被设置为EAGAIN或ENOMEM。生产代码里这个分支一定不能省略。3.2 写时拷贝与文件描述符继承早年间的教科书讲fork总是说子进程是父进程的完全拷贝包括整个地址空间。这个概念在现在的Linux上已经不准了。现代内核用的是copy-on-write技术也就是写时拷贝中文也叫“写时复制”。原理可以这样理解fork之后父进程和子进程并没有各自复制一份全部内存而是共享同一批物理内存页并且这些页被标记成只读。只要双方都只是读取就不产生新的拷贝效率极高。但是一旦其中一方试图写入某个页内核会立即复制这一页并重新分配映射双方这才各玩各的。所以如果fork之后子进程马上exec去运行一个全新的程序根本没有机会复制大量内存fork就非常轻量。不过有一样东西不是写时拷贝而是直接继承的文件描述符表。父进程已经打开的文件描述符子进程会直接继承并且内核里的文件偏移量是共享的。这意味着父进程往文件里写了内容子进程的偏移量也会跟着变化双双写同一个文件时会造成覆盖。实际开发的时候fork之后要考虑是否需要关闭某些文件描述符就是这个原因。3.3 那个坑了无数新人的缓冲区问题这是fork的经典陷阱我必须单独拿出来讲。看下面这段代码#include stdio.h #include unistd.h int main(void) { printf(before fork); fork(); printf(after fork\n); return 0; }你可能会认为输出两行“after fork”但只输出一行“before fork”。因为printf在很多时候是带缓冲的它在输出到普通文件时会把内容暂存在用户空间的缓冲区里只有在遇到换行符、或者程序正常退出、或者缓冲区满的时候才真正调用系统调用write输出。所以上面的“before fork”在fork调用之前可能还停留在stdio缓冲区里并没有真正写出去。fork复制了父进程的整个用户空间自然也包括这个缓冲区。最后代码退出时父进程和子进程各自刷新自己手里的缓冲区副本结果“before fork”被输出了两次。解决的办法是在fork之前主动刷新缓冲区printf(before fork\n); fflush(NULL); fork();我的建议是凡是fork之前有printf操作一律用fflush(NULL)把所有stdio缓冲区都刷干净再谈复制不复制的问题。看起来是小细节但在写日志的进程里如果踩中排查起来会让人抓狂。4. exec族函数用新程序替换当前进程4.1 为什么fork完还要execfork之后子进程和父进程运行的是同一份代码。但实际需求里我们经常希望子进程变成另一个程序。比如shell要执行ls命令它先fork出一个子进程然后这个子进程必须把ls程序加载到自己的地址空间里运行这就靠exec族函数来做。exec族函数做的事情可以理解成“换一副身体”它用新的可执行程序完全替换当前进程的代码段、数据段、堆和栈但进程的PID保持不变。注意一个关键点exec成功的时候它不会返回因为一旦返回说明执行新程序的代码空间已经不存在了。只有exec执行失败时返回值才是-1并设置errno。所以在代码里exec后面一般要直接跟错误处理而不是接着写“后面的逻辑”execlp(ls, ls, -l, NULL); perror(execlp failed); exit(EXIT_FAILURE);如果exec成功perror根本不会执行如果失败我们就能看到具体的错误信息这很自然。4.2 六个函数怎么选exec族一共有六个函数execl、execv、execlp、execvp、execle、execve。它们的基础区别可以看这张表函数名参数形式是否按PATH搜索程序是否可自定义环境变量execl变长参数列表否否execv字符串数组否否execlp变长参数列表是否execvp字符串数组是否execle变长参数列表否是execve字符串数组否是选函数的逻辑也很直接。需要按PATH自动搜索可执行文件就用带字母p的那两个参数个数固定、写得省事用execl系列参数动态生成、个数不确定用execv系列。字母l代表list也就是变长参数v代表vector也就是字符串数组。这个记忆法我一直在用。举个具体的例子。如果你想运行“ls -l /home”使用execlp可以这样写execlp(ls, ls, -l, /home, NULL);注意第一个“ls”是程序名第二个“ls”会作为argv[0]传给新程序这是Unix的约定。结尾的NULL必须带上表示参数列表结束。如果漏了它程序行为未定义非常危险。如果用execv就得先拼一个数组char *args[] {ls, -l, /home, NULL}; execv(/bin/ls, args);这里我写的是绝对路径所以用不带p的execv没问题。4.3 一个能跑通的forkexec示例把fork和exec连起来就能实现一个最简化的“执行命令”函数了。核心逻辑如下#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork); exit(EXIT_FAILURE); } if (pid 0) { // 子进程 execlp(ls, ls, -l, NULL); perror(execlp); exit(EXIT_FAILURE); } // 父进程等待子进程结束 int status; waitpid(pid, status, 0); return 0; }运行这个程序效果就是像在shell里执行ls -l一样。父进程创建子进程后子进程被exec替换成ls程序父进程耐心等待并回收。我在开发工具类程序时这个模式被反复使用你已经掌握它了。5. 进程回收把僵尸扼杀在摇篮里5.1 僵尸进程和孤儿进程到底咋回事先分清两个概念。僵尸进程是“先死没人收”的子进程。子进程结束调用exit或return后它其实并不会立刻被系统彻底抹掉而是保留着退出状态等信息留在进程表里等着父进程用wait或waitpid来读取。父进程如果不调用这个子进程就永远以Z状态待在进程表里虽然不占CPU、不占内存却占着PID。系统能创建的进程数不是无限的PID数量总是有限的。如果父进程一直不回收积累到一定程度再想fork新进程就会失败报EAGAIN。经典案例就是某个后台守护进程每次处理任务都fork一个子进程却忘了wait几天之后服务器上冒出一堆Z。孤儿进程和僵尸刚好相反。孤儿是父进程先退出子进程还没退出。父进程死后子进程就成了无根之木但它不会马上被销毁而是会被PID为1的进程收养由它定期调用wait回收。所以孤儿进程反而相对安全有系统兜底。5.2 wait与waitpid的精细用法处理回收最基础的方式是wait。pid_t wait(int *status);它会阻塞等待任意一个子进程退出并返回那个子进程的PID。status是一个输出参数用于接收退出状态。最简单的用法是wait(NULL);意思是“我不管子进程怎么退出的只要它退出了就行”。但实际开发中我们往往需要知道子进程是否正常退出退出码是多少甚至是不是被信号杀死的。这时候就要解析status。常用的宏有WIFEXITED(status)子进程是否正常退出WEXITSTATUS(status)正常退出时的退出码WIFSIGNALED(status)子进程是否被信号终止WTERMSIG(status)如果是被信号终止是哪个信号wait最大的问题是等待任意一个子进程。当你同时fork了多个子进程想指定等某个特定的PIDwait就不行了。waitpid就是为精细化回收而生的。waitpid的原型是pid_t waitpid(pid_t pid, int *status, int options);pid参数有几种传法为-1时表示等待任意子进程和wait几乎一样大于0时表示等待指定PID的子进程等于0时表示等待与调用者处于同一进程组的任意子进程小于-1时表示等待指定进程组ID的任意子进程。我们用得最多的就是大于0那一种。options参数常用的是WNOHANG意思是如果没有子进程退出不阻塞立即返回0。这给父进程提供了“轮询”的选项不需要一次调用就卡死在那里。完整的状态判断模板我一般这样写int status; pid_t child_pid waitpid(pid, status, 0); if (child_pid -1) { perror(waitpid); } else if (WIFEXITED(status)) { printf(child exited with code %d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(child killed by signal %d\n, WTERMSIG(status)); }关键心得是不要只判断WIFEXITED因为子进程完全可能被信号杀死这时WIFEXITED为假只处理正常退出就会漏掉一半的情况。5.3 用SIGCHLD自动兜底还有一类场景父进程根本不关心子进程的退出状态只要子进程别变僵尸就行。这个时候可以告诉内核子进程退出后直接自动回收。做法是在父进程里设置signal(SIGCHLD, SIG_IGN);子进程结束时会向父进程发送SIGCHLD信号一旦父进程把这个信号设置为忽略内核就知道父进程不想处理子进程状态于是子进程退出后会被自动回收不会进入僵尸状态。这个方法在写少量子进程、不需要退出码时非常省事。但如果你还是想根据退出状态做点逻辑那就别用SIG_IGN而是注册一个真正的SIGCHLD处理函数在handler里调用waitpid配合WNOHANG。复杂场景下我推荐用sigaction而不是signal来注册因为signal在不同Unix系统上语义有差异sigaction行为更统一、更可靠。struct sigaction sa {0}; sa.sa_handler reap_child; sa.sa_flags SA_RESTART; sigaction(SIGCHLD, sa, NULL);在reap_child里循环调用waitpid(-1, NULL, WNOHANG)直到返回0或-1把所有退出的子进程都收掉。注意打印语句不要在handler里写信号处理函数里做事越少越好。6. 实操5个任务进程的创建与回收6.1 程序功能设计与代码光讲概念不落地是没用的我来写一个带实际效果的综合示例。设计目标很简单父进程连续创建5个子进程每个子进程模拟一个耗时任务任务结束后返回不同的退出码父进程分别等待这5个子进程并打印出各自的退出状态。这个程序覆盖了fork、循环创建子进程、waitpid精确回收、状态宏解析、防止子进程陷入创建循环等关键点。#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h #define TASK_COUNT 5 int main(void) { pid_t children[TASK_COUNT]; for (int i 0; i TASK_COUNT; i) { pid_t pid fork(); if (pid 0) { perror(fork); exit(EXIT_FAILURE); } if (pid 0) { // 子进程只执行自己的任务然后退出 printf([child %d] task %d started\n, getpid(), i 1); sleep(i 1); printf([child %d] task %d finished\n, getpid(), i 1); exit((i 1) * 10); } // 父进程记录子进程PID children[i] pid; } // 父进程按顺序回收每一个子进程 for (int i 0; i TASK_COUNT; i) { int status; pid_t ret waitpid(children[i], status, 0); if (ret -1) { perror(waitpid); continue; } if (WIFEXITED(status)) { printf([parent] pid%d exited normally, code%d\n, ret, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf([parent] pid%d killed by signal %d\n, ret, WTERMSIG(status)); } } printf([parent] all tasks done.\n); return 0; }6.2 运行结果与关键点逐行解读保存为tasks.c编译运行gcc tasks.c -o tasks ./tasks输出看上去类似[child 18234] task 1 started [child 18235] task 2 started [child 18236] task 3 started [child 18237] task 4 started [child 18238] task 5 started [child 18234] task 1 finished [parent] pid18234 exited normally, code10 ...有几个细节值得你反复琢磨。第一个子进程分支里任务执行完立刻exit不会回到for循环继续fork下一个子进程。如果你在子进程分支里忘了exit或break子进程也会继续循环创建子进程最终进程树爆炸这是最常见也最隐蔽的bug。第二个父进程把每个子进程的PID存在数组里回收时用waitpid精确等待对应PID。如果这里改用wait就只能等到“任意一个”子进程退出顺序不可控。你要统计每个任务的独立退出码wait是做不到的。第三个我让每个子进程sleep不同的秒数这样你会直观看到“子进程按各自节奏结束但父进程是按数组顺序逐个认领尸体的”。也就是说task 3可能比task 1更早结束但父进程只有循环到children[0]时才回收task 1的进程其他先结束的子进程暂时停留在Z状态。这正好说明Z不一定代表系统有问题只要父进程稍后会回收它就是正常生命周期的一部分。6.3 用gdb亲眼看一次fork如果你想亲眼确认“调用一次返回两次”的效果可以用gdb来调试。编译时记得加调试选项gcc tasks.c -o tasks -g gdb ./tasks进入gdb之后先给fork调用那行打断点假设行号是第17行那么操作是break tasks.c:17 run命中断点后执行info inferiors可以看到当前只有一个进程。继续用next执行fork语句再执行info inferiors你会看到已经有了两个inferior分别对应父进程和子进程。gdb默认跟随父进程如果想调试子进程可以输入set follow-fork-mode child这样gdb会跟随进入子进程你可以继续步进观察子进程分支里的代码执行情况。我心里一直觉得gdb的inferiors机制是理解fork语义的最佳教具比自己盯着代码干想直观得多。7. 常见问题与排查实录7.1 问题速查表把我在实际开发和帮人看代码时遇到最多的进程管理问题整理成一张表方便你对照排查。现象常见原因解决办法fork返回-1perror显示EAGAIN进程数达到系统限制或RLIMIT_NPROC限制用ulimit -u查看限制清理僵尸或提高限制fork返回-1perror显示ENOMEM内存不足检查系统内存评估是否有进程疯狂申请内存printf的同一行内容输出了两次fork复制了stdio缓冲区在fork前调用fflush(NULL)代码里出现很多Z状态进程父进程没有wait或waitpid在父进程里正确回收或用SIGCHLD自动回收waitpid返回-1errno是ECHILD已经没有需要等待的子进程检查PID是否写错子进程可能早已被回收exec之后程序没有按预期运行exec失败但没有检查返回值exec语句后立刻perror并exit多个子进程用wait回收时结果乱套wait只能回收任意子进程顺序不可控改用waitpid指定PID逐个回收子进程和父进程同时写同一个文件内容错乱文件偏移量被继承且共享fork后按需关闭不需要的文件描述符7.2 几条只有踩坑才换得来的建议最后分享几条我自己的习惯不一定写在教科书里但能省很多排查时间。第一条fork和exec之间不要做什么“多余”的事。我指的是尽量不要在fork之后、exec之前调用一些复杂的库函数比如printf、malloc、动态链接相关的操作。因为此时子进程是父进程的完整镜像任何可能修改全局状态的操作都会留下痕迹。即便exec会用新镜像覆盖它们中间过程也可能产生难以复现的bug。第二条对子进程的状态判断要完整。我只判断WIFEXITED不管WIFSIGNALED结果线上某次子进程被外部kill掉程序没有任何日志输出排查了很久才发现是信号终止。后来我要求自己凡是wait系列返回成功必须把WIFEXITED和WIFSIGNALED都检查一遍。第三条处理多个子进程时优先用waitpid而不是wait。除非你的业务真的不在乎“任意一个”和“顺序”否则wait带来的随机性会让统计任务结果的逻辑变得极不可靠。用数组把PID存下来按PID回收才是稳定的姿势。第四条平时排查进程状态养成用ps -eo pid,ppid,stat,comm查看的习惯。看到Z就明白了问题大概率出在父进程没有回收。看到一堆进程PID暴涨优先怀疑fork循环里子进程没有正确分支退出。这个系列的第一篇到这里先告一段落。进程的创建、执行和回收已经是一条主线走完了下一期我打算接着这条线往后走把进程之间的协作讲透。毕竟进程管理不只是让子进程生下来、活一段、收尸真正复杂的是让多个进程之间能够协作起来那就要进入进程间通信的世界了。到时候见。
3月12日我整理完这份进程管理笔记顺手把它定位成一个系列的第一篇。标题就叫《Linux C 进程管理(1) 03.12》吧里面的内容其实一点也不新就是Linux下用C语言进行进程管理时最核心的那几个API以及它们背后的运行逻辑。做嵌入式开发的人基本都会有这种经历主控进程要拉起采集、上传、心跳这些子任务还要时刻盯着它们崩了要自动重启做后端服务的人要在C代码里调用外部命令最经典的做法就是fork加exec就算只写点运维小工具也经常要批量创建子进程去处理并行任务。这些场景绕不开同一个主题进程管理。系统里最底层的C API也就是fork、exec、wait这一组函数是几乎所有上层框架的基石。把这一组函数的来龙去脉弄清楚比单纯多背几个Linux命令要值钱得多。这一篇是系列开头不急着讲特别深的内核调度我把进程从创建、运行、退出到被回收的完整路径先走一遍。你在看完之后至少能回答这几个问题fork返回值的两个分支到底怎么理解exec族那么多函数到底怎么选僵尸进程为什么会拖垮系统以及waitpid是凭什么做到精细化回收的。我还会贴一个能直接编译运行的完整示例最后附上我实际调试中踩过的坑。内容不会太长但密度不会低。1. 先想清楚进程管理到底解决什么问题1.1 从三个真实场景看进程管理的价值很多初学者一碰到进程管理的代码第一反应是“这东西能用在哪儿”。我直接说三个非常常见的场景。第一个是嵌入式设备上的任务调度。设备上电后主控进程启动它负责创建传感器采集子进程、网络上传子进程、日志记录子进程。每个子进程各干一件事主控进程通过周期性的waitpid检查它们是不是还活着如果进程退出码异常那就重新fork一个出来。这个模型在智能网关、摄像头、工业控制器里太常见了。第二个是服务端的命令调用工具。C程序需要在指定目录下执行一个外部shell命令并获取它的执行结果最常见的做法就是fork一个子进程然后在子进程里exec替换成sh或者具体命令父进程再用wait回收结束状态。其实我们自己写的shell执行一条命令时内核做的事就是这么一层套一层。第三个是测试框架的并发模拟。做压力测试时要同时生成几十上百个进程让它们各自执行一段逻辑后返回不同的退出码。父进程按顺序或按状态收集结果统计哪些通过哪些失败。这考验的正是对回收机制的掌控——谁退出、怎么退出、退出码是多少必须准确拿到。这三个场景背后其实指向同一个问题进程是有生命周期的创建、执行、退出、回收这几个环节缺一不可。C语言在Linux下的进程管理就是把这几个环节的API用对、用好。1.2 这一期我们要啃完哪些硬骨头既然是系列第一篇我把范围定得清楚一点免得你抱着“求全”的心态一头扎进来。这一期只做四件事第一建立对进程的基础认知搞明白进程和程序的区别以及Linux内核里描述进程的核心数据结构第二掌握fork调用它能创建子进程但要正确理解返回值机制还要避开缓冲区复制这个新手重灾区第三掌握exec族函数理解“fork之后通常是exec”这个组合以及每一个变体怎么选第四彻底解决进程回收的问题把僵尸进程和孤儿进程的成因、wait和waitpid的用法讲透。至于进程间通信、守护进程、线程等主题留给系列后面的篇幅。你会发现今天这一期其实是在打地基地基稳了后面讲共享内存、消息队列、信号量的时候才会顺。2. 进程是什么先建立基础认知2.1 程序是菜谱进程是那盘正在做的菜这句话是我带新人时最常用的类比。程序是一个存放在磁盘上的可执行文件它本质上是静态的指令集合什么也不做就像一本菜谱躺在书架上不会产生任何效果。进程则是程序被加载到内存之后拥有独立地址空间、独立系统资源的一个运行实体相当于厨师拿着菜谱开始洗菜、切菜、开火整个过程是动态的。同一个可执行文件可以被多次运行每次运行都会生成一个独立的进程。你在三个终端里分别运行同一个程序那就是三个完全不同的进程各自拥有独立的PID、独立的地址空间、独立的打开文件列表。它们之间即使代码完全一样运行状态也互不干扰。这一点和线程有本质区别——线程共享同一个地址空间进程是“鸡蛋各放各的篮子里”。所以当我们在C代码里调用fork之后实际上是在菜谱进行到一半的时候让一个厨师分身出另一个厨师两个厨师接着做同一道菜但各自的锅碗瓢盆是独立的。2.2 Linux眼里每个进程的“档案袋”task_structLinux内核用task_struct结构体来描述每一个进程你可以把它当成每个进程的档案袋。很多书喜欢把这本书讲得很厚但对我们写应用层的C代码来说抓住里面几个关键字段就够用了。第一个是PID和PPID。PID是进程自己的编号PPID是父进程的编号。进程的父子关系就是靠这两个字段维持的这种树状关系一直往上可以追溯到PID为1的init进程或者systemd。第二个是状态字段内核用它记录进程当前处于R、S、D、T、Z等哪个状态。第三个是内存描述符记录进程的地址空间布局包括代码段、数据段、堆、栈的位置。第四个是文件描述符表每个进程都有一张自己的文件表记录它打开的文件。我们在应用层虽然不直接操作task_struct但可以通过/proc文件系统间接查看。比如cat /proc/1234/stat或者以更容易阅读的方式看某个进程的信息cat /proc/1234/status里面会列出PID、PPID、Name、State、VmRSS等字段。排查进程问题的时候这个命令几乎必用。2.3 状态流转从R到Z再到消失Linux的进程状态常见的几种R表示运行中或就绪S表示可中断睡眠D表示不可中断睡眠通常是等待磁盘I/OT表示已停止Z表示僵尸X表示即将被销毁。对进程管理来说最需要关注的就是Z。进程从创建开始进入就绪队列等待调度得到CPU时间片后变成R等待某些资源时变成S或者D收到停止信号后变成T正常退出或者被信号杀死后并不会立刻彻底消失而是进入Z状态保留着一个“尸体”等待父进程来收尸这个尸体就是僵尸进程。只有父进程调用wait或waitpid拿到退出状态内核才会彻底把进程的记录移除。这个Z就是一系列经典问题的根源。我之前在一台运行了好几个月的服务器上执行过ps命令看到几十个僵尸进程就是因为某个服务程序没有正确处理子进程退出事件。别慌后面第5章我会给完整的解决方案。3. fork()详解复制一份自己3.1 返回值设计为什么反直觉fork大概是C语言里最让新人挠头的一个函数了。普通函数调用一次最多返回一次但fork调用一次却返回两次。原因很简单fork在调用点把当前进程复制了一份子进程从同一个位置继续往下执行。既然执行流变成了两条那就必然要有两个返回值。返回值具体的分配规则是这样pid_t pid fork(); if (pid 0) { // fork失败 } else if (pid 0) { // 这是子进程 } else { // 这是父进程pid是子进程的PID }父进程拿到的返回值是子进程的PID子进程拿到的返回值是0。很多人不理解为什么要这样设计。我换个角度说子进程自己想知道自己的PID调用getpid就行了不需要内核在fork返回时告诉它父进程则必须知道子进程的PID否则以后怎么wait它、怎么向它发信号所以父进程拿到的“子进程PID”才是真正有价值的信息。而返回0则是为了区分身份因为子进程只有通过返回值是否为0才能明确知道自己分支在哪里。需要特别注意的是fork失败的情况。常见原因是进程数达到系统上限或内存不足此时返回值是-1errno会被设置为EAGAIN或ENOMEM。生产代码里这个分支一定不能省略。3.2 写时拷贝与文件描述符继承早年间的教科书讲fork总是说子进程是父进程的完全拷贝包括整个地址空间。这个概念在现在的Linux上已经不准了。现代内核用的是copy-on-write技术也就是写时拷贝中文也叫“写时复制”。原理可以这样理解fork之后父进程和子进程并没有各自复制一份全部内存而是共享同一批物理内存页并且这些页被标记成只读。只要双方都只是读取就不产生新的拷贝效率极高。但是一旦其中一方试图写入某个页内核会立即复制这一页并重新分配映射双方这才各玩各的。所以如果fork之后子进程马上exec去运行一个全新的程序根本没有机会复制大量内存fork就非常轻量。不过有一样东西不是写时拷贝而是直接继承的文件描述符表。父进程已经打开的文件描述符子进程会直接继承并且内核里的文件偏移量是共享的。这意味着父进程往文件里写了内容子进程的偏移量也会跟着变化双双写同一个文件时会造成覆盖。实际开发的时候fork之后要考虑是否需要关闭某些文件描述符就是这个原因。3.3 那个坑了无数新人的缓冲区问题这是fork的经典陷阱我必须单独拿出来讲。看下面这段代码#include stdio.h #include unistd.h int main(void) { printf(before fork); fork(); printf(after fork\n); return 0; }你可能会认为输出两行“after fork”但只输出一行“before fork”。因为printf在很多时候是带缓冲的它在输出到普通文件时会把内容暂存在用户空间的缓冲区里只有在遇到换行符、或者程序正常退出、或者缓冲区满的时候才真正调用系统调用write输出。所以上面的“before fork”在fork调用之前可能还停留在stdio缓冲区里并没有真正写出去。fork复制了父进程的整个用户空间自然也包括这个缓冲区。最后代码退出时父进程和子进程各自刷新自己手里的缓冲区副本结果“before fork”被输出了两次。解决的办法是在fork之前主动刷新缓冲区printf(before fork\n); fflush(NULL); fork();我的建议是凡是fork之前有printf操作一律用fflush(NULL)把所有stdio缓冲区都刷干净再谈复制不复制的问题。看起来是小细节但在写日志的进程里如果踩中排查起来会让人抓狂。4. exec族函数用新程序替换当前进程4.1 为什么fork完还要execfork之后子进程和父进程运行的是同一份代码。但实际需求里我们经常希望子进程变成另一个程序。比如shell要执行ls命令它先fork出一个子进程然后这个子进程必须把ls程序加载到自己的地址空间里运行这就靠exec族函数来做。exec族函数做的事情可以理解成“换一副身体”它用新的可执行程序完全替换当前进程的代码段、数据段、堆和栈但进程的PID保持不变。注意一个关键点exec成功的时候它不会返回因为一旦返回说明执行新程序的代码空间已经不存在了。只有exec执行失败时返回值才是-1并设置errno。所以在代码里exec后面一般要直接跟错误处理而不是接着写“后面的逻辑”execlp(ls, ls, -l, NULL); perror(execlp failed); exit(EXIT_FAILURE);如果exec成功perror根本不会执行如果失败我们就能看到具体的错误信息这很自然。4.2 六个函数怎么选exec族一共有六个函数execl、execv、execlp、execvp、execle、execve。它们的基础区别可以看这张表函数名参数形式是否按PATH搜索程序是否可自定义环境变量execl变长参数列表否否execv字符串数组否否execlp变长参数列表是否execvp字符串数组是否execle变长参数列表否是execve字符串数组否是选函数的逻辑也很直接。需要按PATH自动搜索可执行文件就用带字母p的那两个参数个数固定、写得省事用execl系列参数动态生成、个数不确定用execv系列。字母l代表list也就是变长参数v代表vector也就是字符串数组。这个记忆法我一直在用。举个具体的例子。如果你想运行“ls -l /home”使用execlp可以这样写execlp(ls, ls, -l, /home, NULL);注意第一个“ls”是程序名第二个“ls”会作为argv[0]传给新程序这是Unix的约定。结尾的NULL必须带上表示参数列表结束。如果漏了它程序行为未定义非常危险。如果用execv就得先拼一个数组char *args[] {ls, -l, /home, NULL}; execv(/bin/ls, args);这里我写的是绝对路径所以用不带p的execv没问题。4.3 一个能跑通的forkexec示例把fork和exec连起来就能实现一个最简化的“执行命令”函数了。核心逻辑如下#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork); exit(EXIT_FAILURE); } if (pid 0) { // 子进程 execlp(ls, ls, -l, NULL); perror(execlp); exit(EXIT_FAILURE); } // 父进程等待子进程结束 int status; waitpid(pid, status, 0); return 0; }运行这个程序效果就是像在shell里执行ls -l一样。父进程创建子进程后子进程被exec替换成ls程序父进程耐心等待并回收。我在开发工具类程序时这个模式被反复使用你已经掌握它了。5. 进程回收把僵尸扼杀在摇篮里5.1 僵尸进程和孤儿进程到底咋回事先分清两个概念。僵尸进程是“先死没人收”的子进程。子进程结束调用exit或return后它其实并不会立刻被系统彻底抹掉而是保留着退出状态等信息留在进程表里等着父进程用wait或waitpid来读取。父进程如果不调用这个子进程就永远以Z状态待在进程表里虽然不占CPU、不占内存却占着PID。系统能创建的进程数不是无限的PID数量总是有限的。如果父进程一直不回收积累到一定程度再想fork新进程就会失败报EAGAIN。经典案例就是某个后台守护进程每次处理任务都fork一个子进程却忘了wait几天之后服务器上冒出一堆Z。孤儿进程和僵尸刚好相反。孤儿是父进程先退出子进程还没退出。父进程死后子进程就成了无根之木但它不会马上被销毁而是会被PID为1的进程收养由它定期调用wait回收。所以孤儿进程反而相对安全有系统兜底。5.2 wait与waitpid的精细用法处理回收最基础的方式是wait。pid_t wait(int *status);它会阻塞等待任意一个子进程退出并返回那个子进程的PID。status是一个输出参数用于接收退出状态。最简单的用法是wait(NULL);意思是“我不管子进程怎么退出的只要它退出了就行”。但实际开发中我们往往需要知道子进程是否正常退出退出码是多少甚至是不是被信号杀死的。这时候就要解析status。常用的宏有WIFEXITED(status)子进程是否正常退出WEXITSTATUS(status)正常退出时的退出码WIFSIGNALED(status)子进程是否被信号终止WTERMSIG(status)如果是被信号终止是哪个信号wait最大的问题是等待任意一个子进程。当你同时fork了多个子进程想指定等某个特定的PIDwait就不行了。waitpid就是为精细化回收而生的。waitpid的原型是pid_t waitpid(pid_t pid, int *status, int options);pid参数有几种传法为-1时表示等待任意子进程和wait几乎一样大于0时表示等待指定PID的子进程等于0时表示等待与调用者处于同一进程组的任意子进程小于-1时表示等待指定进程组ID的任意子进程。我们用得最多的就是大于0那一种。options参数常用的是WNOHANG意思是如果没有子进程退出不阻塞立即返回0。这给父进程提供了“轮询”的选项不需要一次调用就卡死在那里。完整的状态判断模板我一般这样写int status; pid_t child_pid waitpid(pid, status, 0); if (child_pid -1) { perror(waitpid); } else if (WIFEXITED(status)) { printf(child exited with code %d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(child killed by signal %d\n, WTERMSIG(status)); }关键心得是不要只判断WIFEXITED因为子进程完全可能被信号杀死这时WIFEXITED为假只处理正常退出就会漏掉一半的情况。5.3 用SIGCHLD自动兜底还有一类场景父进程根本不关心子进程的退出状态只要子进程别变僵尸就行。这个时候可以告诉内核子进程退出后直接自动回收。做法是在父进程里设置signal(SIGCHLD, SIG_IGN);子进程结束时会向父进程发送SIGCHLD信号一旦父进程把这个信号设置为忽略内核就知道父进程不想处理子进程状态于是子进程退出后会被自动回收不会进入僵尸状态。这个方法在写少量子进程、不需要退出码时非常省事。但如果你还是想根据退出状态做点逻辑那就别用SIG_IGN而是注册一个真正的SIGCHLD处理函数在handler里调用waitpid配合WNOHANG。复杂场景下我推荐用sigaction而不是signal来注册因为signal在不同Unix系统上语义有差异sigaction行为更统一、更可靠。struct sigaction sa {0}; sa.sa_handler reap_child; sa.sa_flags SA_RESTART; sigaction(SIGCHLD, sa, NULL);在reap_child里循环调用waitpid(-1, NULL, WNOHANG)直到返回0或-1把所有退出的子进程都收掉。注意打印语句不要在handler里写信号处理函数里做事越少越好。6. 实操5个任务进程的创建与回收6.1 程序功能设计与代码光讲概念不落地是没用的我来写一个带实际效果的综合示例。设计目标很简单父进程连续创建5个子进程每个子进程模拟一个耗时任务任务结束后返回不同的退出码父进程分别等待这5个子进程并打印出各自的退出状态。这个程序覆盖了fork、循环创建子进程、waitpid精确回收、状态宏解析、防止子进程陷入创建循环等关键点。#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h #define TASK_COUNT 5 int main(void) { pid_t children[TASK_COUNT]; for (int i 0; i TASK_COUNT; i) { pid_t pid fork(); if (pid 0) { perror(fork); exit(EXIT_FAILURE); } if (pid 0) { // 子进程只执行自己的任务然后退出 printf([child %d] task %d started\n, getpid(), i 1); sleep(i 1); printf([child %d] task %d finished\n, getpid(), i 1); exit((i 1) * 10); } // 父进程记录子进程PID children[i] pid; } // 父进程按顺序回收每一个子进程 for (int i 0; i TASK_COUNT; i) { int status; pid_t ret waitpid(children[i], status, 0); if (ret -1) { perror(waitpid); continue; } if (WIFEXITED(status)) { printf([parent] pid%d exited normally, code%d\n, ret, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf([parent] pid%d killed by signal %d\n, ret, WTERMSIG(status)); } } printf([parent] all tasks done.\n); return 0; }6.2 运行结果与关键点逐行解读保存为tasks.c编译运行gcc tasks.c -o tasks ./tasks输出看上去类似[child 18234] task 1 started [child 18235] task 2 started [child 18236] task 3 started [child 18237] task 4 started [child 18238] task 5 started [child 18234] task 1 finished [parent] pid18234 exited normally, code10 ...有几个细节值得你反复琢磨。第一个子进程分支里任务执行完立刻exit不会回到for循环继续fork下一个子进程。如果你在子进程分支里忘了exit或break子进程也会继续循环创建子进程最终进程树爆炸这是最常见也最隐蔽的bug。第二个父进程把每个子进程的PID存在数组里回收时用waitpid精确等待对应PID。如果这里改用wait就只能等到“任意一个”子进程退出顺序不可控。你要统计每个任务的独立退出码wait是做不到的。第三个我让每个子进程sleep不同的秒数这样你会直观看到“子进程按各自节奏结束但父进程是按数组顺序逐个认领尸体的”。也就是说task 3可能比task 1更早结束但父进程只有循环到children[0]时才回收task 1的进程其他先结束的子进程暂时停留在Z状态。这正好说明Z不一定代表系统有问题只要父进程稍后会回收它就是正常生命周期的一部分。6.3 用gdb亲眼看一次fork如果你想亲眼确认“调用一次返回两次”的效果可以用gdb来调试。编译时记得加调试选项gcc tasks.c -o tasks -g gdb ./tasks进入gdb之后先给fork调用那行打断点假设行号是第17行那么操作是break tasks.c:17 run命中断点后执行info inferiors可以看到当前只有一个进程。继续用next执行fork语句再执行info inferiors你会看到已经有了两个inferior分别对应父进程和子进程。gdb默认跟随父进程如果想调试子进程可以输入set follow-fork-mode child这样gdb会跟随进入子进程你可以继续步进观察子进程分支里的代码执行情况。我心里一直觉得gdb的inferiors机制是理解fork语义的最佳教具比自己盯着代码干想直观得多。7. 常见问题与排查实录7.1 问题速查表把我在实际开发和帮人看代码时遇到最多的进程管理问题整理成一张表方便你对照排查。现象常见原因解决办法fork返回-1perror显示EAGAIN进程数达到系统限制或RLIMIT_NPROC限制用ulimit -u查看限制清理僵尸或提高限制fork返回-1perror显示ENOMEM内存不足检查系统内存评估是否有进程疯狂申请内存printf的同一行内容输出了两次fork复制了stdio缓冲区在fork前调用fflush(NULL)代码里出现很多Z状态进程父进程没有wait或waitpid在父进程里正确回收或用SIGCHLD自动回收waitpid返回-1errno是ECHILD已经没有需要等待的子进程检查PID是否写错子进程可能早已被回收exec之后程序没有按预期运行exec失败但没有检查返回值exec语句后立刻perror并exit多个子进程用wait回收时结果乱套wait只能回收任意子进程顺序不可控改用waitpid指定PID逐个回收子进程和父进程同时写同一个文件内容错乱文件偏移量被继承且共享fork后按需关闭不需要的文件描述符7.2 几条只有踩坑才换得来的建议最后分享几条我自己的习惯不一定写在教科书里但能省很多排查时间。第一条fork和exec之间不要做什么“多余”的事。我指的是尽量不要在fork之后、exec之前调用一些复杂的库函数比如printf、malloc、动态链接相关的操作。因为此时子进程是父进程的完整镜像任何可能修改全局状态的操作都会留下痕迹。即便exec会用新镜像覆盖它们中间过程也可能产生难以复现的bug。第二条对子进程的状态判断要完整。我只判断WIFEXITED不管WIFSIGNALED结果线上某次子进程被外部kill掉程序没有任何日志输出排查了很久才发现是信号终止。后来我要求自己凡是wait系列返回成功必须把WIFEXITED和WIFSIGNALED都检查一遍。第三条处理多个子进程时优先用waitpid而不是wait。除非你的业务真的不在乎“任意一个”和“顺序”否则wait带来的随机性会让统计任务结果的逻辑变得极不可靠。用数组把PID存下来按PID回收才是稳定的姿势。第四条平时排查进程状态养成用ps -eo pid,ppid,stat,comm查看的习惯。看到Z就明白了问题大概率出在父进程没有回收。看到一堆进程PID暴涨优先怀疑fork循环里子进程没有正确分支退出。这个系列的第一篇到这里先告一段落。进程的创建、执行和回收已经是一条主线走完了下一期我打算接着这条线往后走把进程之间的协作讲透。毕竟进程管理不只是让子进程生下来、活一段、收尸真正复杂的是让多个进程之间能够协作起来那就要进入进程间通信的世界了。到时候见。
