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