1. 為什么進程控制是Linux開發(fā)的“地基”做Linux開發(fā)不管是寫應用還是搞驅動繞不開進程。進程控制這塊兒尤其是進程創(chuàng)建和進程終止是所有并發(fā)、IPC、信號、守護進程等機制的底座。我剛入行時領導安排任務第一個就是讓我把fork和exec的調(diào)用關系徹底搞清楚從那時起我就意識到這一章沒吃透后面寫多進程程序基本是寸步難行。這篇內(nèi)容適合誰看我覺得有幾類人特別需要一是剛接觸Linux系統(tǒng)編程的在校生二是從單片機或Windows平臺轉過來的嵌入式開發(fā)者三是寫后端服務但一直只用多線程、沒怎么碰過多進程的工程師。這篇文把進程創(chuàng)建和終止的底層邏輯、邊界情況、以及實際編碼中容易踩的坑全部攤開講盡量做到“知其然也知其所以然”。先說幾個核心關鍵詞fork、vfork、exec族、exit、_exit、僵尸進程、孤兒進程、寫時拷貝COW。把這幾樣東西串起來進程控制的骨架就搭起來了。2. 進程創(chuàng)建不止是fork()這一個函數(shù)2.1fork()的語義和返回值為什么這么設計進程創(chuàng)建最核心的入口就是fork()。它的簽名很簡單#include sys/types.h #include unistd.h pid_t fork(void);但它的行為卻讓無數(shù)新手栽過跟頭。fork()調(diào)用一次返回兩次——一次是在父進程中返回子進程的PID一次是在子進程中返回0。如果失敗則在父進程中返回-1子進程根本不會產(chǎn)生。為什么這么設計因為父進程和子進程都需要知道“我是誰”。父進程拿到子進程PID后續(xù)才能waitpid、kill子進程拿到返回值0從而走不同的分支邏輯。這是多進程編程的一種經(jīng)典“身份識別”方式。我第一次寫fork時最大的困惑就是為什么子進程是從fork()返回處開始執(zhí)行而不是從main()開頭執(zhí)行這就要理解fork的實質(zhì)子進程是父進程的一個“克隆副本”它繼承的是調(diào)用fork()那一刻的進程上下文——包括代碼段、數(shù)據(jù)段、堆、棧、文件描述符表、信號掩碼等。所以它沒必要從頭跑直接從fork返回點繼續(xù)走。#include stdio.h #include unistd.h #include sys/types.h int main() { pid_t pid fork(); if (pid 0) { perror(fork error); return 1; } else if (pid 0) { printf(子進程PID%d父進程PID%d\n, getpid(), getppid()); } else { printf(父進程PID%d子進程PID%d\n, getpid(), pid); } // 注意這段代碼父子都會執(zhí)行 printf(進程 %d 執(zhí)行到這里\n, getpid()); return 0; }上面這段代碼運行后你會看到三行輸出其中兩行打印的是“執(zhí)行到這里”。這就是“fork返回兩次、兩邊都繼續(xù)跑”的效果。實際開發(fā)中常見的寫法是用if-else if-else把父子分支徹底分開避免兩邊執(zhí)行同樣的后續(xù)邏輯。2.2 寫時拷貝COW技術fork為什么“快”fork()剛出現(xiàn)時是直接把父進程的全部地址空間復制一份給子進程。這在早期Unix年代是可以接受的因為那時候進程小。但放到現(xiàn)在一個進程動輒占用幾百MB甚至上GB內(nèi)存如果每次fork都全量復制那性能和內(nèi)存開銷都扛不住。現(xiàn)代Linux的fork()基于寫時拷貝Copy-On-WriteCOW技術優(yōu)化。簡單來說fork()后父子進程的物理內(nèi)存頁面先共享并且把這些頁面標記為只讀。只有當某一方真正去寫這塊內(nèi)存時才觸發(fā)缺頁異常內(nèi)核在異常處理中把這一頁復制一份出來然后更新頁表映射讓該進程擁有獨立副本。這樣帶來的好處是fork()本身的開銷極低幾乎只復制頁表和創(chuàng)建task_struct。父子進程大量共享只讀代碼段例如程序代碼、只讀數(shù)據(jù)不占額外內(nèi)存。只有真正發(fā)生寫入的頁面才被復制。我用個生活中的例子類比就像你和室友在同一份紙質(zhì)合同上簽字雙方手里拿的是同一個原件的復印件只有你要在上面改字時才需要單獨去復印一張新紙。這個“延遲復制”的思想大大提升了fork()的實用性。注意COW的“寫”是指對進程地址空間的寫操作。哪怕只是修改一個char型變量對應的整個4KB頁面也會被復制。所以盡量減少進程間共享可變數(shù)據(jù)這不僅是性能問題更是設計問題。2.3vfork()一個容易誤用的“歷史遺留”vfork()的出現(xiàn)比COW更早它的初衷是創(chuàng)建子進程時不復制父進程地址空間直接共享子進程必須立即執(zhí)行exec或exit否則行為未定義。#include sys/types.h #include unistd.h pid_t vfork(void);vfork()在早期內(nèi)存昂貴的年代很流行因為子進程反正馬上要替換成新程序沒必要復制父進程地址空間。但它有一個致命的問題子進程共享父進程的地址空間一旦子進程在exec之前修改了變量父進程也會“被修改”。在多線程環(huán)境下vfork()還容易引發(fā)死鎖。現(xiàn)代Linux上fork()已經(jīng)通過COW做得很高效了所以我個人強烈建議新代碼一律用fork()不要再用vfork()。除非你在維護歷史包袱很重的老項目否則沒有任何理由主動選擇vfork()。2.4 創(chuàng)建進程后子進程到底“繼承”了什么很多人在fork()后搞不清楚哪些資源是繼承的哪些是獨立的。這里我列一份清單是我在實際開發(fā)中總結出來的類別繼承共享或復制獨立重新創(chuàng)建文件描述符繼承且指向同一文件表項共享文件偏移量各自有獨立的fd編號空間內(nèi)存寫時拷貝邏輯上獨立物理頁面按需復制進程ID無子進程新PID獨立父進程ID子進程的getppid()得到父進程PID獨立信號處理器繼承各自的掛起信號集獨立環(huán)境變量繼承可獨立修改當前工作目錄繼承可獨立chdirumask繼承可獨立修改堆/棧數(shù)據(jù)邏輯上復制獨立這里最容易踩坑的是文件描述符共享。fork()后父子進程的文件描述符指向同一個“打開文件描述”open file description所以它們共享同一個文件偏移量。如果一個進程讀了文件另一個進程的文件偏移也會變。這個特性在某些場景是優(yōu)點比如父子協(xié)作寫日志但有時候也能給你整出莫名其妙的Bug。3. 進程終止exit()、_exit()、return的三方博弈3.1 三種退出方式到底該怎么選進程終止有幾種方式從main()返回本質(zhì)是調(diào)用了exit()。顯式調(diào)用exit(int status)。顯式調(diào)用_exit(int status)或_Exit(int status)。被信號殺死如SIGKILL、SIGSEGV。exit()和_exit()的最大區(qū)別是exit()是C標準庫函數(shù)它會先執(zhí)行清理工作再進入內(nèi)核終止進程_exit()是系統(tǒng)調(diào)用直接進入內(nèi)核終止進程不做任何用戶態(tài)清理。具體來說exit()會做這些事調(diào)用通過atexit()或on_exit()注冊的清理函數(shù)鉤子函數(shù)。刷新標準I/O緩沖區(qū)stdiobuffer把數(shù)據(jù)真正寫出去。關閉所有標準I/O流。調(diào)用_exit()進入內(nèi)核完成真正的終止。而_exit()直接進入內(nèi)核以上步驟全部跳過。這也是一個經(jīng)典Bug的來源如果在程序中用printf輸出但沒有換行且緩沖區(qū)未滿數(shù)據(jù)還留在緩沖區(qū)內(nèi)此時如果調(diào)用_exit()這條輸出可能永遠不會被寫出來?？创a#include stdio.h #include unistd.h #include stdlib.h int main() { printf(這條消息有換行\(zhòng)n); printf(這條消息沒有換行); // _exit(0); // 如果用這個第二條printf的內(nèi)容可能丟失 exit(0); // 這個會刷新緩沖區(qū)正常輸出 }在終端下因為默認是行緩沖第一個printf帶換行會立即輸出第二個printf不帶換行但exit()會刷新緩沖區(qū)所以能看到。如果換成_exit(0)第二個printf的內(nèi)容就可能丟失。所以我的建議是普通應用代碼用return或exit()在寫庫代碼、驅動、嵌入式裸機環(huán)境、或者對資源釋放邏輯有嚴格控制時才考慮_exit()。注意exit()不是異步信號安全的函數(shù)。在信號處理函數(shù)里調(diào)用exit()是未定義行為應該用_exit()。我曾經(jīng)在一個信號處理函數(shù)里用了exit()結果在特定競態(tài)下直接卡死排查了很久才定位到。3.2 退出狀態(tài)碼不只是“0和非0”exit(int status)里的status到底怎么被內(nèi)核和父進程解讀這個知識點在寫腳本、寫服務時特別重要。status是一個8位的值0~255傳給內(nèi)核后父進程通過wait()或waitpid()可以取到這個退出狀態(tài)。shell中用$?獲取的就是這個值。但這里有個細節(jié)如果你傳了一個大于255的值實際生效的是status 0xFF。比如exit(300)父進程拿到的退出狀態(tài)實際是44。這個坑我在一次代碼評審里抓到過——同事寫了個工具里面exit(512)他在腳本里判斷返回值是否等于512結果永遠不成立。另一個容易混淆的點wait()返回的狀態(tài)中不僅包含退出碼還包含“是否被信號終止”的信息。通過WIFEXITED、WEXITSTATUS、WIFSIGNALED、WTERMSIG這些宏來解析#include sys/wait.h #include stdio.h #include stdlib.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { // 子進程 exit(42); } else if (pid 0) { int status; waitpid(pid, status, 0); if (WIFEXITED(status)) { printf(子進程正常退出退出碼%d\n, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf(子進程被信號殺死信號編號%d\n, WTERMSIG(status)); } } return 0; }實際編碼時我一般建議統(tǒng)一約定退出碼含義0表示成功1表示通用錯誤2表示參數(shù)錯誤其他數(shù)字按模塊劃分。并且要在文檔里寫清楚。3.3 僵尸進程進程“死了”但沒“死透”進程終止后會進入僵尸狀態(tài)Zombie。這個狀態(tài)的含義是進程已經(jīng)終止釋放了大部分資源內(nèi)存、打開的文件、信號量等但它的task_struct還留在內(nèi)核進程表中等待父進程來收取它的退出狀態(tài)。為什么要留著因為父進程可能需要知道子進程是正常退出還是被信號殺死的。內(nèi)核必須保留這一小段信息直到有人來“收尸”。如果父進程一直不調(diào)用wait()/waitpid()僵尸進程就會一直殘留。更糟的是如果父進程自身先退出了子進程就變成孤兒進程由initPID為1的進程收養(yǎng)init會周期性地調(diào)用wait來清理這些僵尸。但有一種情況非常棘手如果一個父進程會創(chuàng)建很多子進程且不回收它們那僵尸進程會越積越多最終把進程表塞滿導致系統(tǒng)無法創(chuàng)建新進程。我在做一個批量任務處理工具時就遇到過一次每處理一個文件就fork一個子進程但父親忘了waitpid跑了幾天后整個系統(tǒng)不能創(chuàng)建進程了ps一看滿屏的defunct。避免僵尸進程的三個常用手段父進程顯式waitpid()阻塞或非阻塞地回收。父進程用SIGCHLD信號在信號處理中異步回收。兩層fork中間層進程先退出讓最底層子進程被init收養(yǎng)。3.4 孤兒進程與守護進程的關聯(lián)孤兒進程指的是父進程先退出子進程還在運行的情況。內(nèi)核會把孤兒進程的父進程ID改為1即init進程由它來負責收尸。這個特性是寫守護進程daemon的基礎之一。經(jīng)典的守護進程編寫流程中就有一步是“fork一次然后父進程退出”這樣子進程就變成孤兒被init收養(yǎng)不再隸屬于原來的終端會話。這樣一來即使終端關閉進程也不會收到SIGHUP信號。我當時從零寫過一個守護進程流程是這樣的fork()父進程退出子進程繼續(xù)。子進程調(diào)用setsid()創(chuàng)建新會話脫離控制終端。二次fork()再次父進程退出確保不會重新獲得控制終端。修改當前工作目錄為/避免占用掛載點。重設umask為0保證后續(xù)創(chuàng)建的文件的權限不受影響。關閉標準輸入/輸出/錯誤把日志重定向到文件。這個過程里進程創(chuàng)建和終止的手段交叉使用每一步都是為了“隔離”進程和終端的關聯(lián)。理解了進程控制再去看daemon代碼就會很順暢。4. 實測從fork到exec再到進程替換4.1exec族函數(shù)創(chuàng)建進程的“第二梯隊”fork()創(chuàng)建了一個和父進程幾乎一樣的子進程但很多時候我們的目的是讓子進程去運行一個全新的程序比如ls、python腳本或者另一個自己寫的可執(zhí)行文件。這時候就需要exec族函數(shù)。exec族函數(shù)有6個#include unistd.h extern char **environ; int execl(const char *pathname, const char *arg, ... /*, (char *) NULL */); int execlp(const char *file, const char *arg, ... /*, (char *) NULL */); int execle(const char *pathname, const char *arg, ... /*, (char *) NULL, char *const envp[] */); int execv(const char *pathname, char *const argv[]); int execvp(const char *file, char *const argv[]); int execvpe(const char *file, char *const argv[], char *const envp[]);它們之間的區(qū)別主要在于帶l的是逐個參數(shù)列表傳遞必須以NULL結尾。帶v的是字符串數(shù)組傳參。帶p的會在PATH環(huán)境變量中搜索可執(zhí)行文件。帶e的可以自定義環(huán)境變量。帶f的則是以文件描述符為參數(shù)Linux/BSD擴展。我實際用得最多的是execvp因為它支持從PATH里找命令參數(shù)用數(shù)組好維護#include stdio.h #include unistd.h #include sys/wait.h #include stdlib.h int main() { pid_t pid fork(); if (pid 0) { // 子進程替換成 ls -l char *argv[] {ls, -l, NULL}; execvp(ls, argv); // 如果 exec 失敗會走到這里 perror(execvp error); exit(127); } else if (pid 0) { int status; waitpid(pid, status, 0); if (WIFEXITED(status)) { printf(子進程退出碼%d\n, WEXITSTATUS(status)); } } return 0; }這里有一個關鍵點exec成功時不會返回失敗時返回-1并設置errno。很多人的Bug就出在忘記判斷exec失敗后的處理。exec失敗后你的子進程還是那個“原樣”的進程它會繼續(xù)往下執(zhí)行——如果不顯式exit后面的代碼就瘋狂執(zhí)行而且是在一個“本該被替換掉”的進程里。4.2system()一個被你用小了的“黑盒”system()函數(shù)其實是fork exec waitpid的封裝#include stdlib.h int system(const char *command);它的實現(xiàn)邏輯大致是fork一個子進程子進程里執(zhí)行/bin/sh -c command父進程等待子進程結束。它把進程創(chuàng)建和終止打包成了一個好用的API但正因為它是一個黑盒問題也不少它依賴/bin/sh受shell行為和PATH影響。它內(nèi)部會阻塞等待命令完成不適合高頻調(diào)用。處理用戶輸入時如果命令字符串拼接不當存在命令注入風險。它還會屏蔽掉SIGINT和SIGQUIT可能在交互程序里引發(fā)意外行為。我在實際開發(fā)中能用fork execvp解決的問題盡量不用system。只有那種“我就想臨時跑一條shell命令跑完拉倒”的場景才用system。4.3 一個完整的“創(chuàng)建-替換-回收”案例我把剛才提到的所有組件拼成一個完整的案例。假設我們要寫一個“任務執(zhí)行器”主進程讀取命令列表每一條命令創(chuàng)建子進程執(zhí)行并收集輸出和退出狀態(tài)。#include stdio.h #include stdlib.h #include string.h #include unistd.h #include sys/wait.h void run_command(const char *cmd) { pid_t pid fork(); if (pid 0) { perror(fork); return; } if (pid 0) { // 子進程用 /bin/sh -c 來支持管道、重定向 execl(/bin/sh, sh, -c, cmd, (char *)NULL); // 只有 exec 失敗才走到這里 perror(execl); exit(127); } // 父進程等待并匯報狀態(tài) int status; if (waitpid(pid, status, 0) -1) { perror(waitpid); return; } if (WIFEXITED(status)) { printf([%s] %d\n, cmd, WEXITSTATUS(status)); } else if (WIFSIGNALED(status)) { printf([%s] 信號 %d 殺死\n, cmd, WTERMSIG(status)); } } int main() { run_command(echo hello world); run_command(ls /nonexistent); run_command(sleep 0.1); return 0; }實跑下來輸出類似[echo hello world] 0 ls: cannot access /nonexistent: No such file or directory [ls /nonexistent] 2 [sleep 0.1] 0這個案例看起來簡單但你把它放到“批量任務執(zhí)行、按結果統(tǒng)計成功失敗”的場景里就是一個非常實用的小框架。很多人寫構建腳本、發(fā)布腳本時會在shell里用set -e到處拼命令但如果你需要編程化地處理每一條命令的結果用這套C代碼的思路是完全一致的。5. 常見問題與排查技巧實錄5.1 進程“消失”了但輸出還在怎么回事有一次我用fork后在子進程里printf然后在父進程里直接return發(fā)現(xiàn)終端上輸出亂了。原因是子進程繼承了父進程的stdio緩沖區(qū)。父進程退出時exit()刷新了緩沖區(qū)同時打印了內(nèi)容。子進程可能也在某個時刻刷新同一塊緩沖區(qū)內(nèi)容。這在“父子進程都要向同一個終端輸出”時特別明顯。我的解決方案每個子進程啟動時如果需要獨立輸出先fflush(NULL)清掉緩沖區(qū)再執(zhí)行新邏輯更徹底的是在fork之前就把stdio的緩沖模式改成_IONBF無緩沖。實操心得fork()之后父子進程的stdio緩沖區(qū)并不是“各復制一份”而是“共享同一份物理緩沖區(qū)”因為COW只針對已經(jīng)被修改的頁面。如果你在fork前有未刷新的輸入輸出數(shù)據(jù)fork之后兩邊各自操作緩沖區(qū)會互相污染。所以一條鐵律fork之前保證緩沖區(qū)干凈或者fork之后立即fflush或exit。5.2waitpid的阻塞與非阻塞waitpid默認是阻塞式的父進程會一直等著子進程退出。但有些場景你不希望父親一直掛起比如父親是一個事件循環(huán)。這時可以用WNOHANG選項pid_t ret waitpid(pid, status, WNOHANG); if (ret 0) { // 子進程還沒退出 } else if (ret pid) { // 已回收 } else { // 出錯 }但如果子進程退出狀態(tài)一直沒人收僵尸進程就會積累。事件循環(huán)里我一般用SIGCHLD信號配合sigwaitinfo這種方式來異步回收或者直接統(tǒng)一在事件循環(huán)輪詢的間隙里調(diào)一遍waitpid(..., WNOHANG)。5.3 信號干擾導致的fork失敗fork()失敗時返回-1errno可能有很多種。常見的是EAGAIN表示進程數(shù)或內(nèi)存不足。但還有一個不太容易察覺的坑如果進程被信號打斷比如SIGCHLD或SIGINTfork()是有可能返回失敗的尤其在高并發(fā)環(huán)境下。解決方式在調(diào)用fork()之后判斷返回值如果小于0仔細看errno必要時做一些退避重試或者直接向上匯報錯誤。5.4 僵尸進程排查快查表我把自己排查僵尸進程的常用套路整理一下現(xiàn)象可能原因排查方法ps出現(xiàn)很多defunct父進程沒調(diào)用wait/waitpid用ps -ef父進程退出后僵尸還在可能被init接管但未能及時回收查看PPID是否為1init一般會清理僵尸進程數(shù)量緩慢增長父進程在循環(huán)里fork但只處理了一部分退出狀態(tài)檢查代碼中每個fork分支是否有對應的waitpid系統(tǒng)無法創(chuàng)建新進程進程表滿了cat /proc/sys/kernel/pid_max和 ps -eLf我記得有一次幫同事排查一個后臺任務框架ps里僵尸進程成百上千查了半天才發(fā)現(xiàn)是父進程在異常分支里return了導致waitpid代碼沒執(zhí)行到。那個問題之所以隱蔽是因為正常情況下父子流程都能走到waitpid只有特定的輸入序列觸發(fā)異常分支才會丟僵尸。5.5 如何調(diào)試多進程程序調(diào)試多進程程序比調(diào)試單進程麻煩得多我的經(jīng)驗是用strace -f跟蹤所有進程的系統(tǒng)調(diào)用看fork、execve、exit_group到底發(fā)生在哪里。用gdb調(diào)試時設set follow-fork-mode child可以跟隨子進程。在關鍵流程加日志日志里帶上getpid()便于分辨日志來自哪個進程。用/proc/pid/status查看進程狀態(tài)比如State:字段如果是Z就是僵尸。有個小技巧如果懷疑父進程沒有回收子進程可以手動對該父進程發(fā)一個SIGCHLD信號并觀察它是否觸發(fā)回收邏輯。當然這只是一種快速驗證方法真正修復還是要靠代碼分析。6. 一些值得養(yǎng)成的編碼習慣寫進程控制相關的代碼有些習慣是我這幾年慢慢養(yǎng)成的分享給大家創(chuàng)建子進程之前先把父進程的stdio緩沖區(qū)刷干凈這是一個低成本但能避免大量詭異問題的習慣。特別是用了第三方庫時你根本不知道它有沒有往緩沖區(qū)里塞數(shù)據(jù)。每個fork()后面緊跟判錯pid 0時不要沉默地繼續(xù)跑因為后續(xù)邏輯很可能基于“當前進程是父進程”的假設。子進程里第一件事想清楚如果exec失敗該怎么辦我一般默認exit(127)因為127在shell約定里就是“command not found”的語義方便跟shell行為對齊。父進程區(qū)分“等待單個子進程退出”和“等待任意子進程退出”的語義。前者用waitpid(child_pid, ...)后者用wait(status)。如果搞混在一個多子進程場景里會出現(xiàn)嚴重的邏輯錯亂。不要用vfork除非你在寫一個必須兼容上世紀內(nèi)核的遺留項目。多進程程序里文件描述符的共享語義是一把雙刃劍。父進程打開的文件描述符在子進程中依然打開如果你不想讓子進程繼承可以在fork前把相應的fd設置為FD_CLOEXEC。這個標志配合exec時自動關閉能有效防止文件描述符泄漏到子進程執(zhí)行的新程序里去。這個坑在寫服務端程序時尤其重要——如果不設置FD_CLOEXEC一次fork exec可能把一個監(jiān)聽socket的拷貝帶到子進程里導致通信錯亂。7. 進程控制在未來項目中的著力點進程創(chuàng)建和終止雖然是老生常談的基礎知識但在很多實際項目中仍然扮演著核心角色。比如容器技術的核心就是進程隔離。clone()系統(tǒng)調(diào)用提供的命名空間namespace特性正是容器區(qū)別于普通多進程程序的關鍵。你可以用clone來創(chuàng)建一個帶有獨立PID namespace或mount namespace的進程這比單純理解fork又深了一層。守護進程和systemd服務管理本質(zhì)就是進程生命周期管理。明白了進程終止時退出狀態(tài)碼如何傳遞、SIGCHLD信號如何驅動父進程回收你就知道一個服務管理器是怎么做到的它必須同時管理幾十個上百個進程的創(chuàng)建、監(jiān)控、重啟、退出清理。批量任務調(diào)度系統(tǒng)里進程控制是天然的分層結構。一個調(diào)度器要同時管理多個子進程的并行執(zhí)行、超時終止、資源回收。這里會用上waitpid的WUNTRACED選項——它能讓父進程收到子進程被停止SIGSTOP的消息這可以用來實現(xiàn)任務暫停功能。如果你是在做嵌入式設備開發(fā)fork后地址空間寫時拷貝的機制直接影響你的內(nèi)存峰值計算。一個沒有MMU的單片機上可能根本沒有fork只有vfork或者更底層的線程理解進程模型能幫你判斷哪些代碼可以跨平臺復用。對于后端高并發(fā)服務epoll 多進程模型至今仍是不少網(wǎng)關和高性能代理的核心架構。父進程負責accept連接然后fork子進程處理請求子進程和服務器保持長連接。這種模型下進程創(chuàng)建和終止的頻率會影響整體性能和穩(wěn)定性——你不可能每次來一個請求就fork一次于是就有了進程池、預進程模式。這一切的根源還是得回到fork和wait的語義上來。我個人在實際操作中還有一個體會寫多進程程序時調(diào)試的難度是單進程的好幾倍。不要指望一口氣把代碼寫對更不要靠瞎試來排查問題。推薦的方法是用日志打印每個進程的關鍵動作配合strace觀察系統(tǒng)調(diào)用再結合ps確認進程狀態(tài)。三者一交叉絕大多數(shù)進程控制的問題都能快速定位。這篇文把進程創(chuàng)建和終止的系統(tǒng)性內(nèi)容都覆蓋了一遍。從fork的返回值到COW原理從exit/_exit的區(qū)別到僵尸進程的回收再到exec族函數(shù)的細節(jié)最后給了排查思路和編碼習慣。如果你正好卡在這塊建議直接跟著代碼敲一遍尤其是那個“創(chuàng)建-替換-回收”的完整案例跑通了進程控制的骨架就真正搭起來了。