1. 先把“进程”这个词拆开看1.1 教科书那句话漏掉了什么“进程是程序的一次执行”——这句话我背了很多年但真正让我在排障时不慌的是把进程当成内核里一个实实在在的数据结构来看待。你翻开内核源码fork一个子进程时内核并没有“运行”任何东西它做的事情非常朴素分配一块内存、填一堆字段、把页表项的写权限抹掉、把新的任务挂进调度队列。所谓“进程”在源码层面就是一个task_struct加上它指向的地址空间、文件表、信号表、命名空间这一整套资源的集合体。理解到这一层很多现场问题就有了答案为什么fork之后 RSS 涨了但物理内存没涨、为什么杀不掉的进程多半卡在不可中断睡眠、为什么容器里的 PID 和宿主机对不上。这篇内容适合已经会写代码、但没系统读过内核进程相关源码的朋友也适合被线上进程问题折腾过、想补上底层认知的运维和后台开发。1.2 我习惯把进程拆成四个部件读源码最怕一上来就啃结构体定义几万个字段堆在那里看着就劝退。我自己的做法是先做一次“分治”把进程拆成四个互相独立的部件然后顺着每个部件去定位它在源码里的落点。第一个是身份与调度实体对应task_struct本身它记录了 PID、状态、优先级、调度实体是调度器眼中真正被调度的单位。第二个是地址空间对应mm_struct里面挂着 VMA 链表和页表根决定了进程能看到哪些内存。第三个是执行上下文包括通用寄存器、栈指针、程序计数器保存在内核栈和thread_struct里切换进程的时候换的就是这一套。第四个是资源账本files_struct、fs_struct、sighand_struct、nsproxy这些指针指向的共享结构决定了这个进程打开了哪些文件、在哪个目录、屏蔽了哪些信号。这四个部件之间的关系用一句话概括就是task_struct是树干其余三个是挂在树上的枝。线程和进程的区别本质上是这四根枝里地址空间和资源账本有没有被共享。你调pthread_create最终落到内核就是一个带了CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND | CLONE_THREAD这些标志的clone新任务拿到了一份独立的task_struct但mm和files指针直接指向父任务的那一份tgid也和父任务相同。这也是为什么top里看到的线程 CPU 占用会归到同一个进程下面——它们本来就是同一个“线程组”里的成员。把这条线索理清楚后面读copy_process的时候就不会被一堆if (clone_flags CLONE_XXX)绕晕。提示别急着背字段名先把“哪些字段是进程私有的、哪些是指向共享结构的指针”这件事分清楚读源码的效率会高一个量级。2. task_struct进程的全部家当都在这一个结构体里2.1 从 sched.h 一路读进去task_struct定义在include/linux/sched.h早年的版本是一个巨大的、平铺直叙的结构体几千行字段堆在同一个花括号里。后来内核做了拆分把调度相关、信号相关、内存相关的字段拆到include/linux/sched/目录下的一系列头文件里再用匿名的嵌套结构体嵌回去写法大致是struct { ... } se;这种形式直接访问字段名不变但可读性好很多。你在代码里写p-se.vruntime和写p-se是两回事前者是嵌套结构里的成员后者才是整个子结构。第一次读的时候容易在这上面卡壳以为某个字段找不到定义其实是藏在另一个头文件里。结构体里字段量大但真正高频打交道的就那么几组。__state记录运行状态pid、tgid记录进程号和线程组号mm和active_mm管地址空间files、fs、sighand、signal管资源se、rt、dl分别是公平调度、实时调度、截止时间调度三种调度器的实体thread保存架构相关的寄存器上下文stack指向内核栈parent、children、sibling把整棵进程树串起来。还有一个很容易被忽略的flags里面塞的是PF_EXITING、PF_KTHREAD、PF_VCPU这类标志位判断一个任务是不是内核线程、是不是正在退出靠的就是它。2.2 那几个决定命运的状态字段状态字段值得单独拎出来讲因为线上排查时ps里那个字母几乎是第一手线索。源码里定义的取值有一串TASK_RUNNING表示可运行或正在运行注意它包含“在运行队列里排队”这一层含义不是只有“占着 CPU”才叫 running。TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE是两种睡眠前者能被信号叫醒后者不能这就是ps里S和D的由来。__TASK_STOPPED对应收到SIGSTOP之后的状态EXIT_ZOMBIE是已经退出但父进程还没回收EXIT_DEAD是连最后一点残留都该被释放了。另外还有TASK_KILLABLE它是不可中断睡眠的一个变种允许被致命信号打断写驱动或者做 IO 等待的时候用它比用纯TASK_UNINTERRUPTIBLE更友好。状态不是随便赋值就能改的内核提供了set_current_state()、__set_current_state()、set_special_state()这几组接口区别在于有没有内存屏障。如果你手写current-__state TASK_INTERRUPTIBLE;然后直接调schedule()在弱内存序的架构上有概率出现“唤醒丢失”——对方已经把状态改成 RUNNING 并发出了唤醒你这边又把状态覆盖回睡眠然后就睡死过去了。正确写法是先设状态、再检查条件、再决定要不要睡这个顺序不能颠倒。我在早期写一个字符设备驱动时踩过这个坑现象是压力测试下偶发挂死单步调试永远复现不了最后对着set_current_state的注释才反应过来是屏障的问题。2.3 字段读错就会误判的三个地方第一处是mm和active_mm。普通用户进程这两个指针通常指向同一个mm_struct但内核线程的mm是NULL它借用上一个被调度出去的进程的active_mm来跑靠active_mm的引用计数保证这块地址空间不被释放。所以你在内核线程里访问用户态指针大概率直接崩因为那本来就不是它的地址空间。第二处是pid和tgid。主线程两者相等子线程的pid是独立的但tgid等于主线程的pid。kill()系统调用传的其实是tgid语义走的是kill_pid_info那一套所以你在命令行kill一个多线程进程的某个线程号很可能整个进程都收到信号。第三处是parent和real_parent。real_parent是生物学意义上的父进程parent是当前实际负责回收它的进程被ptrace跟踪或者被subreaper接管的时候这两个会不一样。3. fork 的内核路径一次拷贝半推半就3.1 从系统调用入口到 kernel_clone用户态调fork()陷入内核后走的是SYSCALL_DEFINE0(fork)它本身几乎不做事情把参数打包成一个kernel_clone_args结构体然后交给kernel_clone()。vfork、clone、clone3最后也都汇到这一个函数里差别只在clone_flags和栈指针这些参数上。kernel_clone里做几件事先做参数合法性检查然后调copy_process拿到新的task_struct接着如果发现需要唤醒CLONE_STOPPED之类就把新任务挂到运行队列最后返回新任务的pid。整个链路短得有点出人意料真正的重活全在copy_process里面。copy_process在kernel/fork.c里是一个几百行的长函数我数过它里面的失败跳转标签一路goto bad_fork_xxx排下去有十几个。这个写法不是为了炫技而是因为每一步都申请了资源任何一步失败都必须把前面申请的全部还回去。你读这个函数的时候正好可以顺着这些goto标签反向理解“创建一个进程究竟占用了哪些资源”——每一个bad_fork_free_xxx标签对应的都是一类需要归还的东西这比正向背资源清单有效得多。3.2 copy_process 的十二个动作我把关键步骤按顺序列一下方便对照源码看dup_task_struct复制父进程的task_struct并分配新的内核栈。检查RLIMIT_NPROC限制、pidscgroup 配额、用户进程数上限。sched_fork重置调度实体把新任务的状态设成TASK_NEW避免它立刻被调度。copy_semundo、copy_files、copy_fs、copy_sighand、copy_signal按CLONE_*标志决定是共享还是复制。copy_mm带CLONE_VM就共享mm否则复制一份新的地址空间。copy_namespaces处理 PID、网络、挂载等命名空间。copy_io处理 IO 上下文。copy_thread设置新任务的寄存器上下文让它从ret_from_fork开始执行。alloc_pid分配 PID 和 PID 命名空间相关结构。sched_cgroup_fork、cgroup_can_fork挂进对应的控制组。把新任务挂到父进程的children链表建立进程树关系。wake_up_new_task把任务放进运行队列等待调度。这里有个细节值得留意dup_task_struct只是浅拷贝了结构体的字节指针字段全都指回父进程同一份对象真正的“该复制还是该共享”判断是后面那串copy_xxx函数按标志位做的。所以别被“复制”这个词骗了内核在这里做的是一份精细的分家协议而不是整体深拷贝。也正因为是浅拷贝copy_process里任何一步失败都得小心别把父进程的结构体改坏了这也是它为什么写得那么啰嗦的原因。3.3 写时复制到底省了哪一笔钱fork后面紧跟着exec这是 shell 里最常见的组合。如果fork老老实实把父进程几百兆的地址空间全拷一遍然后exec立刻又把这份拷贝整个丢弃那这笔开销纯属浪费。写时复制就是冲着这个场景设计的。copy_mm走dup_mm→dup_mmap遍历父进程所有的 VMA给子进程建一套新的 VMA 描述同时把父子双方的页表项都改成只读并把物理页的引用计数加一。注意这里改的是父子双方的权限不只是子进程的因为要保证任何一方写入都会触发缺页。真正写入的时候CPU 抛一个页错误内核的do_wp_page接手检查这个页的引用计数如果只有当前进程在用直接恢复可写就行连拷贝都免了如果多个进程共享才分配新页、复制内容、更新页表。这一套下来fork的代价从“复制所有物理内存”降到了“复制页表和 VMA 描述”虽然页表本身也不便宜但通常小一到两个数量级。有个反直觉的点fork之后进程的 RSS 统计往往会涨因为页表页和 VMA 结构本身是实打实新分配的但smaps里的Private_Dirty不会跟着涨共享页还挂在Shared_Clean里。搞不清这一点很容易误以为内存泄漏了。注意vfork走的是另一条路父进程会被挂起直到子进程exec或退出子进程直接借用父进程的地址空间。它的语义比fork危险得多子进程在exec之前对栈上变量的修改会污染父进程也绝对不允许在vfork之后return。3.4 返回值为什么父进程有子进程没有fork一次调用两次返回父进程拿到子进程的 PID子进程拿到 0这个“魔法”在源码里其实很朴素。copy_thread会把新任务的指令指针设置到一个固定入口x86_64 上通常是ret_from_fork同时把通用寄存器里的返回值寄存器rax清零所以子进程从内核返回到用户态时读到的返回值天然就是 0。而父进程走的是正常返回路径返回值来自kernel_clone里alloc_pid拿到的那个数字。两条路径在copy_thread分岔之后各走各的这就是“一次调用两次返回”的全部真相。理解了这一点clone里那些传函数指针、传栈顶地址的花活也就好懂了——本质都是通过修改新任务的寄存器上下文让它从指定位置开始跑。4. execve把地址空间推倒重建4.1 ELF 是怎么被搬进内存的fork造出来的子进程是个“克隆体”要变成真正的新程序还得走execve。入口是do_execveat_common它先把用户态传进来的文件名、argv、envp拷贝到内核空间这一步用copy_strings逐页拷防止用户态指针在中途被改掉组装成linux_binprm然后走search_binary_handler依次询问注册过的二进制格式处理器能不能处理。ELF 的处理函数是load_elf_binary它做几件关键的事读 ELF 头校验魔数、解析程序头表找到PT_LOAD段、调flush_old_exec把旧的地址空间整个卸掉、按段的权限调vm_mmap建立新的映射、对PT_INTERP段找到动态链接器并把它也映射进来、最后把入口地址写进pt_regs的ip字段。flush_old_exec这个函数名起得很到位它做的事情就是把current-mm换成一个空的、全新的地址空间旧的mm_struct引用计数减一没人用了就释放。从这一刻起进程看到的内存世界彻底换了一套。紧接着setup_arg_pages把argv、envp和auxv搬到新用户栈的顶部然后start_thread设置sp、ip和段寄存器返回用户态程序正式开始执行。整个过程中进程的 PID 一直没变task_struct还是那一个变的只是地址空间、文件表里被标记了CLOEXEC的那些描述符、信号处置表这些“内容物”。这也是为什么execve之后进程的启动时间、运行时长这些统计还接着原来的算它确实是同一个进程。4.2 argv 和 environ 落在栈顶的那几百字节argv和envp在内存里的布局值得单独看一眼。栈顶往下依次是参数字符串本身、环境变量字符串、auxv键值对、envp指针数组、argv指针数组最后才是argc。auxv里塞的是内核传给动态链接器的信息包括页大小、AT_ENTRY程序入口、AT_PHDR程序头地址、AT_RANDOM一个 16 字节的随机种子、AT_EXECFN可执行文件路径等。搞二进制安全或者写调试器的人对这个布局会很熟因为栈溢出利用、ROP 链构造都建立在这套布局上。日常写应用的人知道有这么回事就够了但排障时用得上如果某个程序启动就崩在动态链接阶段用gdb看栈顶那块内存auxv里缺了AT_PHDR或者值明显不对基本就能判断是加载器没能正确找到程序头。4.3 文件描述符与信号处置的继承规则execve之后文件描述符默认全部保留这经常导致一个经典问题父进程监听了一个端口fork出子进程子进程exec成别的程序端口还是被占着因为那个监听 fd 被继承下去了。解决办法是在创建 fd 的时候加上O_CLOEXEC内核会在exec时自动关掉。dup2也有对应的dup3可以带这个标志。我见过一个线上案例某个服务重启之后一直提示端口被占用lsof查不到明显的监听进程最后发现是一个早就该退出的辅助进程里残留了继承下来的 fd而它的父进程已经换了三轮。从那之后我们内部规范里写死了一条除了标准输入输出所有 fd 一律带CLOEXEC。信号处置表在exec时的规则是被设置为“忽略”的信号继续保持忽略被安装过处理函数的信号全部恢复成默认动作。这个规则设计得挺合理因为处理函数的地址在新地址空间里根本不存在不重置就是野指针。这也解释了一个常见坑父进程用signal(SIGPIPE, SIG_IGN)忽略了管道破裂fork加exec出来的子进程默认也是忽略状态导致子进程里写断开的管道不会收到信号而是直接拿到EPIPE错误返回代码里如果没检查返回值就会出现“静默丢数据”的现象。5. 状态、调度与上下文切换5.1 状态迁移不是四个字能讲完的进程状态的迁移路径实际比教科书上画的那几条线复杂。一个新建的任务从copy_process出来时是TASK_NEWwake_up_new_task之后进运行队列变成TASK_RUNNING。调度器选中它、切上去执行状态不变还是 RUNNING——注意 RUNNING 同时覆盖“在队列里”和“在 CPU 上”两种情况想区分得看它是不是rq-curr。等待资源时调schedule()之前把自己设成 INTERRUPTIBLE 或 UNINTERRUPTIBLE等条件满足被wake_up_process唤醒状态回到 RUNNING。收到SIGSTOP进 STOPPEDSIGCONT回来。最后调do_exit状态先变成EXIT_ZOMBIE父进程wait之后被release_task释放才算走到EXIT_DEAD的终点。这里最容易误解的是“睡眠”和“阻塞”的关系。从内核视角看只有“在不在运行队列里”这一件事是确定的睡眠是主动让出 CPU 并等待唤醒阻塞是别人观察到的一种现象。一个进程可能一直处于 RUNNING 状态但排在队列末尾迟迟拿不到 CPU用户看到的现象是“卡住了”实际上它一次都没睡。判断到底是哪种/proc/PID/status里的State字段和voluntary_ctxt_switches、nonvoluntary_ctxt_switches两项计数器组合起来看比较靠谱自愿切换多说明一直主动让出非自愿切换多说明是被调度器抢走的也就是在抢 CPU 而不是在等 IO。5.2 switch_to 换掉的到底是哪些寄存器上下文切换的入口是__schedule它挑出下一个要跑的任务调context_switch里面分两步switch_mm_irqs_off换地址空间包括切换页表根寄存器、刷新 TLB 相关状态switch_to换寄存器上下文。switch_to是个架构相关的宏在 x86_64 上要保存和恢复的是被调用者保存寄存器这一组rbx、rbp、r12到r15再加上栈指针rsp。调用者保存的那些寄存器由编译器在调用点自己处理不需要内核操心。浮点/SIMD 寄存器走的是懒加载策略只有真正用到的时候才通过fpu__restore从内存恢复省掉不必要的开销。换栈这件事值得单独说。每个任务有自己的内核栈switch_to里栈指针一换当前执行流就落到了另一个任务的栈上接下来的ret会返回到那个任务上次被切走时保存的返回地址于是一路返回到它当初调schedule()的地方看起来就像它刚从这个函数返回一样。这个设计非常巧妙切换逻辑本身不需要关心“从哪继续执行”靠栈上保存的返回地址自然解决。代价是内核栈不能太大x86_64 上默认 16KB四页写内核代码时递归和大的栈上数组都是禁忌一旦溢出就会静默踩坏相邻内存排查起来极其痛苦。5.3 一次切换的真实成本上下文切换的成本分几块直接的寄存器保存恢复几百个周期地址空间切换导致的 TLB 失效这块往往才是大头尤其是工作集大的进程缓存局部性被破坏切回来之后要重新预热 L1/L2还有调度器本身的选任务开销在任务数很多的时候不可忽略。我做过一个粗略的对比测试在一个小规模压测环境里把线程数从几十拉到几千单纯靠vmstat里的cs列看每秒上下文切换从几万涨到几十万应用吞吐几乎没变但 CPU 的sy占比翻了一倍多。结论很直接能用事件驱动解决的并发别用海量线程硬顶。系统层面有几处可以调的旋钮。/proc/sys/kernel/sched_min_granularity_ns控制一个任务最少跑多久才允许被抢占调大能减少切换次数但会增加延迟。sched_wakeup_granularity_ns影响唤醒抢占的阈值。绑核taskset、cpuset能减少跨核迁移带来的缓存失效。这些参数没有放之四海皆准的值得结合业务是延迟敏感还是吞吐敏感来定盲目照抄网上的数值往往会适得其反。6. 进程的退场与善后6.1 do_exit 里那串 exit_xxx进程主动退出或者被信号杀死最后都会走到do_exit。这个函数里有一串整齐的exit_xxx调用exit_mm释放地址空间、exit_sem处理信号量等待、exit_files关文件、exit_fs释放文件系统上下文、exit_task_namespaces退出命名空间、exit_notify通知父进程。顺序是有讲究的比如必须在地址空间还在的时候才能释放某些资源所以不能随便调换。exit_notify里做两件事给父进程发SIGCHLD如果父进程没设SA_NOCLDWAIT把自己的子进程重新挂靠给别人。状态在这里被设成EXIT_ZOMBIE然后调schedule()主动让出 CPU而且这一让就是永别——这个任务再也不会被调度回来。剩下的task_struct和内核栈不能被自己释放因为它还在被自己使用着必须等父进程调wait或者waitpid进来由release_task来善后。这就是僵尸进程存在的全部理由它不是泄漏是设计上必须保留的一块“遗物”里面装着退出码、资源使用统计等着父进程来读。6.2 僵尸进程存在的合理性很多人第一次看到ps里一堆Z状态的进程会本能地慌其实僵尸本身占的资源极少就是一个task_struct加内核栈通常几 KB 到十几 KB。真正的问题是数量几十万个僵尸会把 PID 号段吃光/proc/sys/kernel/pid_max默认值在 64 位系统上是 4194304听着很多但如果一个高并发服务每秒fork几次且从不回收几小时就能耗掉。判断方法很简单ps -eo stat,ppid,pid,comm | grep ^Z按 PPID 分组统计一下谁的子进程僵尸最多问题就在谁身上。修复思路也很固定父进程必须处理SIGCHLD。要么在信号处理函数里循环调waitpid(-1, ..., WNOHANG)直到返回 0注意必须循环因为多个子进程同时退出时信号可能被合并要么把SIGCHLD显式设成SIG_IGN这会让内核自动回收但代价是拿不到退出码要么用signalfd或者pidfd把它接进事件循环避免在信号处理函数里做不安全的事。还有一种常见情况是父进程本身写得没问题但它是个长期运行的守护进程中途用system()之类的方式起了子进程而system()内部处理了SIGCHLD如果自己的信号处理没考虑嵌套就可能漏回收。6.3 孤儿、subreaper 与托孤父进程先于子进程退出子进程就变成孤儿内核的处理是把它挂到pid 1名下重新认爹。容器场景下这个“1 号进程”往往不是完整的 init而是一个应用的主进程如果它不处理SIGCHLD孤儿退出之后就会堆成僵尸而且没人能回收——这就是容器里僵尸堆积的典型成因。解法有两种让应用主进程正确实现回收逻辑或者在容器里放一个专门的最小 init 来负责收尸。PR_SET_CHILD_SUBREAPER这个prctl提供了一种更灵活的方式某个进程可以声明自己为“次级回收者”它的后代里出现孤儿时会优先挂到它名下而不是pid 1。这个机制对进程管理类程序特别有用比如一个 supervisor 启动了一堆工作进程工作进程又各自fork了孙进程用 subreaper 就能保证所有孤儿的回收都落在 supervisor 手里不用跟系统的 init 抢活。7. 动手验证把源码里的字段拉到现实里看7.1 /proc/PID/status 与结构体字段对照读源码最怕读完就忘我习惯拿一个活着的进程做对照。随便起一个进程看/proc/pid/status里面的字段和task_struct的对应关系大致是这样/proc 字段对应的内核来源说明Nametask_struct-comm最长 15 字符prctl(PR_SET_NAME)可改Statetask_struct-__stateR/S/D/T/Z就是状态宏的简写Tgidtask_struct-tgid线程组号主线程的 pid 与它相同Pidtask_struct-pid当前这个任务的编号PPidtask_struct-real_parent-tgid父进程号Threads线程组内任务计数不是task_struct字段是遍历统计出来的VmRSSmm-rss_stat汇总常驻物理内存包含共享页voluntary_ctxt_switchestask_struct-nvcsw主动让出次数nonvoluntary_ctxt_switchestask_struct-nivcsw被动抢占次数对着这张表看status比干读结构体定义直观得多。想再看细一点/proc/pid/stat里那几个数字字段包含了优先级、nice 值、启动时间、CPU 时间片累计/proc/pid/smaps逐段列出 VMA 的权限和内存分布/proc/pid/maps给出地址范围。多线程程序里/proc/pid/task/目录下每个线程一个子目录进去同样能看到status和stat这是观察线程级状态最快的方式。7.2 用 pahole 看结构体真实布局task_struct到底多大光看源码数不出来因为编译器会做对齐填充。有vmlinux或者带调试信息的内核模块时用pahole -C task_struct vmlinux能直接打出每个字段的偏移、大小和中间的填充空洞。在一个常见的内核配置上这个结构体通常在几 KB 到十几 KB 之间具体取决于开了多少调试和追踪选项。这个数字有实际意义它决定了创建大量进程时的基础内存开销也解释了为什么内核栈不能开太大、为什么某些场景下更推荐用线程池而不是进程池。没有vmlinux也不影响做这个观察gdb里ptype /o struct task_struct能输出类似的布局视图/o就是显示偏移的意思。如果你在调内核模块container_of用得对不对看一眼偏移也能验证。7.3 写个 30 行的 COW 验证程序光听写时复制的原理不够自己跑一遍最实在。下面这段代码在fork前后分别统计自己的VmRSS并在子进程里修改一个全局大数组观察父子进程的内存变化#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h static char big[64 * 1024 * 1024]; static long rss_kb(void) { FILE *f fopen(/proc/self/status, r); char line[256]; long v -1; while (fgets(line, sizeof line, f)) if (!strncmp(line, VmRSS:, 6)) { sscanf(line 6, %ld, v); break; } fclose(f); return v; } int main(void) { memset(big, 0x41, sizeof big); /* 先把页都落实 */ printf(parent before fork : %ld KB\n, rss_kb()); pid_t p fork(); if (p 0) { printf(child after fork : %ld KB\n, rss_kb()); big[0] Z; big[4096 * 100] Z; /* 只碰两页 */ printf(child after write : %ld KB\n, rss_kb()); _exit(0); } waitpid(p, NULL, 0); printf(parent after child : %ld KB\n, rss_kb()); return 0; }跑一遍你会看到子进程fork之后的 RSS 并不到父进程的两倍写了两页之后也只涨了一点点。再配合/proc/pid/smaps里Shared_Clean和Private_Dirty的变化看就完全能对上源码里dup_mmap和do_wp_page的行为。这个实验我建议每个做后台开发的人都亲手做一次比看十篇文章记得牢。8. 排查实录几个从源码倒推出来的经验8.1 fork 变慢的三种典型第一种是 VMA 数量太多。dup_mmap是逐个 VMA 复制的还要为每个 VMA 复制页表进程如果因为大量mmap或者内存分配器碎片导致 VMA 有几十万个fork就会明显变慢。判断方法是看/proc/pid/maps的行数或者cat /proc/pid/status | grep VmPTE。调vm.max_map_count只能放宽上限真正治本得从分配策略入手比如换用对 VMA 更友好的分配器、减少细碎映射。第二种是页表本身太大。一个用了几十 GB 内存的进程页表可能有几百 MBfork时要全部复制。THP透明大页在这里是把双刃剑它减少了页表项数量但也可能让 COW 的粒度从 4KB 变成 2MB一旦发生写时复制拷贝的量会大很多。我曾经遇到一个服务fork时偶发几百毫秒的卡顿最后是把 THP 在某些区域关掉才稳住的。第三种是fork之后立刻exec的场景如果父进程内存很大即使有 COWexec之前的那段窗口期也会因为共享页表而付出代价这种场景改用posix_spawn往往更划算它内部会尽量走vfork路径。8.2 D 状态、僵尸与 PID 耗尽线上几类高频的进程异常从源码角度看其实都很清楚现象可能的根因排查入口ps里长期D状态kill -9无效卡在不可中断睡眠典型是 IO 或驱动层等待/proc/pid/stack看内核栈/proc/pid/wchan大量Z状态父进程未回收子进程按 PPID 聚合检查父进程SIGCHLD处理fork返回EAGAIN触到RLIMIT_NPROC、pidscgroup 或pid_max上限ulimit -u、cgroup 的pids.max、/proc/sys/kernel/pid_max进程被SIGKILL却迟迟不退卡在内核态无法返回用户态处理信号对比/proc/pid/status的SigPnd和内核栈容器内 PID 与宿主机对不上PID 命名空间隔离lsns、/proc/pid/status的NSpid字段D状态那条值得强调SIGKILL不是“立即杀死”它的语义是“给这个进程打上待处理标记等它下次能安全返回用户态时再处理”。进程如果陷在内核里出不来比如等一块永远不返回的磁盘 IO那这个信号就一直挂着。这时候看/proc/pid/stack比反复kill有用得多栈上会直接告诉你在等哪个函数。8.3 我踩过的坑第一坑是拿nvcsw当性能指标。这个计数器只反映被抢占的次数不反映时间。一个进程被抢占一万次可能每次只丢了几微秒也可能是每次丢掉一整个时间片光看数字没法定性得结合/proc/pid/schedstat里的运行时间和等待时间一起看。第二坑是以为线程数可以随便开。线程在内核里也是task_struct每个都占内核栈默认 16KB 的栈乘以一万个线程就是 160MB还不算调度器的队列管理开销。我见过一个服务把线程池上限开到两万压测时没出事生产上因为某个下游变慢导致线程全堵住内存直接顶到上限。第三坑是忽略exec对信号处置的重置规则导致子进程里预期的SIGPIPE保护失效写日志的管道断开后数据静默丢失查了两天才定位到是父进程的忽略设置被继承下去了。还有一个偏经验的判断当一个进程的行为看起来“不符合预期”时先去/proc/pid/下面把那几个文件挨个cat一遍往往五分钟内就能把范围缩小到状态、内存、文件描述符、命名空间这几类里的一类。这套动作做熟了比凭直觉猜要快得多。源码读懂之后带来的最大变化不是记住了多少字段而是看到一个现象时知道该去哪个文件、哪个结构体里找答案——剩下的就是体力活了。
