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