第一次看到fork這個(gè)函數(shù)我盯著那句“調(diào)用一次返回兩次”琢磨了挺久——一個(gè)函數(shù)怎么可能有兩次返回后來在內(nèi)核源碼里把kernel_clone到copy_process這條路走了一遍才算真正把這件事想通。它難懂不是因?yàn)楦拍钣卸嘈醵且驗(yàn)樗荒_踩在用戶態(tài) API 和內(nèi)核調(diào)度器的交界處你在 C 代碼里看到的只是一行函數(shù)調(diào)用背后卻是整個(gè)進(jìn)程地址空間的復(fù)制、頁表的重新登記、調(diào)度實(shí)體的插入。Linux 的 fork 函數(shù)幾乎是所有多進(jìn)程程序的起點(diǎn)從 shell 執(zhí)行命令、Nginx 拉起 worker、到你自己寫的批量任務(wù)分發(fā)腳本底層都是同一套東西。這篇文章我想寫給兩類人一類是剛學(xué)完操作系統(tǒng)課本、知道“fork 會(huì)復(fù)制進(jìn)程”但一寫代碼就蒙的同學(xué)另一類是在項(xiàng)目里被僵尸進(jìn)程、緩沖區(qū)重復(fù)輸出、子進(jìn)程不受控這些問題咬過、想把這套機(jī)制徹底捋順的開發(fā)者。我會(huì)從內(nèi)核實(shí)現(xiàn)路徑、返回值語義、代碼實(shí)操、參數(shù)取舍一路講到排查實(shí)錄代碼都能直接跑坑也都標(biāo)出來。1. fork 的本質(zhì)一次調(diào)用為何有兩次返回1.1 從用戶態(tài)看它只是三個(gè)整數(shù)之一從調(diào)用者角度看fork的接口簡單到幾乎沒有任何可配置項(xiàng)——沒有參數(shù)沒有任何 flag只返回一個(gè)pid_t。這個(gè)返回值分三種情況必須先記牢因?yàn)楹竺?90% 的 bug 都源于這里判斷錯(cuò)了返回值出現(xiàn)在哪個(gè)進(jìn)程含義 0父進(jìn)程這個(gè)值是剛創(chuàng)建出來的子進(jìn)程 PID 0子進(jìn)程說明“我就是那個(gè)新進(jìn)程”沒有別的信息 -1父進(jìn)程創(chuàng)建失敗原因看errno有一點(diǎn)很容易被忽略子進(jìn)程拿到的 0 不是“子進(jìn)程的 PID 是 0”而是一個(gè)標(biāo)記位。子進(jìn)程想知道自己的 PID 得調(diào)getpid()想知道爹是誰得調(diào)getppid()。我見過不少人寫成if (pid 0) { /* 子進(jìn)程 */ }邏輯反了還不報(bào)錯(cuò)程序在多核機(jī)器上跑出來的結(jié)果飄忽不定排查半天才發(fā)現(xiàn)是分支寫反。#include stdio.h #include unistd.h #include sys/types.h int main(void) { pid_t pid fork(); if (pid 0) { perror(fork); return 1; } else if (pid 0) { printf(child : pid%d ppid%d\n, getpid(), getppid()); } else { printf(parent: pid%d child%d\n, getpid(), pid); } return 0; }編譯就用gcc -Wall -O0 fork_demo.c -o fork_demo加-Wall是習(xí)慣編譯器對fork相關(guān)的返回值未檢查會(huì)給出提示能擋掉一批低級(jí)錯(cuò)誤。1.2 內(nèi)核里那條路從系統(tǒng)調(diào)用到copy_process用戶態(tài)的一次fork()最終會(huì)落到內(nèi)核的sys_forkx86-64 上走_(dá)_x64_sys_fork再進(jìn)到kernel_clone。這個(gè)名字在不同內(nèi)核版本里變過老版本叫_do_fork5.x 之后統(tǒng)一成kernel_clone。真正干重活的是copy_process它按順序做了這么幾件事dup_task_struct復(fù)制一份task_struct和內(nèi)核棧此時(shí)父子進(jìn)程的描述符已經(jīng)存在但內(nèi)容還很“空”。一系列權(quán)限與配額檢查RLIMIT_NPROC限制、系統(tǒng)級(jí)線程數(shù)上限、用戶進(jìn)程數(shù)上限任何一項(xiàng)超了就直接返回錯(cuò)誤。sched_fork給新任務(wù)初始化調(diào)度實(shí)體把它掛到調(diào)度器上但此時(shí)還沒真正運(yùn)行。copy_files、copy_fs、copy_sighand這幾項(xiàng)大多是增加引用計(jì)數(shù)而不是深拷貝。打開的文件表、信號(hào)處理函數(shù)表、工作目錄這些父子共享同一份內(nèi)核對象。copy_mm這是最重的一步復(fù)制內(nèi)存描述符、遍歷所有 VMA、復(fù)制頁表并把父子雙方的頁表項(xiàng)統(tǒng)統(tǒng)改成只讀。alloc_pid分配一個(gè)新的 PID。wake_up_new_task把子進(jìn)程放進(jìn)運(yùn)行隊(duì)列等調(diào)度器挑中它。父進(jìn)程在kernel_clone返回處拿到子進(jìn)程 PID子進(jìn)程不是“返回”到這個(gè)位置而是被調(diào)度到時(shí)從ret_from_fork這條棧幀直接跳回用戶態(tài)返回值寄存器被填成 0。所以“一次調(diào)用兩次返回”這個(gè)說法其實(shí)有點(diǎn)誤導(dǎo)——它不是同一個(gè)函數(shù)返了兩遍而是兩個(gè)獨(dú)立的執(zhí)行流各自從內(nèi)核態(tài)穿越回用戶態(tài)只是它們穿越前在同一段內(nèi)核代碼里待過。1.3 為什么不做全量拷貝COW 的取舍邏輯如果fork真的把父進(jìn)程幾百 MB 內(nèi)存整塊復(fù)制一遍那創(chuàng)建一個(gè)進(jìn)程的開銷會(huì)大到?jīng)]法用。早期的確是這個(gè)思路fork后緊跟execve的場景浪費(fèi)極其嚴(yán)重——復(fù)制了一大堆馬上要被覆蓋的內(nèi)存。寫時(shí)復(fù)制Copy-On-Write簡稱 COW就是為了解決這個(gè)浪費(fèi)copy_mm復(fù)制頁表時(shí)父子進(jìn)程的頁表項(xiàng)指向同一批物理頁只是把這些頁的權(quán)限位從可寫改成只讀同時(shí)在task_struct里把頁標(biāo)記成 COW 頁。真正的復(fù)制推遲到有人寫的那一刻。任意一方寫入觸發(fā)缺頁異常內(nèi)核發(fā)現(xiàn)這是個(gè) COW 頁才分配新物理頁、把原內(nèi)容拷過去、改回可寫然后重新執(zhí)行那條指令。這個(gè)設(shè)計(jì)的精妙之處在于只讀的父子進(jìn)程幾乎零成本只有真正被修改過的頁才付出復(fù)制代價(jià)。但 COW 不是沒有成本。fork的耗時(shí)和進(jìn)程當(dāng)前占用的虛擬內(nèi)存成正比因?yàn)轫摫肀旧硪獜?fù)制。粗算一下x86-64 上普通頁是 4KB一個(gè)占 1GB 內(nèi)存的進(jìn)程大約有 26 萬個(gè)頁表項(xiàng)每個(gè) PTE 8 字節(jié)光頁表數(shù)據(jù)就是 2MB 左右再加上遍歷 VMA 的時(shí)間。所以你會(huì)發(fā)現(xiàn)一個(gè)現(xiàn)象——空進(jìn)程fork微秒級(jí)就完了幾百 MB 的服務(wù)進(jìn)程fork一次可能要好幾個(gè)毫秒。這個(gè)結(jié)論直接影響了后面的選型判斷。注意COW 讓父子共享物理頁但邏輯上是兩個(gè)獨(dú)立的地址空間。子進(jìn)程里的malloc返回值在父進(jìn)程里沒有任何意義別指望用這個(gè)地址跨進(jìn)程傳數(shù)據(jù)那需要共享內(nèi)存或者管道。2. 執(zhí)行流、競爭與繼承那些課本上不講清楚的事2.1 父子誰先跑答案是“不知道”fork返回之后父進(jìn)程和子進(jìn)程誰先被 CPU 執(zhí)行完全由調(diào)度器決定沒有任何順序保證。在多核機(jī)器上兩個(gè)進(jìn)程大概率是真并行在單核上時(shí)間片怎么分也看調(diào)度策略。這意味著任何依賴“父進(jìn)程先執(zhí)行完再輪到子進(jìn)程”的代碼都是錯(cuò)的。我踩過的第一個(gè)坑就出在這里一個(gè)父進(jìn)程里 fork 之后立刻往共享的文件描述符寫數(shù)據(jù)子進(jìn)程也寫結(jié)果兩次實(shí)驗(yàn)跑出來的內(nèi)容順序完全不一樣。當(dāng)時(shí)以為是文件系統(tǒng)的問題其實(shí)是執(zhí)行順序不確定。正確的處理方式是顯式同步——用waitpid等子進(jìn)程結(jié)束用管道通信用信號(hào)量互斥而不是靠“大概會(huì)先跑我”。#include stdio.h #include unistd.h #include sys/wait.h int main(void) { pid_t pid fork(); if (pid 0) { printf(child working\n); _exit(0); } int status 0; waitpid(pid, status, 0); printf(child exited, status%d\n, WEXITSTATUS(status)); return 0; }子進(jìn)程退出用_exit而不是exit這是個(gè)細(xì)節(jié)但很重要。exit會(huì)執(zhí)行atexit注冊的函數(shù)、刷新 stdio 緩沖區(qū)而這些緩沖區(qū)是從父進(jìn)程繼承來的如果父進(jìn)程 fork 前有沒刷新的內(nèi)容子進(jìn)程exit時(shí)又刷一遍輸出就重復(fù)了。_exit直接走系統(tǒng)調(diào)用跳過所有這些用戶態(tài)清理干凈利落。2.2 文件描述符繼承共享的不只是“編號(hào)”fork之后子進(jìn)程會(huì)得到父進(jìn)程所有打開文件描述符的副本但這里有個(gè)特別容易誤解的地方復(fù)制的是描述符不是文件對象。父子雙方各自的 fd 編號(hào)可能不同但它們指向同一個(gè)struct file而struct file里存著文件偏移量。后果很直觀父進(jìn)程讀了 100 字節(jié)子進(jìn)程接著讀會(huì)從第 101 字節(jié)開始而不是從頭讀。寫文件同理兩邊交替寫會(huì)互相覆蓋偏移。我在做一個(gè)日志切分的小工具時(shí)就被這個(gè)咬過父子都往同一個(gè)日志文件追加結(jié)果日志里出現(xiàn)了大片空洞——因?yàn)閮蛇叾荚谟胠seek挪同一個(gè)偏移量。想避免這個(gè)問題常規(guī)做法是父子需要獨(dú)立讀寫位置時(shí)子進(jìn)程 fork 之后自己重新open一次文件或者應(yīng)用層用O_APPEND打開讓每次寫都由內(nèi)核原子地定位到文件末尾或者干脆別讓多個(gè)進(jìn)程寫同一個(gè)文件改成各自寫各自的后續(xù)再合并。除了文件描述符子進(jìn)程還會(huì)繼承當(dāng)前工作目錄、信號(hào)處理方式SIG_IGN和自定義處理函數(shù)都繼承但未處理的信號(hào)會(huì)重置為默認(rèn)、umask、環(huán)境變量、資源限制。這些在寫守護(hù)進(jìn)程的時(shí)候會(huì)集中爆發(fā)問題。2.3 多線程進(jìn)程里 fork 的隱藏雷區(qū)這是我認(rèn)為最需要單獨(dú)拎出來說的一條。fork只會(huì)復(fù)制調(diào)用它的那個(gè)線程其他線程在子進(jìn)程里全都不存在。但問題來了那些線程持有的互斥鎖、條件變量、讀寫鎖狀態(tài)是被原樣復(fù)制過去的。如果 fork 的瞬間某個(gè)鎖正被另一個(gè)線程持有那么在子進(jìn)程里這把鎖永遠(yuǎn)處于“被鎖住”的狀態(tài)而持有者已經(jīng)不存在了任何試圖加鎖的代碼都會(huì)永久阻塞。規(guī)避方式有三條路按推薦程度排fork 完立刻 execve。這是最安全的姿勢execve會(huì)把整個(gè)用戶態(tài)地址空間換掉鎖的狀態(tài)也一并消失。絕大多數(shù)“fork 后要干事”的場景其實(shí)都該走這條路。fork 之前保證沒有其他線程在跑比如在程序啟動(dòng)早期就把需要 fork 的邏輯做完。用pthread_atfork注冊 prepare/parent/child 三個(gè)鉤子在 fork 前后手動(dòng)加解鎖。這套機(jī)制能解決問題但很容易寫成死鎖尤其是涉及多把鎖的時(shí)候加鎖順序稍不注意就翻車。提示如果你的程序用了線程池同時(shí)又有 fork 子進(jìn)程的需求請優(yōu)先考慮把子進(jìn)程部分改成獨(dú)立進(jìn)程或者獨(dú)立的服務(wù)不要在同一進(jìn)程里混用?；煊脦淼恼{(diào)試成本遠(yuǎn)高于拆開的改造成本。3. 動(dòng)手實(shí)操從最小 Demo 到可用的進(jìn)程管理3.1 循環(huán) fork 的 2 的 n 次方陷阱先看一段看起來人畜無害的代碼for (int i 0; i 3; i) { fork(); printf(pid%d, i%d\n, getpid(), i); }很多人以為這會(huì)產(chǎn)生 3 個(gè)子進(jìn)程加 1 個(gè)父進(jìn)程。實(shí)際結(jié)果是 8 個(gè)進(jìn)程。原因在于fork之后父進(jìn)程繼續(xù)循環(huán)子進(jìn)程也從 fork 的下一行繼續(xù)執(zhí)行于是它也進(jìn)入下一輪循環(huán)并且再次 fork。每一輪都把當(dāng)前進(jìn)程數(shù)翻倍3 輪就是 23 8。這個(gè)行為本身沒錯(cuò)是很多人對“子進(jìn)程從哪開始執(zhí)行”的理解有偏差。子進(jìn)程不是從main重頭開始而是從fork返回點(diǎn)繼續(xù)。如果確實(shí)需要?jiǎng)?chuàng)建 N 個(gè)并列的工作進(jìn)程比如預(yù)派生模型正確寫法是在子進(jìn)程里立刻跳出循環(huán)#define WORKERS 4 for (int i 0; i WORKERS; i) { pid_t pid fork(); if (pid 0) { perror(fork); break; } if (pid 0) { worker_loop(i); /* 子進(jìn)程干活不再進(jìn)入下一輪 */ _exit(0); } } /* 父進(jìn)程在這里統(tǒng)一 wait */關(guān)鍵就是if (pid 0)分支里干完活直接_exit絕不落回循環(huán)體。這個(gè)模式叫預(yù)派生pre-forkNginx 的 worker 模型、老式 Apache 的 prefork 都是這個(gè)思路。好處是每個(gè) worker 獨(dú)立壞處是 worker 數(shù)在啟動(dòng)時(shí)就固定了得配合平滑重啟來調(diào)整。3.2 用 fork execve 寫一個(gè)迷你 shell想真正理解 fork最好的練習(xí)是寫一個(gè)能跑命令的 shell。它的核心邏輯只有四步讀一行、切參數(shù)、fork、子進(jìn)程 exec。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h #define MAXLINE 1024 int main(void) { char line[MAXLINE]; while (fgets(line, sizeof(line), stdin) ! NULL) { line[strcspn(line, \n)] \0; if (line[0] \0) continue; if (strcmp(line, exit) 0) break; char *argv[64]; int argc 0; char *tok strtok(line, ); while (tok ! NULL argc 63) { argv[argc] tok; tok strtok(NULL, ); } argv[argc] NULL; pid_t pid fork(); if (pid 0) { perror(fork); continue; } if (pid 0) { execvp(argv[0], argv); perror(execvp); /* 只有 exec 失敗才會(huì)走到這里 */ _exit(127); } int status 0; waitpid(pid, status, 0); if (WIFEXITED(status)) { printf([exit %d]\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf([killed by signal %d]\n, WTERMSIG(status)); } } return 0; }幾個(gè)值得說的點(diǎn)。execvp會(huì)自己去PATH里找可執(zhí)行文件所以直接敲ls就能跑。execvp成功的話永遠(yuǎn)不會(huì)返回返回值只在失敗時(shí)有用失敗后必須_exit(127)用 127 是 shell 界的慣例表示“命令沒找到”。waitpid拿到的status是個(gè)打包值不能直接當(dāng)退出碼用得用WIFEXITED、WEXITSTATUS、WIFSIGNALED這些宏去拆。我第一次寫的時(shí)候直接printf(%d, status)輸出 256 讓我困惑了很久——其實(shí)真實(shí)退出碼是 1因?yàn)橥顺龃a存在高 8 位。這個(gè) shell 還很粗糙不支持管道、重定向、后臺(tái)任務(wù)但骨架已經(jīng)對了。想支持管道就需要在 fork 之前先pipe()然后兩個(gè)子進(jìn)程分別把dup2把讀端寫端接到標(biāo)準(zhǔn)輸入輸出上這是個(gè)很好的練手項(xiàng)目。3.3 并行任務(wù)分發(fā)怎么定并發(fā)數(shù)再給一個(gè)更貼近實(shí)際工作的例子——把一批耗時(shí)任務(wù)拆給多個(gè)子進(jìn)程并行跑。這個(gè)模式在數(shù)據(jù)預(yù)處理、批量轉(zhuǎn)碼、壓測腳本里特別常見。#include stdio.h #include unistd.h #include sys/wait.h #define JOBS 4 static void do_work(int id) { sleep(1); /* 模擬耗時(shí)計(jì)算 */ printf(job %d done by pid %d\n, id, getpid()); } int main(void) { pid_t pids[JOBS]; for (int i 0; i JOBS; i) { pid_t pid fork(); if (pid 0) { perror(fork); pids[i] -1; continue; } if (pid 0) { do_work(i); _exit(0); } pids[i] pid; } for (int i 0; i JOBS; i) { if (pids[i] 0) { int status 0; waitpid(pids[i], status, 0); printf(child %d reaped, status%d\n, pids[i], WEXITSTATUS(status)); } } return 0; }并發(fā)數(shù)怎么定我的經(jīng)驗(yàn)是別超過 CPU 邏輯核數(shù)。純計(jì)算型任務(wù)進(jìn)程數(shù)等于核數(shù)時(shí)吞吐最高再多只會(huì)增加上下文切換和內(nèi)存壓力。可以用sysconf(_SC_NPROCESSORS_ONLN)拿到當(dāng)前可用核數(shù)再乘一個(gè)系數(shù)I/O 密集型任務(wù)等待磁盤、網(wǎng)絡(luò)系數(shù)取 2 到 4CPU 密集型任務(wù)系數(shù)取 1每個(gè)子進(jìn)程內(nèi)存占用大比如幾百 MB還得反過來壓低數(shù)量防止觸發(fā) OOM。另外要注意waitpid的回收順序。上面這段代碼是按創(chuàng)建順序回收的如果第 0 個(gè)任務(wù)特別慢后面三個(gè)早就跑完了也得等著。想做到“誰先完誰先回收”用waitpid(-1, status, 0)循環(huán)回收任意子進(jìn)程或者干脆用SIGCHLD信號(hào)處理。4. 資源、參數(shù)與選型什么時(shí)候該用 fork什么時(shí)候不該4.1 fork 失敗的兩種典型 errnofork返回 -1 時(shí)errno最常見的兩個(gè)值是EAGAIN和ENOMEM含義完全不同排查方向也不一樣。EAGAIN表示“資源暫時(shí)不夠”通常是進(jìn)程數(shù)配額打滿了。要檢查幾個(gè)地方RLIMIT_NPROC用ulimit -u看、系統(tǒng)級(jí)kernel.pid_max、kernel.threads-max還有 cgroup 里的pids.max。在容器環(huán)境里跑最容易撞的是 cgroup 的 pids 限制從宿主機(jī)上看一切正常容器里怎么都 fork 不出來。我遇到過的一次就是容器 pids 上限設(shè)得太小業(yè)務(wù)里但凡有個(gè) fork 都失敗日志里只留一行“Resource temporarily unavailable”查了半天才定位到配額。ENOMEM則是內(nèi)存不夠。注意這不一定是物理內(nèi)存耗盡也可能是因?yàn)?COW 機(jī)制下內(nèi)核需要為新進(jìn)程分配task_struct和內(nèi)核棧同時(shí)在復(fù)制頁表時(shí)需要申請內(nèi)存。內(nèi)存緊張時(shí)一個(gè)本身不大的進(jìn)程 fork 也可能失敗。這時(shí)候該看的是dmesg里有沒有 OOM 相關(guān)記錄以及/proc/meminfo的CommitLimit和Committed_AS。堆棧上還有一個(gè)坑內(nèi)核棧默認(rèn)不大歷史上是 8KB某些配置下更小fork本身不占用戶棧但如果你的代碼在fork前遞歸很深子進(jìn)程復(fù)制的是整個(gè)地址空間的映射雖然 COW 不會(huì)立刻復(fù)制物理頁但虛擬地址空間的布局是完全一致的棧溢出風(fēng)險(xiǎn)同樣被繼承過去。4.2 fork、vfork、clone、posix_spawn 怎么選這四個(gè)東西經(jīng)常被放在一起比較但它們的定位差別很大接口地址空間典型用途注意事項(xiàng)fork完全復(fù)制COW通用進(jìn)程創(chuàng)建大內(nèi)存進(jìn)程下耗時(shí)隨內(nèi)存增長vfork與父進(jìn)程共享父進(jìn)程阻塞fork 后立刻 exec 的老場景子進(jìn)程不能 return只能_exit或 execclone可精細(xì)控制共享哪些資源實(shí)現(xiàn)線程、命名空間隔離參數(shù)復(fù)雜直接用的場景不多posix_spawn內(nèi)部實(shí)現(xiàn)可能用 vfork/clone單純想“起個(gè)程序”接口受限不適合 fork 后跑自定義邏輯選型上的判斷其實(shí)很簡單如果你 fork 之后馬上就要 execve那就用posix_spawn它在 glibc 里會(huì)走clone(CLONE_VM | CLONE_VFORK)省掉整個(gè)頁表復(fù)制的開銷在大內(nèi)存進(jìn)程里差距非常明顯。我在一個(gè)占內(nèi)存接近 1GB 的服務(wù)里把fork exec換成posix_spawn創(chuàng)建子進(jìn)程的耗時(shí)從毫秒級(jí)降到了幾十微秒級(jí)效果立竿見影。如果 fork 之后子進(jìn)程要跑一段自己的 C 邏輯改環(huán)境、設(shè)權(quán)限、接著算那還是老老實(shí)實(shí)fork。vfork不要碰它的約束太苛刻稍微寫錯(cuò)一點(diǎn)就是未定義行為而且現(xiàn)代 glibc 的fork已經(jīng)在很多場景下優(yōu)化得夠好了。如果你需要的是“共享地址空間的并發(fā)”那你其實(shí)想要的是線程應(yīng)該用pthread_create而不是clone。clone是給需要做命名空間隔離、實(shí)現(xiàn)容器運(yùn)行時(shí)這類底層工具準(zhǔn)備的。4.3 內(nèi)存開銷的實(shí)測感受我自己做過一個(gè)粗略的對比測試在同一臺(tái)機(jī)器上讓一個(gè)進(jìn)程分別占用 10MB、100MB、500MB 匿名內(nèi)存然后各 fork 1000 次記錄平均耗時(shí)。數(shù)量級(jí)上的結(jié)論是10MB 時(shí) fork 大約在幾十微秒100MB 時(shí)漲到一兩百微秒500MB 時(shí)到了毫秒級(jí)。這個(gè)增長主要來自頁表復(fù)制和 VMA 遍歷跟寫入多少數(shù)據(jù)無關(guān)。這個(gè)結(jié)論有很實(shí)際的指導(dǎo)意義如果你的服務(wù)常駐內(nèi)存很大就不要在熱路徑上頻繁 fork。要么改成常駐的 worker 池啟動(dòng)時(shí)一次性 fork 好之后靠任務(wù)隊(duì)列分發(fā)要么改用線程池要么在 fork 前盡量減少不必要的內(nèi)存映射。反之如果進(jìn)程很小比如一個(gè)命令行小工具fork 的開銷基本可以忽略不用過度設(shè)計(jì)。5. 常見問題與排查實(shí)錄5.1 僵尸進(jìn)程不是“沒死透”是“沒人收尸”子進(jìn)程結(jié)束后內(nèi)核不會(huì)立刻把它的task_struct全部釋放因?yàn)楦高M(jìn)程可能還需要讀取退出狀態(tài)。這個(gè)狀態(tài)叫僵尸態(tài)Z。只要父進(jìn)程調(diào)用了wait或waitpid狀態(tài)被讀取資源才會(huì)真正回收。如果父進(jìn)程一直不回收僵尸會(huì)越積越多。單個(gè)僵尸占的內(nèi)存不多主要是一個(gè)task_struct加內(nèi)核棧但 PID 是有限的數(shù)量堆上去之后新的 fork 就會(huì)返回EAGAIN。用ps aux | grep Z能一眼看到或者ps -eo stat,pid,ppid,comm | awk $1 ~ /^Z/。處理方式有幾種按場景選同步回收waitpid(pid, status, 0)適合明確知道要等哪個(gè)子進(jìn)程的場合。異步回收注冊SIGCHLD處理函數(shù)在處理函數(shù)里循環(huán)waitpid(-1, NULL, WNOHANG)直到返回 0 或 -1。注意SIGCHLD可能合并所以必須用循環(huán) WNOHANG不能只 wait 一次。主動(dòng)放棄如果確實(shí)不關(guān)心子進(jìn)程結(jié)果可以顯式忽略signal(SIGCHLD, SIG_IGN)在某些系統(tǒng)上這會(huì)讓子進(jìn)程退出時(shí)自動(dòng)被回收不用父進(jìn)程操心。但要注意這會(huì)影響到所有子進(jìn)程其他需要waitpid的地方就拿不到狀態(tài)了。#include signal.h #include sys/wait.h #include unistd.h static void on_sigchld(int sig) { (void)sig; int saved_errno errno; while (waitpid(-1, NULL, WNOHANG) 0) { /* 循環(huán)回收所有已退出的子進(jìn)程 */ } errno saved_errno; } int main(void) { struct sigaction sa; sa.sa_handler on_sigchld; sigemptyset(sa.sa_mask); sa.sa_flags SA_RESTART | SA_NOCLDSTOP; sigaction(SIGCHLD, sa, NULL); /* ... 業(yè)務(wù)邏輯 ... */ return 0; }信號(hào)處理函數(shù)里保存和恢復(fù)errno是個(gè)細(xì)節(jié)因?yàn)樾盘?hào)隨時(shí)可能打斷正在進(jìn)行的系統(tǒng)調(diào)用處理函數(shù)里如果改了errno回到被打斷的地方邏輯就亂了。SA_RESTART的作用是讓被信號(hào)打斷的系統(tǒng)調(diào)用自動(dòng)重啟減少EINTR的處理負(fù)擔(dān)。另一個(gè)容易被忽略的角色是孤兒進(jìn)程。父進(jìn)程先于子進(jìn)程退出子進(jìn)程就被“過繼”給initPID 1或者某些系統(tǒng)里的 subreaper由它負(fù)責(zé)回收。這本身不是問題但如果你的程序里子進(jìn)程依賴父進(jìn)程做清理工作父進(jìn)程一死子進(jìn)程就成了沒人管的野進(jìn)程。做守護(hù)進(jìn)程或者熱重啟的時(shí)候要特別小心這一點(diǎn)。5.2 緩沖區(qū)重復(fù)輸出一個(gè)經(jīng)典到不能再經(jīng)典的坑這段代碼把輸出重定向到文件你會(huì)看到兩行hello#include stdio.h #include unistd.h int main(void) { printf(hello); /* 沒有換行 */ fork(); return 0; }原因在于 stdio 的緩沖策略。輸出到終端時(shí)是行緩沖遇到\n才刷輸出到文件時(shí)是全緩沖緩沖區(qū)滿了才刷。printf(hello)沒有換行內(nèi)容就躺在用戶態(tài)緩沖區(qū)里沒發(fā)出去。fork復(fù)制地址空間時(shí)這份緩沖區(qū)內(nèi)容原樣復(fù)制到了子進(jìn)程。父子進(jìn)程各自正常退出exit觸發(fā)刷新于是同一個(gè) hello 被寫了兩次。這個(gè)坑的隱蔽之處在于同樣的代碼在終端上跑是正常的一重定向到日志文件就出問題。所以排查時(shí)如果發(fā)現(xiàn)“日志里怎么有重復(fù)行”先看看是不是在fork前有沒刷新的輸出。規(guī)避手段很成熟fork之前調(diào)用fflush(NULL)把所有的輸出緩沖刷干凈或者子進(jìn)程一律用_exit而不是exit或者在每個(gè)printf后面老實(shí)加\n。這三條里我推薦后兩條組合使用_exit應(yīng)該成為肌肉記憶。5.3 常見問題速查表把上面這些以及一些零散的問題匯總一下方便對著查現(xiàn)象最可能的原因排查/解決fork返回 -1EAGAIN進(jìn)程數(shù)達(dá)到RLIMIT_NPROC或 cgroup pids 上限ulimit -u查容器 pids.maxfork返回 -1ENOMEM內(nèi)核內(nèi)存不足無法分配task_struct或頁表看dmesg、/proc/meminfo子進(jìn)程跑完不退出ps顯示Z父進(jìn)程未回收加waitpid或SIGCHLD處理日志出現(xiàn)重復(fù)行fork 前 stdio 緩沖區(qū)未刷新fork 前fflush(NULL)子進(jìn)程用_exit循環(huán)里 fork 出 2^n 個(gè)進(jìn)程子進(jìn)程落回循環(huán)子進(jìn)程分支結(jié)束后立刻_exit父子寫同一文件內(nèi)容錯(cuò)亂共享文件偏移量用O_APPEND或各自 open或分文件子進(jìn)程里加鎖永遠(yuǎn)阻塞多線程下 fork鎖被其他線程持有改成 fork 后立即 exec或用pthread_atfork子進(jìn)程變成孤兒無人清理父進(jìn)程先退出用 subreaper 或?qū)ｉT的 supervisor子進(jìn)程繼承了不該有的 fdfd 默認(rèn)被繼承fork 后關(guān)閉無關(guān) fd或用O_CLOEXEC最后一條值得展開說一句。O_CLOEXEC這個(gè)標(biāo)志非常有用打開文件或套接字時(shí)帶上它這個(gè) fd 會(huì)在 exec 時(shí)自動(dòng)關(guān)閉避免子進(jìn)程意外持有不該持有的連接。在長連接多的服務(wù)里如果 fork 出來的子進(jìn)程繼承了所有 socket一方面浪費(fèi) fd另一方面連接關(guān)閉的時(shí)機(jī)變得難以判斷。從代碼層面統(tǒng)一給open、socket、pipe2加CLOEXEC是個(gè)好習(xí)慣成本幾乎為零。還有一個(gè)排查技巧不確定子進(jìn)程到底繼承了哪些 fd可以在子進(jìn)程里ls -l /proc/自進(jìn)程PID/fd一眼看清楚。同理/proc/PID/status里的Threads、VmRSS/proc/PID/task/下的線程列表都是排查這類問題的一手信息。養(yǎng)成看/proc的習(xí)慣比裝一堆工具快得多。6. 我在實(shí)際項(xiàng)目里攢下的幾條經(jīng)驗(yàn)寫到這里分享幾個(gè)文檔里不太會(huì)提、但確實(shí)節(jié)省過時(shí)間的做法。第一給每個(gè) fork 出來的子進(jìn)程起個(gè)可識(shí)別的名字。Linux 上可以調(diào)prctl(PR_SET_NAME, worker-xxx)這樣ps和top里就能看明白哪個(gè)進(jìn)程在干什么而不是一堆同名進(jìn)程排在那。出問題時(shí)省下來的定位時(shí)間遠(yuǎn)超當(dāng)初寫這幾行代碼的成本。第二在子進(jìn)程的入口處打一行帶 PID 的日志并且立刻setpgid或調(diào)整會(huì)話。這能讓日志里的 PID 和進(jìn)程樹對應(yīng)起來尤其是在子進(jìn)程會(huì)再 fork 的場景下沒有這層標(biāo)記日志會(huì)亂成一鍋粥。做后臺(tái)任務(wù)的時(shí)候順手把子進(jìn)程放到獨(dú)立的進(jìn)程組后面想整組發(fā)信號(hào)終止也方便。第三不要吝嗇waitpid的循環(huán)寫法。我見過太多“只 wait 一次”的代碼在子進(jìn)程密集退出的場景下漏回收慢慢積累成僵尸。統(tǒng)一寫成while (waitpid(-1, st, WNOHANG) 0)配合SA_RESTART這套模板可以直接抄。第四大內(nèi)存進(jìn)程優(yōu)先考慮換掉模型。如果發(fā)現(xiàn)每次 fork 都有明顯卡頓先別急著調(diào)內(nèi)核參數(shù)問問自己“這個(gè) fork 真的必要嗎”。預(yù)派生進(jìn)程池、線程池、獨(dú)立的常駐服務(wù)這三種方案在絕大多數(shù)場景下都比“按需 fork”更穩(wěn)。fork這個(gè)接口看著古老但它承載的語義——地址空間復(fù)制、文件描述符繼承、執(zhí)行流分叉——至今沒有被替代。把它的返回值、COW、回收機(jī)制這三件事吃透后面再看clone、看容器運(yùn)行時(shí)怎么隔離命名空間、看 shell 怎么執(zhí)行管道都會(huì)順很多。我現(xiàn)在寫涉及多進(jìn)程的代碼開工前會(huì)先在紙上畫一遍父子關(guān)系標(biāo)清楚哪個(gè) fd 誰負(fù)責(zé)關(guān)、哪條路誰負(fù)責(zé) wait畫完之后 bug 就少了一大半。