最近在整理这几年写Linux C的代码笔记第一个想聊透的就是进程管理。很多读者留言说fork会用但每次跑多进程程序都出奇奇怪怪的问题——父进程退出了子进程还在跑、ps里冒出一堆Z状态进程、fork之后printf的输出重复了。这些都是进程管理没形成体系的表现。这篇文章是进程管理系列的第一篇从进程的出生讲到退场覆盖fork、exec、wait这些核心调用再配合一个真实可跑的任务分发示例把底层原理和实操坑一次说清楚。适合刚开始写Linux C的读者也适合那些已经被僵尸进程折磨过、想系统补课的人。1. 先想清楚一个根本问题进程到底是什么1.1 从程序到进程静态文件和动态实体的差异很多教材第一句话就是进程是运行中的程序听起来像废话但仔细琢磨会发现信息量很大。程序是磁盘上躺着的ELF文件它不占CPU、不占内存、不占文件描述符就是一串静态的字节。进程则完全不同它是一套完整的运行环境有独立的地址空间、有当前执行位置、有打开的文件、有环境变量、有内核里保存的一套上下文。拿做饭打比方。程序是菜谱放在书架上落灰也不会产生任何效果进程是照着菜谱正在做菜的那个状态——锅里的温度、切好的菜、放了几勺盐这些都是运行时才有的东西。同样的菜谱十个人同时做就是十个进程它们共享的是菜谱这一份代码但各自的食材、火候、调料互不相干。这个差异在写多进程程序时非常关键。同一份可执行文件启动两次内核会创建两个task_struct代码段在物理内存里只有一份只读共享但数据段、堆栈、堆都是各自私有的。很多人第一次写fork程序时会惊讶为什么子进程改了变量父进程看不到因为那本来就不是同一个变量只是fok时复制了一份相同的值而已。1.2 task_struct内核手里的那张进程身份证从内核视角看进程就是一个结构体。Linux里这个结构体叫task_struct以前叫进程控制块PCB。它有多大不同内核版本不一样但六百多个字段是有的。这里面装着的东西大致可以分成几类标识类PID、PPID、进程组ID、会话ID状态类当前处于什么状态调度器需要读它内存类mm_struct指针指向页表、虚拟地址空间描述文件类files_struct这张表记录了进程打开了哪些文件信号类信号掩码、待处理信号队列调度类优先级、调度策略、运行时间统计亲缘关系父进程、子进程、兄弟进程的指针用户态拿不到整个task_struct但Linux提供了一面镜子/proc目录。每个进程对应/proc/ /其中status文件是人类可读的进程关键信息汇总stat文件则是内核原始统计数据。我排查进程问题时的第一习惯就是执行cat /proc/ /status先看State那行再看PPid再扫一眼VmRSS比单纯ps拿到的信息多得多。一开始学进程管理不需要把task_struct的每个字段都背下来但心里要有这张图进程不是飘在空中的抽象概念它是内核里一条具体的、随时可以被调度的记录。理解了这一点后面再看僵尸、孤儿、写时拷贝都会顺理成章。1.3 我们写C代码时其实一直在跟这几个数字打交道进程管理里最先接触的API就是getpid和getppid。getpid返回当前进程的PIDgetppid返回父进程的PID。这两个函数在进程的一生中随时可以调用不需要特权。#include stdio.h #include unistd.h int main(void) { printf(pid: %d, ppid: %d\n, getpid(), getppid()); return 0; }PID这个数字是要深入理解的。它是内核为进程分配的识别号从2开始递增1号进程是系统启动时的第一个用户态进程现在的Linux发行版上通常叫systemd。PID是会复用的如果系统里进程数太多或者某个进程的PID一直不被回收后面就可能分配出重复的PID。所谓一直被占用指的就是僵尸进程——它的PID还留在进程表里新进程无法使用这个号。还有一个容易混淆的概念是tgid。Linux里线程也被实现成task_struct所以从内核看线程和进程是同一套机制。getpid()返回的其实是线程组IDtgid而真正的线程内ID需要syscall(SYS_gettid)。这个话题到线程部分再展开现在只要记住一点进程管理里说的一个进程在Linux内核眼里和一个线程是同一类对象只是共享的内存资源不同。2. 进程从哪来fork/vfork/exec 的决策逻辑2.1 fork一次调用两次返回fork是Unix系最经典的进程创建接口。它做的事情可以概括为以当前进程为模板创建一份几乎完全相同的拷贝。难点在于这个调用一旦成功调用现场就分裂了——父进程的fork返回子进程的PID子进程的fork返回0。#include stdio.h #include unistd.h #include sys/types.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { printf(child: my pid is %d, ppid is %d\n, getpid(), getppid()); } else { printf(parent: child pid is %d, my pid is %d\n, pid, getpid()); } return 0; }新手最容易漏掉的是先判断pid 0。fork失败的常见原因是进程数达到系统上限但应用层能做的很少该检查还是要检查。我见过不少线上事故就是因为fork后没判断返回值直接拿pid当有效值用最后子进程分支没走、父进程逻辑整体错乱。fork之后两个进程的执行位置是相同的都停在fork返回语句之后的那一行。所以代码必须用if/else把父子逻辑严格分开。这不是风格问题而是fork模型的硬性要求——如果你不写else父进程和子进程会同时往下执行任务就重复了。2.2 写时拷贝COW到底在优化什么早期的Unix fork实现非常粗暴把父进程的整个地址空间复制一份给子进程。分配物理内存、复制页表、逐页拷贝数据一套下来开销巨大。但后来人们发现一个规律绝大多数fork之后紧接着就是exec——exec会丢弃当前地址空间并加载一个全新程序前面辛辛苦苦复制的数据全都白费了。现代Linux用写时拷贝Copy on Write来解决这个问题。fork的时候父子进程先共享同一个物理内存页并把这块页标记为只读。双方都只读时相安无事。一旦父或子尝试写入这个页CPU触发缺页异常内核才真正分配一个新物理页把那块内存的内容复制过去再更新页表。这就是写时拷贝的含义等到要写的那一刻才复制。用代码理解COW下面的程序里fork之后unused是一个从未被修改的局部变量它可能始终和父进程共享物理页而counter被子进程修改触发一次真正复制。#include stdio.h #include unistd.h int main(void) { long unused 0; long counter 0; pid_t pid fork(); if (pid 0) { for (int i 0; i 100000; i) counter; printf(child counter: %ld\n, counter); } else { counter 500; printf(parent counter: %ld\n, counter); } return 0; }COW的意义不只是快它还保证了一个核心语义子进程看到的内存是父进程在fork时刻的快照之后双方各自修改互不可见。有人说COW让fork变成了假复制这种理解不对——语义上仍然是完整拷贝只是实现上把复制操作推迟到了必要时刻。该隔离的照样隔离。2.3 vfork一个很容易被误解的历史遗留vfork在刚接触的时候很容易搞混因为它的行为太反直觉了。它创建子进程时不复制地址空间子进程直接使用父进程的内存并且父进程会被挂起直到子进程调用execve或exit。换句话说子进程对变量的修改父进程能看到——这和fork的隔离语义完全相反。为什么要设计这样一个危险的东西因为比fork更老的内核连COW都没有fork复制开销实在太大而有些场景就是fork完立刻exec。vfork优化掉了这个复制过程。如今COW已经让fork足够廉价vfork的用武之地非常小除非是在那些内存极度受限的嵌入式环境里或者某个实时系统对fork的延迟极其敏感。vfork最著名的坑是子进程在main函数里直接return。return会执行栈帧清理最终还会触发exit相关的用户态流程这会把子进程的栈操作到父进程的内存上因为两者共享地址空间。我见过一次诡异的崩溃查了半天发现就是vforkreturn导致的。所以原则很简单除非非常明确自己在干什么否则一律用fork如果用了vfork子进程里必须马上exec或者exit不要有任何多余动作。2.4 exec族函数换壳不换核fork负责生exec负责变。exec系列函数会把当前进程的内存映像整个替换掉——加载一个新程序重新初始化堆栈、数据段、代码段然后从新程序的入口开始执行。但注意进程的PID没有变文件描述符表默认也保留除非显式打了O_CLOEXEC标记信号掩码之类的属性也会保留。所以从效果看exec是给一个进程换了层壳而不是新建进程。#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { execlp(ls, ls, -l, NULL); perror(execlp); _exit(1); } waitpid(pid, NULL, 0); return 0; }execlp里的p表示会通过PATH环境变量搜索可执行文件l表示参数以列表形式传递参数列表必须以NULL结尾。还有execv系列参数用字符串数组传。初学阶段把它们分成两类记就够了带p的会去PATH里找带l的用可变参数带v的用数组。实际上它们最终都是调用execve这个系统调用。子进程exec成功时原来的代码不再执行所以exec返回值只在失败时才返回-1。这里必须强制检查失败分支否则一旦exec失败子进程会继续往下执行通常直接_exit(1)是最稳妥的处理。exec还有一个隐性问题新程序启动时继承了大量旧的属性——环境变量、打开的文件描述符、信号配置。如果不想要某个fd被继承必须在open时加O_CLOEXEC或者在exec前手动close。多进程写网络服务时这个细节决定你能不能把监听socket永远留在父进程手里。3. 进程活着的时候都会经历什么状态流转与调度暗示3.1 五状态模型之外Linux还有两个隐藏状态教科书讲进程状态通常给一个五状态模型新建、就绪、运行、阻塞、终止。这个模型能帮助理解大框架但放到Linux上就不够用了。用ps看真实系统的进程状态你会看到R、S、D、T、Z、X这些字母它们对应Linux内核里的几类task_struct状态。TASK_RUNNING对应R。既包含正在CPU上运行的进程也包含已经在运行队列里排队、随时可以运行的进程。TASK_INTERRUPTIBLE对应S。可中断睡眠。进程在等待某个条件比如等待socket数据、等互斥锁但可以被信号唤醒。TASK_UNINTERRUPTIBLE对应D。不可中断睡眠主要在等待IO完成磁盘读写、NFS等。这个状态拒绝处理信号kill不掉。TASK_STOPPED / TASK_TRACED对应T。进程被暂停比如收到SIGSTOP或者正在被调试器停住。EXIT_ZOMBIE对应Z。进程已经终止但还没被父进程回收。我最想单独拎出来讲的是D状态。很多新手第一次看到D状态的进程杀不掉以为系统中毒了。其实D状态往往是磁盘IO卡死的信号进程在内核里等着一个读写操作返回这个操作迟迟不回来内核没法安全地把进程切到可中断状态。这种情况如果持续很久不消失通常要检查存储系统是否出问题。3.2 从ps输出的STAT一列看进程处境ps aux输出里的STAT看着只是一串字母其实是读懂进程状态的密码。单个字母主要是状态字母含义Rrunning在运行队列中Ssleeping可中断睡眠Duninterruptible sleep不可中断睡眠Tstopped停止或被跟踪Zzombie僵尸进程Xdead终止且不会出现在正常ps里STAT字段末尾还经常跟着附加符号。表示这个进程在前台进程组s表示它是会话首进程通常是终端对应的shelll表示多线程表示高优先级N表示低优先级。从前台后台看这个问题最直观。在bash里直接跑一个程序它属于前台进程组STAT带如果用放到后台就没有。这个区分和信号传递有直接关系你按下CtrlC内核并不会给所有进程发SIGINT而是只发给当前终端的前台进程组。后台进程没有所以能在你CtrlC之后继续跑。这就是为什么有些人用nohup、setsid来让程序脱离终端生命周期的原因——它们要做的第一步其实是改变进程组与会话归属。判断进程是否僵尸我最常用的组合是ps -ef看STAT列是否有Z同时看PPID指向谁。看到Z之后第一反应不是kill它而是去找父进程看父进程为什么不调用wait。3.3 进程调度的大致规则与优先级进程状态变化背后是调度器在做决策。Linux桌面和服务器上默认的调度策略是CFS完全公平调度核心思想可以简化成按权重给每个进程分配CPU时间不断选择欠CPU债最多的进程运行。每个进程维护一个虚拟运行时间实际运行越久虚拟时间增长越快于是它下次被选中的概率越低这保证了大家能轮流上CPU。nice值影响权重。nice范围是-20到19默认0数值越小优先级越高。这里有个实际限制普通用户只能把nice往大调降低优先级不能往小调只有root能把nice调到负值。如果应用层代码里需要调整优先级用setpriority或nice系统调用不要在程序里试图用静态全局变量模拟那是没用的。调度策略除了SCHED_OTHERCFS还有SCHED_FIFO和SCHED_RR两种实时策略。它们的优先级比普通进程高采用优先抢占规则。写实时应用时会用到但注意实时进程如果写了个死循环又不主动让出CPU整个系统都被它卡住。我用sched_setattr这类接口时一定会加看门狗机制防止把自己锁死。4. 进程怎么退场正常退出、异常退出与僵尸问题4.1 exit与_exit差在一步缓冲区刷新进程退出看起来都是终结但路径分两层用户态的exit和内核态的_exit。main函数里return 0C运行库会把返回值传给exitexit会做一堆用户态清理工作最后再调用_exit进入内核而_exit直接就是系统调用只做内核态收尾——关闭文件描述符、释放内存、把退出状态记录在task_struct里。关键差异就在缓冲区。stdio的输出是带缓冲的printf把内容写进用户空间的缓冲区缓冲区满了或者遇到换行终端模式、或者显式fflush才会真正write到内核。如果进程调用了exit它会负责把缓冲区内容刷出去如果直接用_exit缓冲区里的内容直接丢弃。这个差异在生产环境里经常闯祸最经典的场景是fork前的printf。看下面的代码#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(hello ); // 注意没有换行 pid_t pid fork(); if (pid 0) { _exit(0); } waitpid(pid, NULL, 0); return 0; }程序输出什么很多人的第一反应是hello 但实际屏幕上会出现两个hello 。原因很简单fork创建子进程时把父进程用户空间缓冲区的内容也复制了一份此时缓冲区里有hello 还没flush。子进程调用_exit不会刷缓冲区父进程exit时刷了一次但等等——上面代码里子进程用了_exit为什么还会出现两次你需要仔细跑一下会发现子进程直接用_exit走了内核态不刷缓冲区确实只输出一次才对。真正让问题恶化的是子进程用exit或return它会刷新从父进程那里继承来的缓冲区副本于是同一个hello 被输出两次。这个例子不是为了考倒谁而是提醒一件事在fork之前尽量保证标准输出已经flush干净养成fflush(stdout)的习惯能省掉大量排查时间。4.2 僵尸进程为什么杀不死僵尸进程是新手进程管理的第一大拦路虎。它的成因一句话就能说清子进程先终止了但父进程还没调用wait/waitpid来读取它的退出状态内核就把这个子进程的task_struct和最小化资源保留着等父进程来收尸。为什么内核非要保留这个残骸因为父进程有权知道子进程的退出码——它到底是正常退出还是被信号杀死退出码是多少。如果内核在子进程退出的一瞬间就把所有东西丢掉父进程的wait就没法返回正确答案。所以僵尸状态是一种代价很小的延期记录机制task_struct保留但没有任何内存、文件、CPU资源只有一个PID、退出码、和一点统计信息还占着位置。僵尸进程用kill -9杀不掉原因很多人理解错了不是僵尸抗拒信号而是僵尸已经死了kill只会把信号发给一个不存在的执行实体根本无从处理。杀掉僵尸的正确姿势只有一个让它的父进程调用wait/waitpid回收它。如果父进程已经死了僵尸会被1号进程收养由1号进程负责回收它会自然消失。如果你看到僵尸的PPID是1那它多半很快被清理掉不用太担心。复现僵尸很简单跑一个父进程狂sleep的子进程子进程退出后立即看ps#include stdio.h #include unistd.h #include stdlib.h int main(void) { if (fork() 0) { printf(child exiting\n); exit(0); } sleep(60); return 0; }在父进程sleep的60秒里ps -ef一查那个子进程的STAT就是ZPPID指向还在睡大觉的父进程。4.3 wait/waitpid收尸的正确姿势收尸的API是wait和waitpid。wait会阻塞到任意一个子进程退出waitpid则更精细可以指定等哪个PID也可以通过WNOHANG选项非阻塞地检查。最简单的使用模式#include stdio.h #include sys/wait.h #include unistd.h int main(void) { pid_t pid fork(); if (pid 0) { sleep(2); return 42; } int status; pid_t done waitpid(pid, status, 0); if (done pid) { if (WIFEXITED(status)) { printf(child exit code: %d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(child killed by signal %d\n, WTERMSIG(status)); } } return 0; }WIFEXITED判断是否正常退出WEXITSTATUS拿到退出码WIFSIGNALED判断是否被信号杀死WTERMSIG拿到具体信号。这几个宏掌握好wait就成功了一大半。实际项目里很少只等一个子进程。要回收多个子进程用循环while ((pid_t done waitpid(-1, status, WNOHANG)) 0) { handle_exit(done, status); }-pid参数表示任意子进程WNOHANG表示没有退出的子进程时立即返回0而不是死等。这种写法适合父进程在主循环里定期回收不影响其它逻辑。另一种常见做法是配合SIGCHLD信号子进程退出时内核给父进程发送SIGCHLD父进程在信号处理里批量waitpid确保每个子进程都被收走。需要注意信号处理函数里要调用异步信号安全函数waitpid在这些函数里有争议但很多系统实践在用。为了稳妥更推荐信号处理只设置一个标志位主循环里看到标志位再统一回收。子进程状态变化不止退出这一种也可能是被停止、被恢复。WUNTRACED和WCONTINUED这两个选项就是告诉waitpid这类状态变化也要通知。大多数时候我们用不上但调试交互式程序时可能会用到先把它们认识一下回头不慌。4.4 孤儿进程与守护进程化的前奏父进程先死了子进程怎么办在Linux里一个进程的父进程退出后它不会被直接杀死而是被1号进程收养PPID变成1。这叫孤儿进程。因为养父是1号进程它会负责收割这些孤儿的退出状态所以孤儿进程一般不会变成长久僵尸。写多进程程序时如果父进程意外崩溃你会从ps看到一堆PPID为1的进程还在跑。这是一个经典排查线索不是进程泄漏而是父进程先退场了。这时候如果希望这些子进程也退出需要靠父进程死前发出某种通知比如写入一个死亡标记文件或者通过socket通知或者靠进程组信号这些属于健壮性设计的范畴。守护进程化的第一步也是玩弄这些关系fork出子进程然后让父进程立即退出这样子进程就被1号收养再调用setsid脱离当前会话和终端必要时再fork一次避免重新获得控制终端。这篇先不展开完整守护进程流程但你要能看出它和孤儿进程逻辑是一脉相承的——进程的父子关系、进程组、会话这些基本概念不弄清后面写daemon必踩坑。5. 一个完整示例用多进程实现一个简单的任务分发器5.1 需求和设计聊了这么多原理来一个能跑起来看得见的东西。设想一个日常场景程序要处理12个任务但系统资源有限最多同时运行4个任务。如果用顺序执行太慢如果一次性fork12个并发太高可能拖垮机器。合理做法是维持一个固定并发上限做掉一个就补一个直到全部任务完成。这个模型是很多批量处理工具的基本原型也是进程池的雏形。设计思路父进程调度不干活最多同时存在MAX_CHILDREN个子进程每个子进程领到任务编号后执行完成后退出父进程用waitpid(WNOHANG)轮询回收每回收一个就补充一个新任务这个设计没有用信号简单直观方便理解forkwaitpid怎么配合。5.2 代码实现#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h #define MAX_CHILDREN 4 #define TASK_COUNT 12 void do_task(int task_no) { printf([child %d] start task %d\n, getpid(), task_no); sleep(1); printf([child %d] finish task %d\n, getpid(), task_no); exit(0); } int main(void) { int next_task 0; int running 0; while (next_task TASK_COUNT || running 0) { while (running MAX_CHILDREN next_task TASK_COUNT) { pid_t pid fork(); if (pid 0) { do_task(next_task); } else if (pid 0) { printf([parent] spawned child %d for task %d, running%d\n, pid, next_task, running 1); running; next_task; } else { perror(fork); exit(1); } } int status; pid_t done waitpid(-1, status, WNOHANG); if (done 0) { running--; printf([parent] child %d exited, running%d\n, done, running); } else if (done 0) { perror(waitpid); exit(1); } else { usleep(10000); } } printf([parent] all tasks done\n); return 0; }几个关键点do_task里的exit(0)必不可少否则子进程会从do_task返回后继续回到外层while循环和父进程抢着发号施令最终衍生出一大堆进程。这就是fork程序最常见的事故源头——子进程没有正确分流。另一个点是运行完所有任务之后循环退出条件next_task TASK_COUNT || running 0前者表示还有任务要发后者表示还有子进程要收两个条件都满足时循环结束保证父进程不会在子进程还跑着的时候就退出。5.3 跑起来的现象和我们怎么判断它工作正常编译运行后输出会呈现出明显的有序乱序一开始父进程连续fork了4个孩子处理任务0到31秒后这4个孩子陆续退出父进程马上补上新孩子处理任务4到7直到12个任务全部完成。关键观察点有三个第一任何时候running数量不超4。父进程打印的running就是当前存活子进程数如果这个值偶尔变成5、变成6说明fork之后控制流没有完全分离子进程自己也去fork了。第二ps能看到进程树。在程序运行期间打开另一个终端执行ps -ef --forest能看到每个任务的子进程都是父进程的直属后代没有出现一个子进程下面又挂着另一个子进程的情况。如果出现了嵌套fork多半是父进程分支和子进程分支没有用exit隔干净。第三程序结束前没有Z状态残留。程序最后一行打印all tasks done此时所有子进程都应该已经被回收。如果ps还能看到该程序后代里的Z进程说明waitpid循环写得太频繁或者有一个子进程没被正确处理。我自己经常会干一件小事来验证回收是否及时在程序末尾打印所有子进程是否都已经消失。最简单的方式是再fork一个监察进程让它等在旁边定期检查指定PID是否存在不过这个做法对新手可能过于花哨。更实在的建议是用ps -o pid,ppid,stat,cmd --forest反复观察几次确认没有Z并且所有进程的树状关系符合预期。5.4 这个例子再往下还能怎么改这个任务分发器只是骨架真正要落地成工具还有很多扩展点。如果任务依赖一个全局数组来取参数注意fork之后子进程拿到的是fork时刻的拷贝不是和父进程共享同一份数据。想让所有子进程同时读写一份数据得用mmap共享内存这是后面进程间通信篇的内容。如果担心子进程一直不退出可以在waitpid前面加一个超时机制用带WUNTRACED的循环配合monotonic时钟统计等待时间超时后用kill向子进程发送SIGKILL。这涉及到信号篇的内容但你现在至少知道方向。如果任务数特别多比如几十万个频繁forkexec的开销会很大这时该考虑线程池或者posix_spawn。posix_spawn可以把exec的过程合并进一次调用在fork开销敏感的嵌入式环境里非常常用。这些内容会在系列的后面展开目前这篇文章第一线的内容到这里已经相当完整——从进程的认知模型到fork/exec/wait的组合使用再到状态分析、僵尸问题、完整示例足够支撑你独立调试一个大半部分的Linux C多进程程序。最后再分享一个我自己的调试习惯每次写多进程程序第一件事是明确每个进程的职责出口。子进程分支里干完活该exit就exit该exec就exec绝不给它机会继续往父进程的逻辑里钻。第二件事是别嫌麻烦多开一个终端窗口盯着ps程序跑起来立刻用ps -ef --forest看进程树。这两个习惯帮我省下的时间比当时记下的任何API都值。
最近在整理这几年写Linux C的代码笔记第一个想聊透的就是进程管理。很多读者留言说fork会用但每次跑多进程程序都出奇奇怪怪的问题——父进程退出了子进程还在跑、ps里冒出一堆Z状态进程、fork之后printf的输出重复了。这些都是进程管理没形成体系的表现。这篇文章是进程管理系列的第一篇从进程的出生讲到退场覆盖fork、exec、wait这些核心调用再配合一个真实可跑的任务分发示例把底层原理和实操坑一次说清楚。适合刚开始写Linux C的读者也适合那些已经被僵尸进程折磨过、想系统补课的人。1. 先想清楚一个根本问题进程到底是什么1.1 从程序到进程静态文件和动态实体的差异很多教材第一句话就是进程是运行中的程序听起来像废话但仔细琢磨会发现信息量很大。程序是磁盘上躺着的ELF文件它不占CPU、不占内存、不占文件描述符就是一串静态的字节。进程则完全不同它是一套完整的运行环境有独立的地址空间、有当前执行位置、有打开的文件、有环境变量、有内核里保存的一套上下文。拿做饭打比方。程序是菜谱放在书架上落灰也不会产生任何效果进程是照着菜谱正在做菜的那个状态——锅里的温度、切好的菜、放了几勺盐这些都是运行时才有的东西。同样的菜谱十个人同时做就是十个进程它们共享的是菜谱这一份代码但各自的食材、火候、调料互不相干。这个差异在写多进程程序时非常关键。同一份可执行文件启动两次内核会创建两个task_struct代码段在物理内存里只有一份只读共享但数据段、堆栈、堆都是各自私有的。很多人第一次写fork程序时会惊讶为什么子进程改了变量父进程看不到因为那本来就不是同一个变量只是fok时复制了一份相同的值而已。1.2 task_struct内核手里的那张进程身份证从内核视角看进程就是一个结构体。Linux里这个结构体叫task_struct以前叫进程控制块PCB。它有多大不同内核版本不一样但六百多个字段是有的。这里面装着的东西大致可以分成几类标识类PID、PPID、进程组ID、会话ID状态类当前处于什么状态调度器需要读它内存类mm_struct指针指向页表、虚拟地址空间描述文件类files_struct这张表记录了进程打开了哪些文件信号类信号掩码、待处理信号队列调度类优先级、调度策略、运行时间统计亲缘关系父进程、子进程、兄弟进程的指针用户态拿不到整个task_struct但Linux提供了一面镜子/proc目录。每个进程对应/proc/ /其中status文件是人类可读的进程关键信息汇总stat文件则是内核原始统计数据。我排查进程问题时的第一习惯就是执行cat /proc/ /status先看State那行再看PPid再扫一眼VmRSS比单纯ps拿到的信息多得多。一开始学进程管理不需要把task_struct的每个字段都背下来但心里要有这张图进程不是飘在空中的抽象概念它是内核里一条具体的、随时可以被调度的记录。理解了这一点后面再看僵尸、孤儿、写时拷贝都会顺理成章。1.3 我们写C代码时其实一直在跟这几个数字打交道进程管理里最先接触的API就是getpid和getppid。getpid返回当前进程的PIDgetppid返回父进程的PID。这两个函数在进程的一生中随时可以调用不需要特权。#include stdio.h #include unistd.h int main(void) { printf(pid: %d, ppid: %d\n, getpid(), getppid()); return 0; }PID这个数字是要深入理解的。它是内核为进程分配的识别号从2开始递增1号进程是系统启动时的第一个用户态进程现在的Linux发行版上通常叫systemd。PID是会复用的如果系统里进程数太多或者某个进程的PID一直不被回收后面就可能分配出重复的PID。所谓一直被占用指的就是僵尸进程——它的PID还留在进程表里新进程无法使用这个号。还有一个容易混淆的概念是tgid。Linux里线程也被实现成task_struct所以从内核看线程和进程是同一套机制。getpid()返回的其实是线程组IDtgid而真正的线程内ID需要syscall(SYS_gettid)。这个话题到线程部分再展开现在只要记住一点进程管理里说的一个进程在Linux内核眼里和一个线程是同一类对象只是共享的内存资源不同。2. 进程从哪来fork/vfork/exec 的决策逻辑2.1 fork一次调用两次返回fork是Unix系最经典的进程创建接口。它做的事情可以概括为以当前进程为模板创建一份几乎完全相同的拷贝。难点在于这个调用一旦成功调用现场就分裂了——父进程的fork返回子进程的PID子进程的fork返回0。#include stdio.h #include unistd.h #include sys/types.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { printf(child: my pid is %d, ppid is %d\n, getpid(), getppid()); } else { printf(parent: child pid is %d, my pid is %d\n, pid, getpid()); } return 0; }新手最容易漏掉的是先判断pid 0。fork失败的常见原因是进程数达到系统上限但应用层能做的很少该检查还是要检查。我见过不少线上事故就是因为fork后没判断返回值直接拿pid当有效值用最后子进程分支没走、父进程逻辑整体错乱。fork之后两个进程的执行位置是相同的都停在fork返回语句之后的那一行。所以代码必须用if/else把父子逻辑严格分开。这不是风格问题而是fork模型的硬性要求——如果你不写else父进程和子进程会同时往下执行任务就重复了。2.2 写时拷贝COW到底在优化什么早期的Unix fork实现非常粗暴把父进程的整个地址空间复制一份给子进程。分配物理内存、复制页表、逐页拷贝数据一套下来开销巨大。但后来人们发现一个规律绝大多数fork之后紧接着就是exec——exec会丢弃当前地址空间并加载一个全新程序前面辛辛苦苦复制的数据全都白费了。现代Linux用写时拷贝Copy on Write来解决这个问题。fork的时候父子进程先共享同一个物理内存页并把这块页标记为只读。双方都只读时相安无事。一旦父或子尝试写入这个页CPU触发缺页异常内核才真正分配一个新物理页把那块内存的内容复制过去再更新页表。这就是写时拷贝的含义等到要写的那一刻才复制。用代码理解COW下面的程序里fork之后unused是一个从未被修改的局部变量它可能始终和父进程共享物理页而counter被子进程修改触发一次真正复制。#include stdio.h #include unistd.h int main(void) { long unused 0; long counter 0; pid_t pid fork(); if (pid 0) { for (int i 0; i 100000; i) counter; printf(child counter: %ld\n, counter); } else { counter 500; printf(parent counter: %ld\n, counter); } return 0; }COW的意义不只是快它还保证了一个核心语义子进程看到的内存是父进程在fork时刻的快照之后双方各自修改互不可见。有人说COW让fork变成了假复制这种理解不对——语义上仍然是完整拷贝只是实现上把复制操作推迟到了必要时刻。该隔离的照样隔离。2.3 vfork一个很容易被误解的历史遗留vfork在刚接触的时候很容易搞混因为它的行为太反直觉了。它创建子进程时不复制地址空间子进程直接使用父进程的内存并且父进程会被挂起直到子进程调用execve或exit。换句话说子进程对变量的修改父进程能看到——这和fork的隔离语义完全相反。为什么要设计这样一个危险的东西因为比fork更老的内核连COW都没有fork复制开销实在太大而有些场景就是fork完立刻exec。vfork优化掉了这个复制过程。如今COW已经让fork足够廉价vfork的用武之地非常小除非是在那些内存极度受限的嵌入式环境里或者某个实时系统对fork的延迟极其敏感。vfork最著名的坑是子进程在main函数里直接return。return会执行栈帧清理最终还会触发exit相关的用户态流程这会把子进程的栈操作到父进程的内存上因为两者共享地址空间。我见过一次诡异的崩溃查了半天发现就是vforkreturn导致的。所以原则很简单除非非常明确自己在干什么否则一律用fork如果用了vfork子进程里必须马上exec或者exit不要有任何多余动作。2.4 exec族函数换壳不换核fork负责生exec负责变。exec系列函数会把当前进程的内存映像整个替换掉——加载一个新程序重新初始化堆栈、数据段、代码段然后从新程序的入口开始执行。但注意进程的PID没有变文件描述符表默认也保留除非显式打了O_CLOEXEC标记信号掩码之类的属性也会保留。所以从效果看exec是给一个进程换了层壳而不是新建进程。#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { execlp(ls, ls, -l, NULL); perror(execlp); _exit(1); } waitpid(pid, NULL, 0); return 0; }execlp里的p表示会通过PATH环境变量搜索可执行文件l表示参数以列表形式传递参数列表必须以NULL结尾。还有execv系列参数用字符串数组传。初学阶段把它们分成两类记就够了带p的会去PATH里找带l的用可变参数带v的用数组。实际上它们最终都是调用execve这个系统调用。子进程exec成功时原来的代码不再执行所以exec返回值只在失败时才返回-1。这里必须强制检查失败分支否则一旦exec失败子进程会继续往下执行通常直接_exit(1)是最稳妥的处理。exec还有一个隐性问题新程序启动时继承了大量旧的属性——环境变量、打开的文件描述符、信号配置。如果不想要某个fd被继承必须在open时加O_CLOEXEC或者在exec前手动close。多进程写网络服务时这个细节决定你能不能把监听socket永远留在父进程手里。3. 进程活着的时候都会经历什么状态流转与调度暗示3.1 五状态模型之外Linux还有两个隐藏状态教科书讲进程状态通常给一个五状态模型新建、就绪、运行、阻塞、终止。这个模型能帮助理解大框架但放到Linux上就不够用了。用ps看真实系统的进程状态你会看到R、S、D、T、Z、X这些字母它们对应Linux内核里的几类task_struct状态。TASK_RUNNING对应R。既包含正在CPU上运行的进程也包含已经在运行队列里排队、随时可以运行的进程。TASK_INTERRUPTIBLE对应S。可中断睡眠。进程在等待某个条件比如等待socket数据、等互斥锁但可以被信号唤醒。TASK_UNINTERRUPTIBLE对应D。不可中断睡眠主要在等待IO完成磁盘读写、NFS等。这个状态拒绝处理信号kill不掉。TASK_STOPPED / TASK_TRACED对应T。进程被暂停比如收到SIGSTOP或者正在被调试器停住。EXIT_ZOMBIE对应Z。进程已经终止但还没被父进程回收。我最想单独拎出来讲的是D状态。很多新手第一次看到D状态的进程杀不掉以为系统中毒了。其实D状态往往是磁盘IO卡死的信号进程在内核里等着一个读写操作返回这个操作迟迟不回来内核没法安全地把进程切到可中断状态。这种情况如果持续很久不消失通常要检查存储系统是否出问题。3.2 从ps输出的STAT一列看进程处境ps aux输出里的STAT看着只是一串字母其实是读懂进程状态的密码。单个字母主要是状态字母含义Rrunning在运行队列中Ssleeping可中断睡眠Duninterruptible sleep不可中断睡眠Tstopped停止或被跟踪Zzombie僵尸进程Xdead终止且不会出现在正常ps里STAT字段末尾还经常跟着附加符号。表示这个进程在前台进程组s表示它是会话首进程通常是终端对应的shelll表示多线程表示高优先级N表示低优先级。从前台后台看这个问题最直观。在bash里直接跑一个程序它属于前台进程组STAT带如果用放到后台就没有。这个区分和信号传递有直接关系你按下CtrlC内核并不会给所有进程发SIGINT而是只发给当前终端的前台进程组。后台进程没有所以能在你CtrlC之后继续跑。这就是为什么有些人用nohup、setsid来让程序脱离终端生命周期的原因——它们要做的第一步其实是改变进程组与会话归属。判断进程是否僵尸我最常用的组合是ps -ef看STAT列是否有Z同时看PPID指向谁。看到Z之后第一反应不是kill它而是去找父进程看父进程为什么不调用wait。3.3 进程调度的大致规则与优先级进程状态变化背后是调度器在做决策。Linux桌面和服务器上默认的调度策略是CFS完全公平调度核心思想可以简化成按权重给每个进程分配CPU时间不断选择欠CPU债最多的进程运行。每个进程维护一个虚拟运行时间实际运行越久虚拟时间增长越快于是它下次被选中的概率越低这保证了大家能轮流上CPU。nice值影响权重。nice范围是-20到19默认0数值越小优先级越高。这里有个实际限制普通用户只能把nice往大调降低优先级不能往小调只有root能把nice调到负值。如果应用层代码里需要调整优先级用setpriority或nice系统调用不要在程序里试图用静态全局变量模拟那是没用的。调度策略除了SCHED_OTHERCFS还有SCHED_FIFO和SCHED_RR两种实时策略。它们的优先级比普通进程高采用优先抢占规则。写实时应用时会用到但注意实时进程如果写了个死循环又不主动让出CPU整个系统都被它卡住。我用sched_setattr这类接口时一定会加看门狗机制防止把自己锁死。4. 进程怎么退场正常退出、异常退出与僵尸问题4.1 exit与_exit差在一步缓冲区刷新进程退出看起来都是终结但路径分两层用户态的exit和内核态的_exit。main函数里return 0C运行库会把返回值传给exitexit会做一堆用户态清理工作最后再调用_exit进入内核而_exit直接就是系统调用只做内核态收尾——关闭文件描述符、释放内存、把退出状态记录在task_struct里。关键差异就在缓冲区。stdio的输出是带缓冲的printf把内容写进用户空间的缓冲区缓冲区满了或者遇到换行终端模式、或者显式fflush才会真正write到内核。如果进程调用了exit它会负责把缓冲区内容刷出去如果直接用_exit缓冲区里的内容直接丢弃。这个差异在生产环境里经常闯祸最经典的场景是fork前的printf。看下面的代码#include stdio.h #include unistd.h #include sys/wait.h int main(void) { printf(hello ); // 注意没有换行 pid_t pid fork(); if (pid 0) { _exit(0); } waitpid(pid, NULL, 0); return 0; }程序输出什么很多人的第一反应是hello 但实际屏幕上会出现两个hello 。原因很简单fork创建子进程时把父进程用户空间缓冲区的内容也复制了一份此时缓冲区里有hello 还没flush。子进程调用_exit不会刷缓冲区父进程exit时刷了一次但等等——上面代码里子进程用了_exit为什么还会出现两次你需要仔细跑一下会发现子进程直接用_exit走了内核态不刷缓冲区确实只输出一次才对。真正让问题恶化的是子进程用exit或return它会刷新从父进程那里继承来的缓冲区副本于是同一个hello 被输出两次。这个例子不是为了考倒谁而是提醒一件事在fork之前尽量保证标准输出已经flush干净养成fflush(stdout)的习惯能省掉大量排查时间。4.2 僵尸进程为什么杀不死僵尸进程是新手进程管理的第一大拦路虎。它的成因一句话就能说清子进程先终止了但父进程还没调用wait/waitpid来读取它的退出状态内核就把这个子进程的task_struct和最小化资源保留着等父进程来收尸。为什么内核非要保留这个残骸因为父进程有权知道子进程的退出码——它到底是正常退出还是被信号杀死退出码是多少。如果内核在子进程退出的一瞬间就把所有东西丢掉父进程的wait就没法返回正确答案。所以僵尸状态是一种代价很小的延期记录机制task_struct保留但没有任何内存、文件、CPU资源只有一个PID、退出码、和一点统计信息还占着位置。僵尸进程用kill -9杀不掉原因很多人理解错了不是僵尸抗拒信号而是僵尸已经死了kill只会把信号发给一个不存在的执行实体根本无从处理。杀掉僵尸的正确姿势只有一个让它的父进程调用wait/waitpid回收它。如果父进程已经死了僵尸会被1号进程收养由1号进程负责回收它会自然消失。如果你看到僵尸的PPID是1那它多半很快被清理掉不用太担心。复现僵尸很简单跑一个父进程狂sleep的子进程子进程退出后立即看ps#include stdio.h #include unistd.h #include stdlib.h int main(void) { if (fork() 0) { printf(child exiting\n); exit(0); } sleep(60); return 0; }在父进程sleep的60秒里ps -ef一查那个子进程的STAT就是ZPPID指向还在睡大觉的父进程。4.3 wait/waitpid收尸的正确姿势收尸的API是wait和waitpid。wait会阻塞到任意一个子进程退出waitpid则更精细可以指定等哪个PID也可以通过WNOHANG选项非阻塞地检查。最简单的使用模式#include stdio.h #include sys/wait.h #include unistd.h int main(void) { pid_t pid fork(); if (pid 0) { sleep(2); return 42; } int status; pid_t done waitpid(pid, status, 0); if (done pid) { if (WIFEXITED(status)) { printf(child exit code: %d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(child killed by signal %d\n, WTERMSIG(status)); } } return 0; }WIFEXITED判断是否正常退出WEXITSTATUS拿到退出码WIFSIGNALED判断是否被信号杀死WTERMSIG拿到具体信号。这几个宏掌握好wait就成功了一大半。实际项目里很少只等一个子进程。要回收多个子进程用循环while ((pid_t done waitpid(-1, status, WNOHANG)) 0) { handle_exit(done, status); }-pid参数表示任意子进程WNOHANG表示没有退出的子进程时立即返回0而不是死等。这种写法适合父进程在主循环里定期回收不影响其它逻辑。另一种常见做法是配合SIGCHLD信号子进程退出时内核给父进程发送SIGCHLD父进程在信号处理里批量waitpid确保每个子进程都被收走。需要注意信号处理函数里要调用异步信号安全函数waitpid在这些函数里有争议但很多系统实践在用。为了稳妥更推荐信号处理只设置一个标志位主循环里看到标志位再统一回收。子进程状态变化不止退出这一种也可能是被停止、被恢复。WUNTRACED和WCONTINUED这两个选项就是告诉waitpid这类状态变化也要通知。大多数时候我们用不上但调试交互式程序时可能会用到先把它们认识一下回头不慌。4.4 孤儿进程与守护进程化的前奏父进程先死了子进程怎么办在Linux里一个进程的父进程退出后它不会被直接杀死而是被1号进程收养PPID变成1。这叫孤儿进程。因为养父是1号进程它会负责收割这些孤儿的退出状态所以孤儿进程一般不会变成长久僵尸。写多进程程序时如果父进程意外崩溃你会从ps看到一堆PPID为1的进程还在跑。这是一个经典排查线索不是进程泄漏而是父进程先退场了。这时候如果希望这些子进程也退出需要靠父进程死前发出某种通知比如写入一个死亡标记文件或者通过socket通知或者靠进程组信号这些属于健壮性设计的范畴。守护进程化的第一步也是玩弄这些关系fork出子进程然后让父进程立即退出这样子进程就被1号收养再调用setsid脱离当前会话和终端必要时再fork一次避免重新获得控制终端。这篇先不展开完整守护进程流程但你要能看出它和孤儿进程逻辑是一脉相承的——进程的父子关系、进程组、会话这些基本概念不弄清后面写daemon必踩坑。5. 一个完整示例用多进程实现一个简单的任务分发器5.1 需求和设计聊了这么多原理来一个能跑起来看得见的东西。设想一个日常场景程序要处理12个任务但系统资源有限最多同时运行4个任务。如果用顺序执行太慢如果一次性fork12个并发太高可能拖垮机器。合理做法是维持一个固定并发上限做掉一个就补一个直到全部任务完成。这个模型是很多批量处理工具的基本原型也是进程池的雏形。设计思路父进程调度不干活最多同时存在MAX_CHILDREN个子进程每个子进程领到任务编号后执行完成后退出父进程用waitpid(WNOHANG)轮询回收每回收一个就补充一个新任务这个设计没有用信号简单直观方便理解forkwaitpid怎么配合。5.2 代码实现#include stdio.h #include stdlib.h #include unistd.h #include sys/wait.h #define MAX_CHILDREN 4 #define TASK_COUNT 12 void do_task(int task_no) { printf([child %d] start task %d\n, getpid(), task_no); sleep(1); printf([child %d] finish task %d\n, getpid(), task_no); exit(0); } int main(void) { int next_task 0; int running 0; while (next_task TASK_COUNT || running 0) { while (running MAX_CHILDREN next_task TASK_COUNT) { pid_t pid fork(); if (pid 0) { do_task(next_task); } else if (pid 0) { printf([parent] spawned child %d for task %d, running%d\n, pid, next_task, running 1); running; next_task; } else { perror(fork); exit(1); } } int status; pid_t done waitpid(-1, status, WNOHANG); if (done 0) { running--; printf([parent] child %d exited, running%d\n, done, running); } else if (done 0) { perror(waitpid); exit(1); } else { usleep(10000); } } printf([parent] all tasks done\n); return 0; }几个关键点do_task里的exit(0)必不可少否则子进程会从do_task返回后继续回到外层while循环和父进程抢着发号施令最终衍生出一大堆进程。这就是fork程序最常见的事故源头——子进程没有正确分流。另一个点是运行完所有任务之后循环退出条件next_task TASK_COUNT || running 0前者表示还有任务要发后者表示还有子进程要收两个条件都满足时循环结束保证父进程不会在子进程还跑着的时候就退出。5.3 跑起来的现象和我们怎么判断它工作正常编译运行后输出会呈现出明显的有序乱序一开始父进程连续fork了4个孩子处理任务0到31秒后这4个孩子陆续退出父进程马上补上新孩子处理任务4到7直到12个任务全部完成。关键观察点有三个第一任何时候running数量不超4。父进程打印的running就是当前存活子进程数如果这个值偶尔变成5、变成6说明fork之后控制流没有完全分离子进程自己也去fork了。第二ps能看到进程树。在程序运行期间打开另一个终端执行ps -ef --forest能看到每个任务的子进程都是父进程的直属后代没有出现一个子进程下面又挂着另一个子进程的情况。如果出现了嵌套fork多半是父进程分支和子进程分支没有用exit隔干净。第三程序结束前没有Z状态残留。程序最后一行打印all tasks done此时所有子进程都应该已经被回收。如果ps还能看到该程序后代里的Z进程说明waitpid循环写得太频繁或者有一个子进程没被正确处理。我自己经常会干一件小事来验证回收是否及时在程序末尾打印所有子进程是否都已经消失。最简单的方式是再fork一个监察进程让它等在旁边定期检查指定PID是否存在不过这个做法对新手可能过于花哨。更实在的建议是用ps -o pid,ppid,stat,cmd --forest反复观察几次确认没有Z并且所有进程的树状关系符合预期。5.4 这个例子再往下还能怎么改这个任务分发器只是骨架真正要落地成工具还有很多扩展点。如果任务依赖一个全局数组来取参数注意fork之后子进程拿到的是fork时刻的拷贝不是和父进程共享同一份数据。想让所有子进程同时读写一份数据得用mmap共享内存这是后面进程间通信篇的内容。如果担心子进程一直不退出可以在waitpid前面加一个超时机制用带WUNTRACED的循环配合monotonic时钟统计等待时间超时后用kill向子进程发送SIGKILL。这涉及到信号篇的内容但你现在至少知道方向。如果任务数特别多比如几十万个频繁forkexec的开销会很大这时该考虑线程池或者posix_spawn。posix_spawn可以把exec的过程合并进一次调用在fork开销敏感的嵌入式环境里非常常用。这些内容会在系列的后面展开目前这篇文章第一线的内容到这里已经相当完整——从进程的认知模型到fork/exec/wait的组合使用再到状态分析、僵尸问题、完整示例足够支撑你独立调试一个大半部分的Linux C多进程程序。最后再分享一个我自己的调试习惯每次写多进程程序第一件事是明确每个进程的职责出口。子进程分支里干完活该exit就exit该exec就exec绝不给它机会继续往父进程的逻辑里钻。第二件事是别嫌麻烦多开一个终端窗口盯着ps程序跑起来立刻用ps -ef --forest看进程树。这两个习惯帮我省下的时间比当时记下的任何API都值。
