1. 從一次“Broken pipe”說起為什么我決定徹底搞懂管道先把話說在前面如果你寫過任何Linux下的多進程程序那你大概率見過這兩行輸出之一——Broken pipe或者進程莫名其妙卡住不動、像死鎖一樣。我第一次被“管道”正面教育是在一個日志采集模塊里。模塊A從上游接消息處理完之后通過管道交給模塊B做聚合落盤。A處理完一批網(wǎng)絡(luò)斷了一下B那邊沒來得及收完A就把寫端關(guān)了B在read的時候直接拿到EOF整個鏈路靜默停擺日志掉了一大批。排查那天我用strace跟了一下午才把問題盯到那個只有幾十行代碼的管道邏輯上。也是從那時候開始我把進程間通信IPC里最基礎(chǔ)、也最常用的管道機制徹底啃了一遍。后來帶新人凡是要寫多進程程序我都建議先別碰共享內(nèi)存、消息隊列先把管道吃透。原因很簡單管道是IPC里最樸素、最貼近內(nèi)核實現(xiàn)的一種理解了它再去理解其他IPC機制會順很多。這篇文章就圍繞“進程間通信IPC機制管道”展開不講虛的直接把我實際用過的代碼、踩過的坑、排查問題的思路都攤開來。適合三類人看第一次接觸Linux進程通信的新手想在項目里用管道但怕踩坑的開發(fā)者以及準備系統(tǒng)梳理IPC知識的進階讀者。這里先補充一個基礎(chǔ)概念方便后面表述所謂的管道本質(zhì)上就是一個內(nèi)核里的環(huán)形緩沖區(qū)一頭連著進程A的輸出一頭連著進程B的輸入。數(shù)據(jù)不需要落盤在內(nèi)核空間里流動所以它比寫臨時文件的效率高得多但又有明確的字節(jié)流限制——沒有消息邊界沒有隨機訪問數(shù)據(jù)讀走就沒了。這一點會貫穿全文后面很多坑都和它有關(guān)。2. 管道的本質(zhì)一個內(nèi)核緩沖區(qū)再加上兩份文件描述符的“接力”很多人學管道上來就背“管道是先進先出的字節(jié)流”“單向通信”這些都對但都不夠。真正決定你寫代碼時會不會出問題的是下面這組事實管道由內(nèi)核創(chuàng)建通過pipe()系統(tǒng)調(diào)用返回兩個文件描述符一個用于讀一個用于寫。兩個描述符指向同一個管道對象而這個對象內(nèi)部維護著一個緩沖區(qū)。2.1pipe()一次做了什么看一下最簡單的創(chuàng)建代碼#include unistd.h #include stdio.h int main() { int fds[2]; if (pipe(fds) -1) { perror(pipe); return 1; } printf(read fd%d, write fd%d\n, fds[0], fds[1]); return 0; }運行后你會看到類似read fd3, write fd4的輸出。0、1、2被標準輸入、標準輸出、標準錯誤占了所以新打開的描述符從3開始。fds[0]是讀端fds[1]是寫端這個順序別記反我見過不止一個人在代碼里把兩個fd用反結(jié)果數(shù)據(jù)寫進讀端寫操作直接報錯。這里要理解一個關(guān)鍵點pipe()創(chuàng)建管道時讀端和寫端同時屬于當前進程。那怎么變成兩個進程之間的通信答案靠fork()。2.2 fork之后文件描述符發(fā)生了什么fork()會復制整個進程地址空間也包括打開的文件描述符表。子進程拿到的fds[0]和fds[1]和父進程的是同一個內(nèi)核管道對象不是復制了一份緩沖區(qū)。這就是管道能通信的底層基礎(chǔ)——兩個進程共享同一段內(nèi)核緩沖區(qū)。但這里出現(xiàn)了一個所有新手都會遇到的問題管道是單向的而現(xiàn)在父子進程手里同時握著讀端和寫端如果不做處理通信天然就會亂套。2.3 為什么必須在fork后立刻關(guān)閉多余的一端這是管道編程的第一條軍規(guī)。在fork()之后你必須立刻在父進程里關(guān)閉讀端或?qū)懚酥械囊粋€在子進程里關(guān)閉另一個讓每個進程只保留一端。比如父子進程單向通信父進程寫、子進程讀#include unistd.h #include stdio.h #include string.h #include sys/wait.h int main() { int fds[2]; pipe(fds); pid_t pid fork(); if (pid 0) { // 子進程關(guān)閉寫端只保留讀端 close(fds[1]); char buf[64] {0}; ssize_t n read(fds[0], buf, sizeof(buf)); if (n 0) { printf(子進程收到: %s\n, buf); } close(fds[0]); return 0; } // 父進程關(guān)閉讀端只保留寫端 close(fds[0]); const char *msg hello from parent; write(fds[1], msg, strlen(msg)); close(fds[1]); wait(NULL); return 0; }為什么要這么較真因為如果不關(guān)閉多余的一端會有兩個非常隱蔽的后果第一EOF永遠等不到。讀端判斷數(shù)據(jù)是否讀完靠的是read()返回0而read()返回0的條件是“所有寫端都已關(guān)閉”。如果子進程手里還握著一個寫端沒關(guān)那read()永遠不會返回0調(diào)用方會一直阻塞。這個我在實際項目里見過兩次現(xiàn)象就是進程“假死”日志全無gdb一看全卡在read上。第二數(shù)據(jù)流向失控。兩個進程各自都握著讀寫端如果父進程往里寫、子進程也往里寫數(shù)據(jù)就混在一起了。雖然單條write不超過PIPE_BUF時是原子的但多個寫者寫出來的順序毫無保證在需要有序處理的場景里這就是災(zāi)難。所以fork之后第一件事就是把你不需要的那一端close掉。這不是性能優(yōu)化是正確性問題。3. 一個真正能跑通的匿名管道示例父子進程互相傳數(shù)據(jù)理論說完了給一個可以直接抄的完整示例。這個例子比上面那個稍微復雜一點父進程給子進程發(fā)送一個整數(shù)數(shù)組子進程累加求和再把結(jié)果傳回父進程。先上代碼#include unistd.h #include stdio.h #include stdlib.h #include sys/wait.h #define ARRAY_SIZE 10 int main() { int pipe_parent_to_child[2]; int pipe_child_to_parent[2]; if (pipe(pipe_parent_to_child) -1 || pipe(pipe_child_to_parent) -1) { perror(pipe); exit(1); } pid_t pid fork(); if (pid 0) { // 子進程 close(pipe_parent_to_child[1]); // 關(guān)掉第一個管道的寫端 close(pipe_child_to_parent[0]); // 關(guān)掉第二個管道的讀端 int nums[ARRAY_SIZE]; ssize_t n read(pipe_parent_to_child[0], nums, sizeof(nums)); if (n ! sizeof(nums)) { fprintf(stderr, 子進程讀取數(shù)據(jù)不完整\n); exit(1); } int sum 0; for (int i 0; i ARRAY_SIZE; i) { sum nums[i]; } write(pipe_child_to_parent[1], sum, sizeof(sum)); close(pipe_parent_to_child[0]); close(pipe_child_to_parent[1]); return 0; } // 父進程 close(pipe_parent_to_child[0]); // 關(guān)掉第一個管道的讀端 close(pipe_child_to_parent[1]); // 關(guān)掉第二個管道的寫端 int nums[ARRAY_SIZE]; for (int i 0; i ARRAY_SIZE; i) { nums[i] i 1; } write(pipe_parent_to_child[1], nums, sizeof(nums)); int sum; ssize_t n read(pipe_child_to_parent[0], sum, sizeof(sum)); if (n ! sizeof(sum)) { fprintf(stderr, 父進程讀取結(jié)果失敗\n); exit(1); } close(pipe_parent_to_child[1]); close(pipe_child_to_parent[0]); wait(NULL); printf(子進程計算的和是: %d\n, sum); return 0; }編譯運行g(shù)cc pipe_demo.c -o pipe_demo ./pipe_demo輸出子進程計算的和是: 55也就是1到10的和。這個例子有兩個值得說透的設(shè)計點。為什么用兩個管道而不是一個因為管道是單向的。有人會想那我用一個管道父子進程都保留讀寫端不是也能雙向傳嗎前面說過兩個寫者同時往一個管道寫數(shù)據(jù)交叉無法控制更關(guān)鍵的是如果我讀了本該對方讀的數(shù)據(jù)邏輯就全亂了。所以雙向通信的常規(guī)做法就是建兩個管道各管一個方向。這個方案簡單、清晰、永遠可靠。為什么在代碼里校驗read()的返回值因為管道是流式的你可能一次read讀不滿你請求的字節(jié)數(shù)。管道不保證“只要寫了N字節(jié)一次read就能讀到N字節(jié)”。read返回多少取決于緩沖區(qū)當前有多少數(shù)據(jù)。這點和讀普通文件不一樣普通文件的read通常能一次讀滿但管道的read可能讀一半就返回了。上面代碼里我用sizeof(nums)直接請求讀完整數(shù)組這在數(shù)據(jù)量小、且寫端一次寫入時通常是成立的但嚴謹?shù)墓こ檀a應(yīng)該循環(huán)讀取直到讀夠指定字節(jié)。數(shù)據(jù)量一大這個假設(shè)就會出問題。我見過生產(chǎn)環(huán)境的bug就是某次消息體超過管道緩沖區(qū)的一半read只讀回了前半截后面的全丟了。所以記得對管道做read時永遠要寫一個“讀滿指定字節(jié)數(shù)”的循環(huán)或者明確校驗返回值不要假設(shè)一次read能拿全所有數(shù)據(jù)。4. 寫端關(guān)閉的語義EOF、read返回0和SIGPIPE信號這一節(jié)是整個管道機制里最容易讓人栽跟頭的部分。很多詭異問題根子都在“寫端何時關(guān)閉”這五個字上。4.1 四種典型場景我把讀端讀數(shù)據(jù)時可能遇到的四種情況列出來對照著看最好理解場景讀端行為緩沖區(qū)里有數(shù)據(jù)寫端還開著read返回實際讀到的字節(jié)數(shù)正常消費緩沖區(qū)為空寫端還開著read阻塞直到有數(shù)據(jù)或?qū)懚岁P(guān)閉緩沖區(qū)有數(shù)據(jù)所有寫端都已關(guān)閉read先把剩余數(shù)據(jù)讀完下次調(diào)用返回0緩沖區(qū)為空所有寫端都已關(guān)閉read直接返回0表示EOFEOF的本質(zhì)不是“沒有數(shù)據(jù)了”而是“再也不會有人寫數(shù)據(jù)了”。判斷依據(jù)是管道所有的寫端描述符都已關(guān)閉不是“寫端進程退出了”。這兩個經(jīng)常被混為一談。舉個實際的例子。父進程fork后如果父進程忘了close(fds[1])子進程讀端read永遠不會返回0即使父進程已經(jīng)exit。因為你這個進程是fork出來的父進程手里那份寫端描述符還活著。父進程退出只是關(guān)閉了它自己的那一個寫端只要這個管道對象還至少有一個寫端引用在任意進程中存在EOF都不會發(fā)生。這就是章節(jié)2.3里強調(diào)“關(guān)閉多余寫端”的深層原因。4.2 SIGPIPE和“Broken pipe”到底是什么再看另一側(cè)。當讀端已經(jīng)全部關(guān)閉寫端還在往管道里寫數(shù)據(jù)時內(nèi)核會向?qū)戇M程發(fā)送SIGPIPE信號。這個信號的默認動作是終止進程。你寫的程序如果在終端里跑經(jīng)常會看到Broken pipe或者進程直接退出就是它干的。還是用父子進程的例子。父進程fork之后子進程立刻關(guān)閉了讀端父進程還往管道里寫這時候父進程就會收到SIGPIPE。如果父進程不處理這個信號它會直接死掉。處理方式有兩種第一種忽略信號讓write返回EPIPE錯誤#include signal.h signal(SIGPIPE, SIG_IGN); // 之后 write() 會返回 -1errno 為 EPIPE第二種用sigaction注冊自定義處理函數(shù)記錄日志再做清理。我個人的建議是凡是寫管道的進程都先把SIGPIPE忽略掉。原因很直白——管道對端的生命周期不受你控制對方隨時可能掛掉如果讓默認的SIGPIPE直接把你的進程干掉你連清理現(xiàn)場的機會都沒有。忽略信號之后讓write返回錯誤碼你再決定是重試還是放棄主動權(quán)在自己手里。這里還藏著一個坑write寫入的數(shù)據(jù)量小于等于PIPE_BUF時是原子的大于PIPE_BUF時就不保證了。如果對端已經(jīng)關(guān)閉你的write可能寫進去一部分才收到EPIPE這時候你連“到底寫了多少”都說不清。所以像socket編程一樣寫管道也要做好部分寫入的重試或回滾設(shè)計不能想當然。5. 匿名管道和命名管道FIFO什么時候該用誰聊完匿名管道再來說說它的“兄弟”——命名管道也就是FIFO。兩者底層機制幾乎相同都是內(nèi)核緩沖區(qū)都是字節(jié)流單向通信但適用場景完全不同。匿名管道沒有名字只能通過fork傳遞文件描述符所以它天然只適用于父子進程或親緣關(guān)系進程之間的通信。沒有親緣關(guān)系的兩個進程拿不到對方的文件描述符匿名管道就沒法用。FIFO在文件系統(tǒng)里有一個路徑名任意兩個進程只要知道這個路徑都能通過它通信。這就解決了無親緣關(guān)系進程之間用管道通信的問題。5.1 FIFO的基本用法創(chuàng)建FIFO用mkfifo命令行或者在代碼里用mkfifo()函數(shù)mkfifo /tmp/myfifo代碼里創(chuàng)建#include sys/types.h #include sys/stat.h if (mkfifo(/tmp/myfifo, 0644) -1) { perror(mkfifo); }一個典型的FIFO通信長這樣。進程A寫#include fcntl.h #include stdio.h #include unistd.h int main() { int fd open(/tmp/myfifo, O_WRONLY); if (fd -1) { perror(open); return 1; } write(fd, hello fifo, 11); close(fd); return 0; }進程B讀#include fcntl.h #include stdio.h #include unistd.h int main() { int fd open(/tmp/myfifo, O_RDONLY); if (fd -1) { perror(open); return 1; } char buf[64] {0}; ssize_t n read(fd, buf, sizeof(buf)); printf(讀取到: %s\n, buf); close(fd); return 0; }注意先啟動哪個都行因為open一個FIFO用于讀時會阻塞直到有寫者打開用于寫時會阻塞直到有讀者打開。這個阻塞特性既是便利也是坑。5.2 阻塞與非阻塞打開的坑openFIFO時默認是阻塞模式。這意味著以只讀方式open一個FIFO如果當前沒有寫者打開它這個調(diào)用會一直阻塞。以只寫方式open一個FIFO如果當前沒有讀者打開它這個調(diào)用也會一直阻塞。我見過典型的啟動順序問題服務(wù)里兩個模塊都由守護進程拉起模塊X先啟動試圖openFIFO等待模塊Y結(jié)果模塊Y因為依賴沒就緒遲遲不啟動模塊X一直卡在open整個啟動流程就僵住了。解決方法是使用非阻塞模式打開int fd open(/tmp/myfifo, O_RDONLY | O_NONBLOCK);非阻塞模式下只讀打開FIFO會立即成功即使沒有寫者只寫打開FIFO如果沒有讀者open會返回ENXIO錯誤。這樣你就需要自己處理重試邏輯但進程不會卡死。什么時候用阻塞什么時候用非阻塞如果兩個進程的生命周期強綁定比如同一個服務(wù)的master和worker用阻塞模式通常更省事因為內(nèi)核幫你做了同步。如果是兩個獨立部署的模塊我建議用非阻塞加輪詢或條件處理至少在啟動階段要非阻塞部署順序問題夠你喝一壺的。5.3 匿名管道與FIFO對比維度匿名管道FIFO是否需要文件系統(tǒng)路徑不需要需要進程關(guān)系要求必須有親緣關(guān)系無要求創(chuàng)建方式pipe()mkfifo()生命周期隨最后一個fd關(guān)閉而消失以文件形式存在需手動刪除典型場景父子進程、shell管道無親緣關(guān)系的兩個服務(wù)進程另外提醒一點FIFO是文件系統(tǒng)里的節(jié)點但用完之后記得unlink刪除。如果你不刪重啟時再mkfifo會拿EEXIST錯誤而且這個“文件”不占磁盤數(shù)據(jù)塊只占一個inode節(jié)點但留在那里容易讓后來維護的人誤判它是普通文件。我自己習慣在程序里創(chuàng)建FIFO后立刻登記到清理邏輯里進程退出前統(tǒng)一刪除。6. 管道的原子性、緩沖區(qū)與雙向通信的“正確姿勢”管道還有一些底層細節(jié)平時用不到但一旦遇到性能問題或者并發(fā)寫入就會變成決定成敗的關(guān)鍵。6.1 PIPE_BUF和寫入原子性Linux手冊里定義了PIPE_BUF它表示“對管道的一次原子寫操作的最大字節(jié)數(shù)”。在Linux上這個值通常是4096字節(jié)但要注意它可能隨內(nèi)核配置變化需要用pathconf查詢確認。具體規(guī)則是這樣的如果write的數(shù)據(jù)量小于等于PIPE_BUF這次寫入是原子的。多個進程同時寫管道時內(nèi)核保證這些數(shù)據(jù)不會交錯。也就是說要么這次寫入的數(shù)據(jù)完整地排在已寫數(shù)據(jù)后面要么完全不影響其他寫入。如果write的數(shù)據(jù)量大于PIPE_BUF原子性就沒有保證了。多個寫者同時寫時數(shù)據(jù)可能交錯穿插。如果你依賴“一條消息的完整字節(jié)流必須連續(xù)”這樣的語義就會出問題。這直接決定了多個進程共享同一個管道寫端時單條消息大小最好控制在PIPE_BUF之內(nèi)。超過的話要么在應(yīng)用層加鎖要么換用消息隊列這類有消息邊界的IPC機制。6.2 雙向通信的誤區(qū)不要幻想一個管道能雙向跑上一個章節(jié)的例子已經(jīng)說明雙向通信要用兩個管道。我在這里再補充一下為什么不建議用單個管道。假設(shè)父子進程共享同一個管道的讀寫端然后形成如下局面父進程寫入請求子進程讀取。子進程寫入響應(yīng)父進程讀取。表面看起來沒問題但只要兩邊同時寫就會交叉而且一旦設(shè)計成“A寫完等B讀B讀完再寫回”的同步模式單管道也能勉強跑但責任劃分太脆弱。兩個管道各管一個方向語義清晰排查也方便值得多花一次pipe()調(diào)用。6.3 管道緩沖區(qū)的大小和動態(tài)調(diào)整Linux管道的默認緩沖區(qū)大小歷史上是65536字節(jié)64KB而不是很多教材上寫的4KB。4KB那個數(shù)值是PIPE_BUF——原子寫的上限它不等于緩沖區(qū)總?cè)萘?。這兩個概念很容易混。如果覺得64KB不夠用可以從內(nèi)核2.6.35開始用fcntl調(diào)整管道緩沖區(qū)大小#include fcntl.h #include unistd.h int pipe_fds[2]; pipe(pipe_fds); // 獲取當前緩沖區(qū)大小 int size fcntl(pipe_fds[0], F_GETPIPE_SZ); printf(當前緩沖區(qū)大小: %d\n, size); // 嘗試設(shè)置為1MB fcntl(pipe_fds[0], F_SETPIPE_SZ, 1024 * 1024);注意F_SETPIPE_SZ只對管道的讀端文件描述符生效而且內(nèi)核有自己的上限限制默認情況下不允許設(shè)置超過系統(tǒng)允許的最大值。非特權(quán)用戶通常最多能設(shè)置到1MB。我用這個特性處理過一個數(shù)據(jù)傳輸場景上游一次性dump出300KB的序列化數(shù)據(jù)如果不調(diào)大緩沖區(qū)寫入方和讀取方的調(diào)度就會出現(xiàn)頻繁的交替喚醒性能很難看。調(diào)大之后整個傳輸過程順暢很多。7. 管道排障實戰(zhàn)從“卡死”到“斷管”的定位鏈路最后這部分是我最想分享的。管道相關(guān)的bug癥狀通常就兩類進程卡住不動或者進程收信號退出。但這些癥狀背后原因千奇百怪定位是有套路可循的。7.1 現(xiàn)象一進程卡死read永遠不返回碰到這種問題我一般按下面這個順序排查。先懷疑寫端描述符沒有全部關(guān)閉。用ls -l /proc/pid/fd看這個進程當前持有的文件描述符重點看有沒有多余的管道寫端。命令長這樣ls -l /proc/12345/fd | grep pipe你會看到一堆pipe:[inode號]這樣的輸出。把inode號相同的條目數(shù)一下如果既有讀又有寫而且不屬于你預(yù)期的持有方基本就是多余的fd沒有關(guān)閉。我處理過的一個真實案例主進程fork了兩個子進程各自負責一部分數(shù)據(jù)結(jié)果其中一個子進程在初始化時fork了一個臨時進程那個臨時進程繼承了管道fd后又沒有關(guān)閉導致主讀取端永遠等不到EOF。再看是不是有進程持有了寫端但從來不寫。這種情況比上一種更隱蔽。用lsof查誰還開著這個管道lsof | grep pipe如果發(fā)現(xiàn)某個進程持有寫端但已經(jīng)卡死在別的地方那你讀端的進程自然就永遠阻塞。解決方案要么殺掉持有者要么在業(yè)務(wù)邏輯里加超時控制。7.2 現(xiàn)象二Broken pipe進程被信號打死這類問題有兩個排查要點。第一確認是誰觸發(fā)了SIGPIPE。給程序加信號處理前先用strace跟一下strace -f -o /tmp/trace.log ./your_program然后看trace日志里最后一個成功執(zhí)行的系統(tǒng)調(diào)用如果緊接著是--- SIGPIPE {si_signoSIGPIPE, ...} ---說明write往一個沒有讀端的管道里寫了數(shù)據(jù)。第二檢查業(yè)務(wù)邏輯里對端生命周期是否早于預(yù)期結(jié)束。管道對端進程退出不代表它死了也可能它只是正常完成了任務(wù)。但讀端的關(guān)閉會讓寫端下一次寫數(shù)據(jù)時收到SIGPIPE。工程上最穩(wěn)妥的寫法是寫端進程忽略SIGPIPE然后嚴格檢查每次write的返回值。7.3 現(xiàn)象三數(shù)據(jù)不完整但進程沒報錯這通常出在“部分讀”或“部分寫”上。read和write返回的字節(jié)數(shù)小于你請求的字節(jié)數(shù)但返回值是正數(shù)代碼里如果沒做循環(huán)處理數(shù)據(jù)就悄悄丟了。這種問題比報錯更危險因為沒有任何異?，F(xiàn)象。排查這類問題可以用dd模擬讀取確認管道里實際能讀出多少數(shù)據(jù)dd if/tmp/myfifo bs4096 count1如果dd出來的字節(jié)數(shù)和預(yù)期不符說明寫入端可能沒有真正寫全。7.4 管道排障自查清單我把經(jīng)驗濃縮成下面這張清單遇到管道問題直接照著過一遍。檢查項操作目的多余fdls -l /proc/pid/fd確認所有不需要的讀寫端都已關(guān)閉寫端存活lsof | grep pipe確認管道對象沒有“僵尸”持有者信號處理查看是否忽略SIGPIPE避免進程被信號打死讀寫循環(huán)檢查read/write返回值確認沒有部分讀寫的遺漏緩沖區(qū)大小fcntl(F_GETPIPE_SZ)確認數(shù)據(jù)量不超過緩沖區(qū)原子性確認單條寫小于PIPE_BUF避免并發(fā)寫入數(shù)據(jù)交錯8. 寫在最后的個人建議我這幾年寫多進程程序的體會是能用管道解決的別急著上更復雜的IPC機制。管道的模型足夠簡單行為可預(yù)期調(diào)試手段成熟一個strace加一個ls /proc/fd就能看穿一切。相比之下共享內(nèi)存要考慮同步、緩存失效和崩潰恢復消息隊列要考慮節(jié)點管理和消息類型約定這些東西在業(yè)務(wù)早期都是不小的負擔。真到了需要推倒重來的臨界點標志也很明顯比如你的單條消息超過64KB、你需要隨機訪問歷史數(shù)據(jù)、或者你需要多個消費者各自獨立消費同一份數(shù)據(jù)。遇到這些需求再回頭考慮共享內(nèi)存、消息隊列或socket也不遲。但在那之前管道都是一個靠譜的起點。個人實際經(jīng)驗中說一句寫管道代碼的時候把read、write的返回值當一等公民對待把SIGPIPE的處理寫進所有常駐進程的初始化里多做這兩件事能省下無數(shù)個排查的夜晚。