你有沒有遇到過這種情況線上服務(wù)沒多少用戶量CPU 卻飆得離譜或者你 fork 完子進(jìn)程后父子進(jìn)程的打印順序完全不按你預(yù)期的來又或者一個程序明明不復(fù)雜卻頻繁卡頓、僵尸進(jìn)程堆積。這些問題看著五花八門追根溯源全部指向同一個領(lǐng)域——Linux 進(jìn)程管理。這篇內(nèi)容我會從內(nèi)核視角把進(jìn)程管理這條鏈路完整梳理一遍重點(diǎn)拆解兩個核心環(huán)節(jié)進(jìn)程是如何被創(chuàng)建的以及創(chuàng)建之后調(diào)度器又是如何決定“誰先跑、誰后跑、跑多久”的。同時會延伸到進(jìn)程退出、回收和僵尸進(jìn)程這些工程實(shí)戰(zhàn)中一定會踩到的場景基本覆蓋了從創(chuàng)建到調(diào)度、再到銷毀的完整生命周期。適合正在學(xué) Linux 內(nèi)核原理的學(xué)生也適合那些寫多進(jìn)程服務(wù)、做性能排查時經(jīng)常需要面對進(jìn)程模型的開發(fā)者和運(yùn)維。1. 進(jìn)程在Linux里到底是什么——從task_struct說起1.1 “進(jìn)程”不是抽象概念它就是一個結(jié)構(gòu)體實(shí)例教科書上說“進(jìn)程是運(yùn)行中的程序”這句話沒錯但對內(nèi)核開發(fā)者來說太朦朧了。在 Linux 內(nèi)核里進(jìn)程的本質(zhì)就是一塊數(shù)據(jù)一個叫task_struct的結(jié)構(gòu)體實(shí)例。內(nèi)核每創(chuàng)建一個進(jìn)程都會kmalloc出一塊內(nèi)存初始化一個task_struct然后把這個結(jié)構(gòu)體掛到全局任務(wù)鏈表上。進(jìn)程的切換、調(diào)度、信號處理、資源統(tǒng)計(jì)說白了都是在對這塊數(shù)據(jù)做操作。你ps看到一行輸出背后就是遍歷這一堆task_struct節(jié)點(diǎn)然后把字段打印成表格。task_struct是一個非常龐大的結(jié)構(gòu)體包含的字段有幾百個按職責(zé)大致可以分成這幾類職責(zé)代表字段作用狀態(tài)與調(diào)度state、se、prio、static_prio、normal_prio、rt_priority表示進(jìn)程當(dāng)前狀態(tài)、調(diào)度實(shí)體、優(yōu)先級內(nèi)存管理mm、active_mm指向進(jìn)程地址空間描述符文件系統(tǒng)fs、files記錄根目錄、當(dāng)前工作目錄、打開的文件表信號處理sigpending、signal掛起信號和信號處理函數(shù)身份與權(quán)限cred、uid、gid記錄用戶態(tài)身份和權(quán)限相關(guān)信息時間與統(tǒng)計(jì)start_time、utime、stime啟動時間、用戶態(tài)/內(nèi)核態(tài) CPU 時間資源限制rlim進(jìn)程可使用的資源上限用生活里的類比來說每個進(jìn)程像是一個在公司里的員工task_struct就是他的完整檔案袋。檔案里寫著他是誰、在哪個部門調(diào)度器、住哪內(nèi)存、負(fù)責(zé)什么項(xiàng)目文件描述符、上面有多少領(lǐng)導(dǎo)權(quán)限權(quán)限體系。調(diào)度器做決策的時候看的不是“人”就是這份檔案。1.2 在 Linux 里進(jìn)程和線程沒有那么涇渭分明很多人問“Linux 進(jìn)程和線程到底怎么區(qū)分”。答案可能會顛覆你的認(rèn)知在內(nèi)核視角下進(jìn)程和線程沒有本質(zhì)區(qū)別它們都是task_struct。區(qū)別只在于clone()系統(tǒng)調(diào)用時傳入哪些共享標(biāo)志如果父子進(jìn)程共享地址空間CLONE_VM、共享文件表CLONE_FILES、共享信號處理器CLONE_SIGHAND那看起來就是一個“線程組”里的多個線程。如果不共享這些東西各自擁有獨(dú)立的地址空間和資源這就是傳統(tǒng)意義上的“進(jìn)程”。所以 Linux 里的線程準(zhǔn)確叫法是輕量級進(jìn)程Lightweight Process。你平時用ps -eLf可以看到一個進(jìn)程對應(yīng)的多個線程每行一個task_structLWP 就是線程 ID。我實(shí)際排查線程問題時踩過一個坑用top看某個進(jìn)程 CPU 占用不高但整個系統(tǒng)負(fù)載很高。后來用top -H -p PID按線程查看才發(fā)現(xiàn)是其中一個線程在死循環(huán)。這就是因?yàn)檫M(jìn)程是一種“資源容器”CPU 調(diào)度其實(shí)是針對于線程內(nèi)核可調(diào)度實(shí)體進(jìn)行的并不以進(jìn)程為最小單位。2. 進(jìn)程的誕生fork、寫時復(fù)制與執(zhí)行流切換2.1 fork 的語義調(diào)用一次返回兩次Linux 創(chuàng)建進(jìn)程最經(jīng)典的方式就是fork()。這個系統(tǒng)調(diào)用的語義在大學(xué)課本里就寫著調(diào)用一次返回兩次。如果是父進(jìn)程成功調(diào)用fork()內(nèi)核會在父進(jìn)程的地址空間基礎(chǔ)上復(fù)制一份子進(jìn)程的task_struct然后讓父進(jìn)程返回子進(jìn)程的 PID讓子進(jìn)程返回 0。這樣程序里就能通過返回值判斷自己是父還是子#include stdio.h #include unistd.h int main() { pid_t pid fork(); if (pid 0) { perror(fork); return 1; } if (pid 0) { printf(子進(jìn)程PID%d父進(jìn)程PID%d\n, getpid(), getppid()); } else { printf(父進(jìn)程PID%d子進(jìn)程PID%d\n, getpid(), pid); } sleep(1); return 0; }編譯運(yùn)行g(shù)cc -o fork_demo fork_demo.c ./fork_demo你會發(fā)現(xiàn)輸出兩行但順序不一定固定。父和子誰先運(yùn)行完全由調(diào)度器決定。如果你假設(shè)父進(jìn)程一定先執(zhí)行大概率會寫出有并發(fā) Bug 的程序。fork 失敗的情況也得留意。最常見的原因是進(jìn)程數(shù)達(dá)到RLIMIT_NPROC限制或者內(nèi)存不足申請不到內(nèi)核態(tài)數(shù)據(jù)結(jié)構(gòu)。線上服務(wù)器如果 fork 頻繁報 EAGAIN首先去查是不是某個系統(tǒng)服務(wù)把進(jìn)程數(shù)打滿了。2.2 寫時復(fù)制COW為什么 fork 可以這么快早期 Unix 的fork()確實(shí)會完整復(fù)制父進(jìn)程的地址空間包括所有物理頁。后來工程師們想明白一個關(guān)鍵問題fork 之后絕大多數(shù)情況是緊接著調(diào)用exec()加載新程序父進(jìn)程的整個地址空間很快就會被覆蓋丟棄前面復(fù)制那么多頁純屬浪費(fèi)。于是內(nèi)核引進(jìn)了寫時復(fù)制Copy-on-Write機(jī)制。原理一句話概括fork 的時候內(nèi)核不會復(fù)制父進(jìn)程的物理頁只是把父進(jìn)程的頁表復(fù)制一份并把父子進(jìn)程頁表中所有可寫頁表項(xiàng)標(biāo)記為只讀。父子進(jìn)程的虛擬地址此時映射到同一個物理頁。誰先嘗試寫這個頁面誰就會觸發(fā)缺頁異常內(nèi)核在異常處理里做真正的物理頁復(fù)制、更新頁表權(quán)限然后重放這條寫指令。這個過程快在哪fork 本身只需要復(fù)制頁表不需要復(fù)制物理內(nèi)存時間復(fù)雜度大大下降。只有實(shí)際發(fā)生寫入的頁面才會被復(fù)制很多“復(fù)制后不寫”的場景開銷為零。如果 fork 后立刻exec()幾乎不會觸發(fā)缺頁復(fù)制開銷極小。這也是為什么一些 Web 服務(wù)器喜歡用 fork 模型每次都復(fù)制一個很大的進(jìn)程出來但在 exec 之前只做很少的操作整體成本可控。2.3 fork 的變體與 exec工程里到底怎么用真實(shí)工程里直接用裸fork()的情形其實(shí)不算多因?yàn)榇蠖鄶?shù)語言運(yùn)行時會自己做封裝。但你理解原理之后看 C/C 里的pthread_create、Python 的multiprocessing底層就不虛了。fork()有三個值得注意的親戚系統(tǒng)調(diào)用行為典型場景fork()復(fù)制進(jìn)程配合 COW父子獨(dú)立地址空間經(jīng)典進(jìn)程創(chuàng)建vfork()不復(fù)制頁表父進(jìn)程阻塞子進(jìn)程共享父進(jìn)程地址空間直到子進(jìn)程 exec 或退出嵌入式/內(nèi)存受限環(huán)境現(xiàn)在基本被 forkCOW 替代clone()通過 flags 精細(xì)控制父子共享哪些資源pthread_create的底層實(shí)現(xiàn)再來看exec系列。這里有個常見誤區(qū)exec 不是創(chuàng)建進(jìn)程而是替換進(jìn)程。execve()系列系統(tǒng)調(diào)用execl、execlp、execvp等會把當(dāng)前進(jìn)程的代碼段、數(shù)據(jù)段、堆、棧全部換成新可執(zhí)行文件的內(nèi)容但進(jìn)程的 PID、打開的文件描述符默認(rèn)情況下等保持原樣。所以整個生命周期是fork()創(chuàng)建新進(jìn)程。子進(jìn)程調(diào)用exec()加載目標(biāo)可執(zhí)行程序。父進(jìn)程wait()回收子進(jìn)程。這條鏈路從 Unix 時代延續(xù)至今Linux 上跑任何程序的本質(zhì)都是這一套組合拳。提示很多人分不清“執(zhí)行一個程序”和“創(chuàng)建一個進(jìn)程”。執(zhí)行程序必然先創(chuàng)建進(jìn)程或者復(fù)用當(dāng)前進(jìn)程但創(chuàng)建進(jìn)程之后不一定 exec。比如環(huán)境變量設(shè)置、命令行解析這些邏輯都得在 exec 之前做好準(zhǔn)備。3. 調(diào)度器的核心機(jī)制vruntime、CFS與調(diào)度類3.1 調(diào)度器演進(jìn)從遍歷所有進(jìn)程到紅黑樹選最左節(jié)點(diǎn)說完了進(jìn)程怎么來接下來是主角調(diào)度器。它的任務(wù)可以濃縮成一句話——多個進(jìn)程都在可運(yùn)行隊(duì)列里CPU 到底給誰。Linux 調(diào)度器歷史上經(jīng)歷過三個階段O(n) 調(diào)度器2.4 時代每次調(diào)度都要遍歷整個運(yùn)行隊(duì)列計(jì)算每個進(jìn)程的優(yōu)先級、當(dāng)前狀態(tài)等。進(jìn)程數(shù)量多了以后調(diào)度本身消耗的 CPU 時間線性上升這在高負(fù)載服務(wù)器上完全不可接受。O(1) 調(diào)度器2.6 早期引入 active / expired 兩個優(yōu)先級數(shù)組調(diào)度時間變成常數(shù)級。它更重視響應(yīng)速度但對“公平性”的理解比較粗暴交互式進(jìn)程體驗(yàn)不穩(wěn)定。CFS完全公平調(diào)度器2.6.23 之后不再用優(yōu)先級數(shù)組而是維護(hù)一棵紅黑樹用虛擬運(yùn)行時間vruntime作為鍵值每次取最左葉子節(jié)點(diǎn)作為下一個運(yùn)行進(jìn)程。名字叫“完全公平”但實(shí)際是通過權(quán)重實(shí)現(xiàn)“按比例公平”不是絕對平均?，F(xiàn)在的 6.x 內(nèi)核又在 CFS 基礎(chǔ)上引入了 EEVDF最早虛擬截止時間優(yōu)先理念有些變化但 CFS 的虛擬時間模型依然是理解這一切的地基所以我們從 CFS 講起。3.2 核心概念vruntime 是怎么算出來的CFS 的關(guān)鍵變量是vruntime翻譯過來叫“虛擬運(yùn)行時間”。每個進(jìn)程更準(zhǔn)確說是每個調(diào)度實(shí)體都維護(hù)一個自己的vruntime。進(jìn)程運(yùn)行的時間越長vruntime就越大。內(nèi)核每次選擇下一個進(jìn)程時就從紅黑樹里挑出vruntime最小的那個進(jìn)程來運(yùn)行。這樣做的好處很直觀哪個進(jìn)程欠的 CPU 時間最多就先補(bǔ)給他。vruntime的增長速度并不是簡單的 1:1而是經(jīng)過權(quán)重?fù)Q算delta_vruntime delta_exec * NICE_0_LOAD / se_load其中NICE_0_LOAD 1024se_load是當(dāng)前進(jìn)程的權(quán)重。權(quán)重的來源就是 nice 值。nice 值范圍是 -20 到 19內(nèi)核里通過一張靜態(tài)映射表把它轉(zhuǎn)換成權(quán)重nice 值權(quán)值-2088761-109546010245335101101915從這個表格能看到兩個要點(diǎn)。第一nice 0 的進(jìn)程權(quán)重就是 1024vruntime增長速度和真實(shí)運(yùn)行時間一致。第二nice 值每降低一級權(quán)重約增加 1.25 倍每提高一級權(quán)重約減少 0.8 倍。但權(quán)重差不是均勻的。nice 0 到 nice 19 權(quán)重相差約 68 倍。所以如果一個 nice 0 的進(jìn)程和一個 nice 19 的進(jìn)程同時競爭一個 CPUnice 19 的進(jìn)程幾乎跑不動它的vruntime漲得飛快很快就被紅黑樹推到右邊。為了讓你更直觀地感受假設(shè) nice 0 進(jìn)程運(yùn)行 1ms它的vruntime增加 1ms同樣是 1ms 運(yùn)行時間nice 19 進(jìn)程的vruntime增加約1 * 1024 / 15 ≈ 68ms。這就是“低優(yōu)先級進(jìn)程得到更少 CPU”在數(shù)學(xué)上的精確表達(dá)。3.3 為什么是紅黑樹而不是鏈表或數(shù)組這個問題我面試時經(jīng)常被問到。原因很樸素CFS 需要頻繁做兩種操作——插入新喚醒的進(jìn)程、刪除運(yùn)行中的進(jìn)程、找出最小vruntime節(jié)點(diǎn)。鏈表查找最小值是 O(n)數(shù)組插入刪除涉及移動都不適合大量進(jìn)程的場景。紅黑樹能在 O(log n) 時間內(nèi)完成插入、刪除、查找最小節(jié)點(diǎn)平衡操作又能控制樹的深度保證最壞情況下性能也可接受。實(shí)際代碼里調(diào)度器直接把紅黑樹的最左葉子節(jié)點(diǎn)作為下一個要運(yùn)行的進(jìn)程。這棵樹的根在 per-CPU 運(yùn)行隊(duì)列的cfs_rq結(jié)構(gòu)里如果兩個 CPU 上各有一個cfs_rq調(diào)度就是各跑各的只有發(fā)生負(fù)載均衡時才會把進(jìn)程從忙的 CPU 遷移到閑的 CPU。3.4 調(diào)度類不同需求的進(jìn)程走不同的“車道”CFS 管的是普通進(jìn)程但 Linux 里還活著多種調(diào)度需求。為了靈活處理內(nèi)核把調(diào)度器代碼抽象成了“調(diào)度類”sched_class每個task_struct都會掛到某個調(diào)度類下面。從高優(yōu)先級到低優(yōu)先級核心調(diào)度類大致如下調(diào)度類優(yōu)先級典型用途stop_sched_class最高停止 CPU、CPU 熱插拔等內(nèi)核內(nèi)部任務(wù)dl_sched_class高Deadline 調(diào)度嚴(yán)格保證最晚完成時間用于實(shí)時任務(wù)rt_sched_class較高SCHED_FIFO / SCHED_RR傳統(tǒng)實(shí)時調(diào)度fair_sched_class中CFS普通進(jìn)程idle_sched_class最低每個 CPU 的空閑進(jìn)程調(diào)度器選擇進(jìn)程時會從高優(yōu)先級調(diào)度類開始找只有當(dāng)前調(diào)度類沒有可運(yùn)行任務(wù)才會往下走。這就是為什么實(shí)時進(jìn)程能搶占普通進(jìn)程的原因rt_sched_class 在 fair_sched_class 前面。rt 調(diào)度類內(nèi)部又有兩種策略SCHED_FIFO先進(jìn)先出。相同優(yōu)先級的任務(wù)先到先跑沒有時間片的概念直到任務(wù)自己阻塞或退出或者更高優(yōu)先級的任務(wù)出現(xiàn)。SCHED_RR時間片輪轉(zhuǎn)。同優(yōu)先級的任務(wù)輪流運(yùn)行時間片用完就排到隊(duì)尾。用實(shí)時策略時要特別謹(jǐn)慎。如果系統(tǒng)里有一個 SCHED_FIFO 的死循環(huán)進(jìn)程普通進(jìn)程包括 shell、監(jiān)控程序完全得不到 CPU系統(tǒng)看起來就像死機(jī)了鍵盤和鼠標(biāo)都無響應(yīng)。這也是為什么設(shè)置實(shí)時策略需要 root 權(quán)限或CAP_SYS_NICE權(quán)限。3.5 上下文切換的代價為什么更推薦線程調(diào)度器做出決策后就要執(zhí)行上下文切換。這個操作不是簡單切換寄存器而是要保存當(dāng)前進(jìn)程的 CPU 現(xiàn)場恢復(fù)下一個進(jìn)程的現(xiàn)場。進(jìn)程間的上下文切換開銷更大因?yàn)閮蓚€進(jìn)程有不同的地址空間內(nèi)核需要切換內(nèi)核棧。切換 CR3 寄存器使 MMU 指向新進(jìn)程的頁表。刷新 TLBTranslation Lookaside Buffer。重置流水線狀態(tài)新進(jìn)程的指令和數(shù)據(jù)基本都在冷緩存里后續(xù)訪問會頻繁 miss。線程之間切換就好一些它們共享地址空間CR3 不變TLB 也基本不用全部刷新只是切換棧、寄存器、指令指針。所以在高并發(fā)場景里線程模型往往比進(jìn)程模型有更好的上下文切換性能。我在做性能優(yōu)化時測過一個處理服務(wù)用進(jìn)程模型每秒只能承受約 2 萬請求換成線程模型以后接近 5 萬主要差距就是上下文切換的 TLB miss 少了很多。4. 優(yōu)先級、nice值與CPU綁定不知道這些命令等于白搭4.1 nice 值給低優(yōu)先級進(jìn)程“讓路”在用戶態(tài)絕大多數(shù)進(jìn)程都是普通進(jìn)程走 CFS。你能直接用到的干預(yù)手段就是 nice 值。nice名字本身就很有意思——“禮貌”。你的進(jìn)程越禮貌nice 值越大越把 CPU 讓給別人。啟動時指定 nice 值nice -n 10 ./cpu_bound_process對已運(yùn)行的進(jìn)程調(diào)整renice -n 5 -p 1234這里有個很實(shí)際的規(guī)則普通用戶只能把 nice 值調(diào)高讓優(yōu)先級更低不能調(diào)低讓優(yōu)先級更高。比如你自己啟動一個進(jìn)程你可以把自己的進(jìn)程從 nice 0 改成 nice 10但不能改成 nice -10因?yàn)檎{(diào)低優(yōu)先級會搶占其他用戶進(jìn)程的資源內(nèi)核不讓你這么干。只有 root 或者有CAP_SYS_NICE權(quán)限的進(jìn)程才能隨便調(diào)。從實(shí)測角度一個 nice 0 的 CPU 密集進(jìn)程和一個 nice 19 的 CPU 密集進(jìn)程在單核上跑nice 19 的進(jìn)程能被分配到的 CPU 時間會少到讓任務(wù)幾乎無法完成。做批處理任務(wù)時經(jīng)常用 nice 調(diào)低優(yōu)先級避免影響了線上服務(wù)的響應(yīng)。4.2 chrt實(shí)時調(diào)度策略的正確用法如果你需要嚴(yán)格保障某個任務(wù)的最壞情況響應(yīng)時間普通 CFS 滿足不了可以考慮實(shí)時調(diào)度策略。chrt就是設(shè)置實(shí)時策略和優(yōu)先級的工具# 以 SCHED_FIFO 策略運(yùn)行優(yōu)先級 50 chrt -f 50 ./realtime_task # 以 SCHED_RR 策略運(yùn)行優(yōu)先級 30 chrt -r 30 ./realtime_task # 查看當(dāng)前進(jìn)程的調(diào)度策略 chrt -p $$實(shí)時優(yōu)先級范圍是 1~99數(shù)字越大優(yōu)先級越高。普通進(jìn)程的 nice 值范圍是 -20~19和這個實(shí)時優(yōu)先級完全是兩套體系不要混淆。什么場景適合用實(shí)時調(diào)度音頻采集、工業(yè)控制、高頻交易這種對抖動極其敏感的任務(wù)它們需要的是“到了時間就必須運(yùn)行”的硬保證。普通 Web 服務(wù)完全沒必要用了反而有風(fēng)險。我親眼見過有人給一個日志處理進(jìn)程設(shè)了 SCHED_FIFO 高優(yōu)先級結(jié)果它占住 CPU 不放數(shù)據(jù)庫主進(jìn)程餓死整個服務(wù)雪崩。實(shí)時優(yōu)先級不是越高越好它的本質(zhì)是搶占權(quán)必須控制使用范圍。4.3 taskset 與 NUMA綁核要不要用再往下一層是 CPU 親和性CPU affinity。用taskset可以把進(jìn)程綁定到指定的 CPU 核心上# 將進(jìn)程綁定到 CPU0 和 CPU1 taskset -c 0,1 ./cpu_bound # 綁定到 CPU0~3 的任意核心 taskset -c 0-3 ./cpu_bound # 修改已有進(jìn)程的綁定 taskset -pc 0 1234綁核的價值主要體現(xiàn)在緩存和 NUMA 上。如果一個進(jìn)程在多核之間來回遷移它的熱數(shù)據(jù)在 L1/L2 緩存里反復(fù)失效性能損耗明顯。綁定到固定核心后一級二級緩存能保持相對熱度。在 NUMA 架構(gòu)下進(jìn)程訪問本地內(nèi)存和遠(yuǎn)端內(nèi)存的延遲差距能達(dá)到數(shù)倍把進(jìn)程綁定到內(nèi)存所在節(jié)點(diǎn)的本地 CPU 上能顯著降低內(nèi)存訪問延遲。但綁核也不是越多越好。綁定后調(diào)度器就不能在這個進(jìn)程上做負(fù)載均衡了。如果該 CPU 核心本身已經(jīng)很忙其他核心很閑綁核反而會浪費(fèi)算力。我的建議是先不要綁核用性能分析工具比如perf觀察確認(rèn)緩存 miss 和遠(yuǎn)程內(nèi)存訪問是瓶頸再考慮綁定別一上來就綁。5. 進(jìn)程的“身后事”退出、回收與僵尸進(jìn)程5.1 從 exit 到 do_exit進(jìn)程退出到底清理了什么進(jìn)程退出不是簡單的“內(nèi)存釋放”。當(dāng)進(jìn)程調(diào)用exit()或者從 main 函數(shù)返回時內(nèi)核會執(zhí)行do_exit()整個清理過程大概涵蓋釋放用戶態(tài)地址空間mm銷毀頁表和物理頁面。關(guān)閉進(jìn)程打開的所有文件描述符。釋放文件系統(tǒng)相關(guān)結(jié)構(gòu)當(dāng)前目錄引用等。向父進(jìn)程發(fā)送 SIGCHLD 信號喚醒正在 wait 的父進(jìn)程。把進(jìn)程狀態(tài)設(shè)置為僵尸ZOMBIE保留最小信息等待父進(jìn)程回收。注意最后一步。進(jìn)程死了但task_struct并沒有立刻消失。它會以一個僵尸狀態(tài)繼續(xù)留在進(jìn)程表里直到父進(jìn)程調(diào)用wait()或waitpid()來讀取退出狀態(tài)。5.2 僵尸進(jìn)程為什么內(nèi)核不立刻清干凈新同學(xué)第一次看到僵尸進(jìn)程時通常會問既然進(jìn)程都結(jié)束了為什么不立刻回收掉答案是父進(jìn)程有權(quán)知道子進(jìn)程的退出碼。比如一個子進(jìn)程因?yàn)槟承┬ｒ?yàn)失敗而退出退出碼是 3。父進(jìn)程需要拿到這個 3 來判斷子進(jìn)程為什么退出。內(nèi)核必須有地方存這個退出碼又不能為此保留整個地址空間所以就在進(jìn)程表里留下一個最小化的task_struct里面主要是 PID、退出碼、資源統(tǒng)計(jì)、時間統(tǒng)計(jì)。所以僵尸進(jìn)程占用的資源其實(shí)很少它本身沒問題。真正的問題在于如果父進(jìn)程一直不 wait僵尸進(jìn)程就會一直累積。大量僵尸會消耗 PID 表項(xiàng)讓系統(tǒng)無法創(chuàng)建新進(jìn)程。同時運(yùn)維看top的時候滿屏 zombie會嚴(yán)重影響排障判斷。一個經(jīng)典的制造僵尸進(jìn)程的 C 代碼是這樣的#include stdio.h #include unistd.h #include sys/wait.h int main() { pid_t pid fork(); if (pid 0) { // 子進(jìn)程立即退出 return 0; } // 父進(jìn)程不調(diào)用 wait直接掛起 sleep(30); return 0; }編譯運(yùn)行后另開一個終端執(zhí)行ps -el | awk $2 Z你就能看到狀態(tài)為 Z 的僵尸進(jìn)程。父進(jìn)程睡 30 秒后退出僵尸會被系統(tǒng)收養(yǎng)并回收就消失了。5.3 排查和清理僵尸進(jìn)程的實(shí)戰(zhàn)流程在線上服務(wù)器碰到僵尸進(jìn)程第一步不是急著 kill而是理清父子關(guān)系。推薦按這個順序排查# 1. 找出所有僵尸進(jìn)程 ps -el | awk $2 Z # 或 top -b -n 1 | grep zombie # 2. 看僵尸進(jìn)程的父進(jìn)程是誰 ps -o ppid -p zombie_pid # 3. 看父進(jìn)程到底在干什么 ps -fp ppid處理方式取決于父進(jìn)程的情況如果父進(jìn)程是我們的服務(wù)進(jìn)程那問題大概率是代碼里 fork 了子進(jìn)程卻沒有調(diào)用 wait或者只 wait 了一個、另一個沒處理。正確做法是補(bǔ)上waitpid(-1, NULL, WNOHANG)循環(huán)。如果父進(jìn)程是可以安全的重啟或 kill 的進(jìn)程直接把父進(jìn)程 kill 掉它的孤兒進(jìn)程們會被 systemd 收養(yǎng)systemd 會循環(huán) wait 回收僵尸自然消失。如果父進(jìn)程是不能動的重要進(jìn)程可以用SIGCHLD信號處理器或者現(xiàn)成的子進(jìn)程管理器來做回收。提示硬 kill 僵尸進(jìn)程kill -9 zombie_pid是沒有意義的。內(nèi)核里它已經(jīng)“死”了kill 信號不會起任何作用。能做的只有從父進(jìn)程層面去 wait或者干掉父進(jìn)程讓子進(jìn)程被收養(yǎng)。5.4 孤兒進(jìn)程父進(jìn)程沒了誰來管和僵尸進(jìn)程經(jīng)常一起出現(xiàn)的是孤兒進(jìn)程——父進(jìn)程先退出子進(jìn)程還在運(yùn)行。正常情況下子進(jìn)程的父進(jìn)程字段ppid會被改成 1也就是被 init 進(jìn)程現(xiàn)在一般是 systemd收養(yǎng)。systemd 作為祖先會在子進(jìn)程退出時主動調(diào)用wait完成回收。所以孤兒進(jìn)程只要不自己掛住一般不會變僵尸。在容器化環(huán)境里有個細(xì)節(jié)值得注意容器往往沒有完整的 init 進(jìn)程如果容器里的 1 號進(jìn)程不是專門負(fù)責(zé)收尸的 init就可能導(dǎo)致容器內(nèi)的孤兒進(jìn)程沒人回收積累成僵尸。這也是很多容器基礎(chǔ)鏡像額外引入tini之類 init 程序的原因。5.5 不可中斷睡眠 D 狀態(tài)和僵尸不是一回事排查進(jìn)程狀態(tài)時除了 Z還經(jīng)常會看到 D不可中斷睡眠狀態(tài)。D 狀態(tài)通常意味著進(jìn)程正在等待內(nèi)核態(tài) IO比如等待磁盤寫入完成、等待 NFS 響應(yīng)這期間信號殺不掉它因?yàn)閮?nèi)核正在做一些不能半途而廢的操作。大量 D 狀態(tài)進(jìn)程基本說明底層 IO 子系統(tǒng)出問題了比如存儲卡死、網(wǎng)絡(luò)文件系統(tǒng)超時。這種情況排查重點(diǎn)不在進(jìn)程層而是去查存儲和網(wǎng)絡(luò)。我處理過一例 MySQL 實(shí)例無響應(yīng)ps一看幾十個 D 狀態(tài)線程最后定位到是底層存儲設(shè)備故障和數(shù)據(jù)庫配置沒什么關(guān)系。結(jié)尾一點(diǎn)個人體會進(jìn)程管理這塊內(nèi)容學(xué)的時候確實(shí)枯燥但每次線上出問題最后都會回到這些基礎(chǔ)概念。我自己排查過不少 CPU 飆高、服務(wù)掛起的問題最開始的判斷往往不是代碼邏輯而是先看進(jìn)程狀態(tài)、調(diào)度策略、優(yōu)先級這幾個入口。其中 fork 和 wait 的配合、僵尸進(jìn)程和孤兒進(jìn)程的機(jī)制、實(shí)時調(diào)度策略的使用邊界這三個點(diǎn)踩過坑以后就再也忘不掉了。如果你剛接觸 Linux建議不要只盯著top那一排數(shù)據(jù)而是抽時間親手跑一遍 fork、wait、taskset、chrt 的示例看看進(jìn)程狀態(tài)在ps -el里怎么變化。只要把這些實(shí)驗(yàn)做一遍你對“進(jìn)程是怎么活過來又是怎么被安排運(yùn)行的”這件事的理解會比看十篇文章都深刻。