簡(jiǎn)介《Linux系統(tǒng)編程實(shí)戰(zhàn)技巧》對(duì)應(yīng)的是杰克-本尼·佩爾松所著的《Linux系統(tǒng)編程技術(shù)》一書面向有一定 Linux 基礎(chǔ)、希望深入系統(tǒng)級(jí)編程的開發(fā)者。書中從環(huán)境搭建講起逐步覆蓋共享庫構(gòu)建與使用、終端輸入輸出控制、進(jìn)程間通信、多線程編程以及調(diào)試技巧等主題并以實(shí)際案例和練習(xí)引導(dǎo)讀者動(dòng)手編寫高效、健壯的 Linux 程序強(qiáng)調(diào)在實(shí)踐中鞏固概念幫助讀者理解原理后直接應(yīng)用到日常開發(fā)與問題排查。壓縮包內(nèi)為 1 個(gè) PDF 文件大小約 4.82MBPDF 格式便于跨設(shè)備閱讀、檢索和批注適合自主學(xué)習(xí)或工作查閱。目前已有 102 人學(xué)習(xí)說明其內(nèi)容在開發(fā)者群體中具備一定參考價(jià)值。通過系統(tǒng)閱讀讀者能補(bǔ)齊系統(tǒng)編程知識(shí)短板把握共享庫、進(jìn)程協(xié)作、終端控制與多線程等關(guān)鍵點(diǎn)掌握從基礎(chǔ)概念到實(shí)戰(zhàn)排錯(cuò)的核心技能為后續(xù)深入服務(wù)端開發(fā)與內(nèi)核機(jī)制打下扎實(shí)基礎(chǔ)。1. 項(xiàng)目概述與核心價(jià)值1.1 為什么現(xiàn)在還要學(xué)系統(tǒng)編程先拋個(gè)觀點(diǎn)在云原生、容器化、Serverless 鋪天蓋地的今天Linux 系統(tǒng)編程不僅沒過時(shí)反而成了區(qū)分“調(diào)包俠”和“真工程師”的分水嶺。很多人會(huì)用 Python、Go 寫業(yè)務(wù)但遇到性能瓶頸、詭異崩潰、內(nèi)存泄漏就抓瞎了——因?yàn)椴粫?huì)看底層。系統(tǒng)編程的本質(zhì)就是直接跟內(nèi)核打交道理解進(jìn)程、內(nèi)存、文件、信號(hào)、IPC 這些抽象概念背后的真實(shí)機(jī)制。我經(jīng)常打一個(gè)比方用高級(jí)語言寫業(yè)務(wù)相當(dāng)于開自動(dòng)擋汽車踩油門就走做系統(tǒng)編程相當(dāng)于你親自調(diào)發(fā)動(dòng)機(jī)、變速箱你得知道每個(gè)擋位什么時(shí)候換、離合器怎么配合。這個(gè)過程固然辛苦但一旦你掌握了再看上層框架、中間件會(huì)有一覽眾山小的感覺。這門技術(shù)最典型的應(yīng)用場(chǎng)景一是基礎(chǔ)設(shè)施類項(xiàng)目數(shù)據(jù)庫、消息隊(duì)列、存儲(chǔ)引擎、網(wǎng)絡(luò)代理二是性能敏感型服務(wù)網(wǎng)關(guān)、推薦引擎、實(shí)時(shí)流處理三是嵌入式與邊緣計(jì)算物聯(lián)網(wǎng)網(wǎng)關(guān)、智能設(shè)備。待遇普遍不低但門檻也擺在那里核心卡點(diǎn)就是系統(tǒng)編程能力。這篇實(shí)戰(zhàn)總結(jié)不是來給你念 man 手冊(cè)的而是把我在實(shí)際項(xiàng)目中高頻踩坑、反復(fù)驗(yàn)證過的關(guān)鍵知識(shí)點(diǎn)拎出來結(jié)合具體場(chǎng)景講清楚“為什么”。文章會(huì)覆蓋時(shí)間處理、內(nèi)存管理、文件 I/O、錯(cuò)誤處理、崩潰排查等幾個(gè)硬核方向每個(gè)都給到可落地的代碼片段和排查命令?？赐瓴桓艺f讓你脫胎換骨但至少能在遇到同類問題時(shí)少走幾個(gè)大彎。1.2 這篇文章適合誰有 C/C 基礎(chǔ)、正在轉(zhuǎn)向 Linux 服務(wù)端開發(fā)的工程師是這篇文章最核心的閱讀人群。如果你是剛學(xué)完《Unix 環(huán)境高級(jí)編程》前幾章、對(duì)文件描述符和進(jìn)程概念有了模糊認(rèn)識(shí)但還沒在真實(shí)項(xiàng)目里練過手的階段那正好。另外準(zhǔn)備面試后端崗位、被問到“進(jìn)程和線程的區(qū)別”“select 和 epoll 的差異”這類問題時(shí)只能背答案的朋友同樣適合讀一讀——我會(huì)從原理層面幫你把這些知識(shí)點(diǎn)打穿而不是停留在面經(jīng)口訣上。如果你已經(jīng)在寫業(yè)務(wù)代碼但對(duì) strace、gdb、perf 這類工具僅限于聽說那這篇文章的實(shí)操部分會(huì)給你清楚的入手路徑。底層原理配合工具鏈雙管齊下才能真正把知識(shí)變成排查問題的能力。對(duì)于純運(yùn)維或純前端背景的朋友這篇文章可能有一定深度但不必勸退——遇到不懂的系統(tǒng)調(diào)用直接 man 一下或者查內(nèi)核源碼注釋養(yǎng)成查一手資料的習(xí)慣比看二手博客強(qiáng)得多。2. 內(nèi)容整體設(shè)計(jì)與技術(shù)選型思路2.1 項(xiàng)目實(shí)戰(zhàn)中的技術(shù)棧與系統(tǒng)監(jiān)控回到一個(gè)實(shí)際的系統(tǒng)編程項(xiàng)目里來聊。比如我們要做一個(gè)高并發(fā)的日志采集代理需要從多個(gè)網(wǎng)絡(luò)連接讀取數(shù)據(jù)、解析、批量寫入磁盤。這個(gè)項(xiàng)目看起來簡(jiǎn)單但真正實(shí)現(xiàn)時(shí)技術(shù)選型處處是坑每一處都體現(xiàn)系統(tǒng)編程的核心功力。技術(shù)棧上幾個(gè)核心選擇是這樣的語言選 C 而不是 C日志代理的核心在于 I/O 吞吐和內(nèi)存控制C 的 runtime 更輕、可控性更強(qiáng)配合內(nèi)核 API 直來直去幾乎沒有隱藏開銷。C 標(biāo)準(zhǔn)庫確實(shí)方便但異常安全、模板展開帶來的二進(jìn)制膨脹在低配嵌入式環(huán)境下并不劃算。I/O 模型選 epoll 而不是多線程面對(duì)大量并發(fā)連接為每個(gè)連接起一個(gè)線程上下文切換開銷會(huì)吃掉不少 CPU。epoll 配合非阻塞 I/O 加事件驅(qū)動(dòng)是 Linux 下處理高并發(fā)的最優(yōu)模型沒有之一。存儲(chǔ)層不直接裸寫磁盤無論你多自信OS 的頁緩存page cache優(yōu)化比你手寫的任何緩沖機(jī)制都成熟。正確的姿勢(shì)是高頻寫入先進(jìn)入用戶態(tài)緩沖區(qū)積累一批或定時(shí)落盤利用 write 或 pwrite 的“拷貝到內(nèi)核頁緩存即返回”的特性把性能壓力交給內(nèi)核的 pdflush 機(jī)制去刷盤。監(jiān)控方式最直觀的就是 /proc 文件系統(tǒng)。不要小看這個(gè)虛擬文件系統(tǒng)它幾乎是內(nèi)核狀態(tài)的全景窗口。比如/proc/{pid}/status 可以看進(jìn)程內(nèi)存分布VmRSS、VmPeak/proc/{pid}/io 能統(tǒng)計(jì)真實(shí)讀寫字節(jié)數(shù)/proc/loadavg 反映系統(tǒng)整體負(fù)載。排查文件描述符泄漏直接看 /proc/{pid}/fd 目錄的符號(hào)鏈接數(shù)量。我調(diào)試很多問題第一步就是進(jìn)去掃一眼這個(gè)目錄比盲目上工具高效得多。2.2 為什么選這套方案避開了什么坑選這套方案核心邏輯是減少不可控的間接層。多線程模型看似直覺但坑在同步。鎖競(jìng)爭(zhēng)、條件變量誤喚醒、死鎖、ABA 問題隨便一個(gè)都能讓你調(diào)幾個(gè)通宵。而單線程 epoll 模型配合非阻塞 I/O天然規(guī)避了并發(fā)帶來的數(shù)據(jù)競(jìng)爭(zhēng)問題——一個(gè)線程按順序處理所有就緒事件根本不需要鎖。這種模型的確定性極強(qiáng)出了問題也容易復(fù)現(xiàn)。另外沒有盲目引入第三方庫。很多新手一上來就找 libevent、libuv但底層邏輯沒搞通之前這些庫就是個(gè)黑盒。你在 epoll 層犯了語義錯(cuò)誤比如沒有處理 EPOLLRDHUP、對(duì) EPOLLERR 響應(yīng)不正確換個(gè)庫同樣會(huì)有問題而且更難查。先把系統(tǒng)調(diào)用層面的手冊(cè)讀透再談抽象。這里補(bǔ)一個(gè)操作系統(tǒng)層面的背景epoll 之所以高效核心在于內(nèi)核維護(hù)了一個(gè)就緒鏈表應(yīng)用程序只需要等待自己關(guān)注的事件被觸發(fā)無需每次遍歷大量文件描述符。這個(gè)機(jī)制網(wǎng)上的文章一搜一大把我不再展開。實(shí)際操作中建議多看看內(nèi)核源碼中 fs/eventpoll.c 的注釋理解水平會(huì)高出一大截。3. 核心細(xì)節(jié)解析與實(shí)操要點(diǎn)3.1 時(shí)間處理你代碼里的 time 可能是錯(cuò)的先來個(gè)開胃菜——時(shí)間處理。這個(gè)問題看著基礎(chǔ)但坑極深。系統(tǒng)編程中經(jīng)常碰到的一個(gè)需求是“計(jì)算某段邏輯耗時(shí)”很多人寫代碼直接用clock()或者gettimeofday()然后發(fā)現(xiàn)結(jié)果忽大忽小神秘莫測(cè)。先說結(jié)論性能統(tǒng)計(jì)一律用 clock_gettime(CLOCK_MONOTONIC)不要用 gettimeofday 或 time。因?yàn)?CLOCK_MONOTONIC 不受系統(tǒng)時(shí)間跳變影響——NTP 校時(shí)、運(yùn)維手動(dòng)改時(shí)間都不會(huì)干擾它它只記錄系統(tǒng)上電以來流逝的時(shí)間。再深一層clock()返回的是進(jìn)程占用 CPU 的時(shí)間而非墻鐘時(shí)間。如果你的程序有大量 sleep 或 I/O 等待clock()統(tǒng)計(jì)出來的數(shù)值會(huì)嚴(yán)重偏小幾乎等于沒測(cè)。這個(gè)細(xì)節(jié)面試經(jīng)?？紝?shí)際開發(fā)中也極容易中招。#include stdio.h #include time.h static inline double now_ts(void) { struct timespec ts; clock_gettime(CLOCK_MONOTONIC, ts); return ts.tv_sec ts.tv_nsec / 1e9; } int main(void) { double start now_ts(); // 模擬業(yè)務(wù)處理 for (volatile int i 0; i 100000000; i); double end now_ts(); printf(elapsed: %.6f s\n, end - start); return 0; }注意結(jié)構(gòu)體timespec的tv_nsec單位是納秒不是微秒。很多人在這個(gè)單位換算上翻車把 1000 當(dāng) 1000000 用結(jié)果性能數(shù)據(jù)放大了 1000 倍。這種問題一旦跑在監(jiān)控告警上能把整個(gè)團(tuán)隊(duì)帶溝里。3.2 內(nèi)存分配malloc 的背后不是簡(jiǎn)單的堆再聊聊內(nèi)存管理。很多 C/C 程序員對(duì) malloc 的理解停留在“從堆上分配一塊內(nèi)存”這個(gè)層面但實(shí)際上當(dāng)你調(diào)用 malloc(1024) 時(shí)內(nèi)核可能根本沒有給你分配真實(shí)的物理內(nèi)存頁。Linux 下 glibc 的 malloc 對(duì)小塊內(nèi)存默認(rèn)閾值通常是 128KB 以內(nèi)走 brk通過調(diào)整堆頂指針滿足分配大塊內(nèi)存走 mmap由內(nèi)核在進(jìn)程地址空間找一個(gè)空閑區(qū)域映射。關(guān)鍵點(diǎn)是mmap 出來的內(nèi)存在首次訪問時(shí)才觸發(fā)缺頁異常由內(nèi)核真正分配物理頁。所以你的程序申請(qǐng)了 1GB 內(nèi)存但 RSS駐留內(nèi)存可能只有幾百 MB——這就是著名的內(nèi)存惰性分配。這個(gè)機(jī)制本身是優(yōu)化但也是坑源。在高并發(fā)服務(wù)中如果大量使用 mmap 分配內(nèi)存又頻繁釋放會(huì)產(chǎn)生大量頁表操作造成性能抖動(dòng)。對(duì)于需要高頻分配釋放對(duì)象的場(chǎng)景正確做法是維護(hù)自己的內(nèi)存池或者使用 tcmalloc / jemalloc 這類現(xiàn)代分配器。它們通過線程本地緩存降低鎖競(jìng)爭(zhēng)性能提升很明顯。# 查看進(jìn)程實(shí)際物理內(nèi)存占用RSS cat /proc/{pid}/status | grep -E VmRSS|VmPeak # 查看內(nèi)存映射分布 cat /proc/{pid}/maps | head -n 20以上命令在線上排查內(nèi)存問題時(shí)極常用。若發(fā)現(xiàn) VmPeak 遠(yuǎn)大于 VmRSS說明存在大量申請(qǐng)但未實(shí)際使用的內(nèi)存——可能是預(yù)留型分配也可能是內(nèi)存泄漏的早期信號(hào)需要結(jié)合 pmap 判斷具體映射區(qū)域。3.3 文件 I/O 的幾個(gè)隱身殺手文件 I/O 看起來簡(jiǎn)單open、read、write 三板斧但實(shí)際項(xiàng)目里有一堆隱形陷阱。第一個(gè)坑是未處理部分讀寫。read/write 被信號(hào)中斷EINTR或者實(shí)際讀寫字節(jié)數(shù)小于請(qǐng)求字節(jié)數(shù)的場(chǎng)景非常普遍。尤其是在管道、socket、慢速設(shè)備上write 幾乎不可能一次寫完所有數(shù)據(jù)。必須寫循環(huán)重試邏輯這是一個(gè)合格系統(tǒng)程序員的基本素養(yǎng)。ssize_t writen(int fd, const void *buf, size_t n) { const char *p buf; size_t left n; while (left 0) { ssize_t nw write(fd, p, left); if (nw 0) { if (errno EINTR) // 被信號(hào)打斷重試 continue; return -1; // 其他錯(cuò)誤交給調(diào)用方處理 } left - nw; p nw; } return n; }第二個(gè)坑是 forgot O_CLOEXEC。在 fork exec 的模型中如果你 open 一個(gè)文件描述符時(shí)沒有指定 O_CLOEXEC那么 exec 執(zhí)行新程序后這個(gè) fd 默認(rèn)會(huì)保持打開狀態(tài)。如果新程序的某個(gè)庫恰好在某路徑下創(chuàng)建文件或者加鎖就可能產(chǎn)生隱性的沖突?，F(xiàn)代的寫法是 open 時(shí)一律加 O_CLOEXEC除非你明確需要跨 exec 傳遞 fd。第三個(gè)坑是 fclose 的返回值沒人檢查。fclose 不只是釋放用戶態(tài)緩沖它還會(huì)嘗試把緩沖區(qū)內(nèi)剩余數(shù)據(jù) flush 到內(nèi)核并檢查是否落盤成功。很多人寫完文件直接 fclose 不查返回值結(jié)果磁盤滿、NFS 斷連導(dǎo)致數(shù)據(jù)丟失程序還不知情。寫關(guān)鍵數(shù)據(jù)時(shí)fclose 之后請(qǐng)務(wù)必檢查返回值。4. 實(shí)操過程與核心環(huán)節(jié)實(shí)現(xiàn)4.1 從零搭建一個(gè)非阻塞回顯服務(wù)為了把上面的理論串起來這里帶大家手寫一個(gè)極簡(jiǎn)的 epoll 回顯服務(wù)。它監(jiān)聽 TCP 端口收到什么就原樣返回什么。麻雀雖小但 epoll 的核心用法全在里面——從我多年的經(jīng)驗(yàn)來看這個(gè)練手項(xiàng)目搞定后再看 Nginx、Redis 的事件循環(huán)代碼會(huì)輕松特別多。先列出關(guān)鍵代碼再逐行解釋#include stdio.h #include stdlib.h #include string.h #include unistd.h #include errno.h #include sys/socket.h #include netinet/in.h #include sys/epoll.h #include fcntl.h #define MAX_EVENTS 64 #define BUF_SIZE 4096 static int set_nonblock(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main(void) { int lfd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr { .sin_family AF_INET, .sin_addr.s_addr htonl(INADDR_ANY), .sin_port htons(9000) }; bind(lfd, (struct sockaddr *)addr, sizeof(addr)); listen(lfd, 128); set_nonblock(lfd); int epfd epoll_create1(0); struct epoll_event ev {.events EPOLLIN, .data.fd lfd}; epoll_ctl(epfd, EPOLL_CTL_ADD, lfd, ev); struct epoll_event events[MAX_EVENTS]; char buf[BUF_SIZE]; for (;;) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (fd lfd) { // 有新連接到達(dá) int cfd accept4(lfd, NULL, NULL, SOCK_NONBLOCK); if (cfd 0) { ev.events EPOLLIN | EPOLLRDHUP; ev.data.fd cfd; epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, ev); } } else { if (events[i].events EPOLLRDHUP) { close(fd); continue; } ssize_t r read(fd, buf, sizeof(buf)); if (r 0) { write(fd, buf, r); // 回顯 } else if (r 0) { close(fd); } else { if (errno ! EAGAIN errno ! EWOULDBLOCK) { close(fd); } } } } } return 0; }幾個(gè)必須劃重點(diǎn)的細(xì)節(jié)第一accept4 帶 SOCK_NONBLOCK 一步到位。如果先 accept 再單獨(dú)調(diào) fcntl 設(shè)置非阻塞在高并發(fā)場(chǎng)景下存在一個(gè)時(shí)間窗口該 fd 仍處于阻塞模式。如果這個(gè)窗口內(nèi)該連接變得非?；钴S你的事件循環(huán)可能在 accept 返回后、設(shè)置非阻塞前阻塞在讀操作上整個(gè)服務(wù)就卡死了。這個(gè)問題在教科書里很少被強(qiáng)調(diào)但在生產(chǎn)環(huán)境很容易栽跟頭。第二EPOLLRDHUP 必須監(jiān)聽。很多人只關(guān)注 EPOLLIN忽略了連接關(guān)閉事件。其實(shí)對(duì)端關(guān)閉連接時(shí)Epoll 會(huì)同時(shí)觸發(fā) EPOLLIN但當(dāng)你 read 返回 0 時(shí)才處理意味著至少多一次系統(tǒng)調(diào)用。如果對(duì)端是半關(guān)閉shutdown 寫端你的 read 可能永遠(yuǎn)不返回 0連接泄漏就發(fā)生了。加上 EPOLLRDHUP內(nèi)核會(huì)在對(duì)端關(guān)閉連接的第一時(shí)間通知你處理更優(yōu)雅。第三read 返回 -1 時(shí)要區(qū)分 EAGAIN 和真正的錯(cuò)誤。EAGAIN/EWOULDBLOCK 表示當(dāng)前沒有數(shù)據(jù)可讀這是非阻塞模式下的正常情況忽略即可。其他錯(cuò)誤ECONNRESET、EPIPE 等才需要關(guān)閉連接。這個(gè)判斷順序?qū)懛戳藭?huì)出現(xiàn)大量無效的 close 調(diào)用白白丟失連接。編譯這段代碼gcc -O2 -o echo echo.c ./echo # 另開終端測(cè)試 echo hello | nc 127.0.0.1 9000 # 輸出 hello4.2 利用 strace 動(dòng)態(tài)追蹤系統(tǒng)調(diào)用詳情寫完回顯服務(wù)如果本地測(cè)試正常但懷疑某些場(chǎng)景有異常怎么辦strace 就是最犀利的工具它通過 ptrace 機(jī)制攔截進(jìn)程的所有系統(tǒng)調(diào)用讓你看到用戶態(tài)和內(nèi)核態(tài)之間的每一次交互。# 跟蹤新啟動(dòng)的進(jìn)程 strace -f -e tracenetwork,read,write -o /tmp/echo.log ./echo # 或者跟蹤正在運(yùn)行的進(jìn)程 strace -p 12345 -f -e traceall -o /tmp/echo_attach.log跟蹤日志里的關(guān)鍵信息如何解讀以 accept 為例如果日志里出現(xiàn)大量EAGAIN說明事件循環(huán)里確實(shí)在讀非就緒的 fd——這本身是設(shè)計(jì)使然但如果密集出現(xiàn)說明事件注冊(cè)邏輯可能有問題fd 沒有正確地從 epoll 移除。再比如看到write(...) -1 EPIPE說明對(duì)端已關(guān)閉但你仍在寫通常需要處理 SIGPIPE 信號(hào)或使用 MSG_NOSIGNAL 標(biāo)志。有一個(gè)使用技巧先 strace 看系統(tǒng)調(diào)用序列再結(jié)合代碼邏輯定位比單純看日志高效得多。很多詭異的問題日志里全是歲月靜好strace 一跑就原形畢露。特別是超時(shí)類問題在 strace 輸出里你能清楚看到 poll/ppoll/epoll_wait 的等待時(shí)長(zhǎng)簡(jiǎn)潔明了。提示strace 有性能開銷不能長(zhǎng)時(shí)間在生產(chǎn)環(huán)境開啟。它適合臨時(shí)追蹤某個(gè)可疑進(jìn)程定位問題后立刻關(guān)閉。4.3 gdb 調(diào)試崩潰與段錯(cuò)誤系統(tǒng)編程最常見的崩潰就是段錯(cuò)誤Segmentation Fault。定位段錯(cuò)誤很多人第一反應(yīng)是看 core dump 文件這沒問題但如果 core 開關(guān)沒開或者 core 文件巨大無比就得靠 gdb 現(xiàn)場(chǎng)調(diào)試了。# 編譯時(shí)開啟 -g 保留調(diào)試符號(hào)-O0 關(guān)閉優(yōu)化便于單步調(diào)試 gcc -g -O0 -o echo echo.c # 用 gdb 啟動(dòng) gdb ./echo # 在 gdb 中運(yùn)行 (gdb) run # 崩潰后查看棧回溯 (gdb) bt # 查看當(dāng)前幀源碼 (gdb) list # 查看某個(gè)變量/內(nèi)存 (gdb) info locals (gdb) x/16xb buf這里必須強(qiáng)調(diào)一個(gè)我在實(shí)踐中反復(fù)驗(yàn)證的經(jīng)驗(yàn)崩潰兩次的現(xiàn)象往往才是 root cause。第一次崩潰可能發(fā)生在任意位置但第二次崩潰基本能穩(wěn)定暴露真正的問題因?yàn)榇藭r(shí)數(shù)據(jù)結(jié)構(gòu)已經(jīng)被污染成穩(wěn)定狀態(tài)。所以線上遇到偶現(xiàn)段錯(cuò)誤不要急著重啟盡量保留現(xiàn)場(chǎng)用 gdb attach 上去看看。此外當(dāng)沒有 gdb 環(huán)境時(shí)也需要看懂核心轉(zhuǎn)儲(chǔ)文件里到底發(fā)生了什么。一個(gè)常見組合# 查看 core 文件的堆棧概要 gdb ./echo /var/lib/systemd/coredump/core.echo.12345 (gdb) thread apply all bt這個(gè)命令會(huì)列出所有線程的棧能快速判斷問題發(fā)生在哪個(gè)線程是主事件循環(huán)還是某個(gè) worker。多線程程序崩潰時(shí)所有線程棧都打出來非常關(guān)鍵——問題線程的?？赡懿皇亲铒@眼的那個(gè)但通過觀察鎖等待關(guān)系和資源訪問模式就能定位。4.4 日志與監(jiān)控沒有觀測(cè)就沒有降級(jí)最后是日志。系統(tǒng)編程的程序往往運(yùn)行在無人值守的服務(wù)器上日志就是你的眼睛。但日志怎么寫是有講究的。首先盡量使用異步日志避免磁盤 I/O 阻塞業(yè)務(wù)線程。其次日志必須有級(jí)別DEBUG/INFO/WARN/ERROR且可動(dòng)態(tài)調(diào)整——生產(chǎn)環(huán)境默認(rèn) INFO排查問題時(shí)臨時(shí)降級(jí)到 DEBUG不需要重啟進(jìn)程。如果追求更精細(xì)的操作可以自己實(shí)現(xiàn)一個(gè)信號(hào)鉤子收到 SIGUSR1 時(shí)提升日志級(jí)別收到 SIGUSR2 時(shí)恢復(fù)。這種設(shè)計(jì)在線上運(yùn)維中非常實(shí)用。這里補(bǔ)充一個(gè)可以“抄作業(yè)”的小方案日志落盤路徑/var/log/yourapp/app.log軟鏈到當(dāng)前版本目錄日志輪轉(zhuǎn)用 logrotate每天切割 保留 7 天超過大小強(qiáng)制輪轉(zhuǎn)核心指標(biāo)通過 /proc/{pid}/fd 統(tǒng)計(jì)連接數(shù)、通過 /proc/{pid}/status 統(tǒng)計(jì)內(nèi)存、通過 epoll_wait 返回值統(tǒng)計(jì)事件吞吐量全部定時(shí)打印到日志一旦做到以上幾點(diǎn)出現(xiàn)問題大概率能通過日志鏈路直接定位不需要頻繁登錄機(jī)器。5. 常見問題與排查技巧實(shí)錄5.1 連接數(shù)暴漲時(shí)出現(xiàn)“Too many open files”現(xiàn)象服務(wù)運(yùn)行一段時(shí)間后日志里飄著Too many open files新連接無法 accept。排查思路先看當(dāng)前進(jìn)程打開了多少 fdls /proc/{pid}/fd | wc -l再確認(rèn)系統(tǒng)限制ulimit -n兩者對(duì)比若接近或達(dá)到上限就是 fd 泄漏最可能的原因和解決代碼里accept返回的 fd 在某條分支上忘記 close比如 read 返回異常時(shí)沒關(guān)相對(duì)隱蔽的是epoll_ctl刪除 fd 失敗卻沒有 close 這個(gè) fd還有一個(gè)容易忽略的點(diǎn)select/poll時(shí)代程序換到 epoll 后對(duì) close 行為沒做調(diào)整——epoll 里 fd 被 close 時(shí)自動(dòng)從監(jiān)聽列表移除但如果你繼續(xù)沿用舊的“兩段式刪除”寫法就可能在刪除時(shí)拿到已關(guān)閉 fd 編號(hào)的復(fù)用誤刪其他連接推薦預(yù)防手段在代碼里周期性統(tǒng)計(jì) fd 總數(shù)并輸出日志設(shè)置明確告警閾值而不是等到了系統(tǒng)上限才被動(dòng)發(fā)現(xiàn)。另外建議給每個(gè)可能持有 fd 的結(jié)構(gòu)體增加magic字段close 后置 0后續(xù)任何訪問都先校驗(yàn)快速定位重復(fù)釋放問題。5.2 讀數(shù)據(jù)時(shí)遇到 EINTR 和 EAGAIN 的處理迷惑場(chǎng)景非阻塞 socket 編程時(shí)read 返回 -1errno 分別等于 EINTR 和 EAGAIN很多新手表示一臉懵。區(qū)分說明EINTR系統(tǒng)調(diào)用被信號(hào)中斷只是暫時(shí)的重新調(diào)用一次就行。常見觸發(fā)場(chǎng)景是終端 CtrlC、定時(shí)信號(hào)或者調(diào)試器介入。EAGAIN/EWOULDBLOCK資源暫時(shí)不可用比如 socket 接收緩沖區(qū)為空不是錯(cuò)誤。非阻塞模式下這是常態(tài)直接忽略或者回到 epoll_wait 等待下一輪事件。經(jīng)驗(yàn)法則這兩種錯(cuò)誤碼都要“繼續(xù)等”但 EINTR 是立即重試EAGAIN 是回到事件循環(huán)。如果循環(huán)里對(duì) EINTR 重寫時(shí)還帶著 sleep等于是人為給自己的服務(wù)加了延遲如果 EAGAIN 被當(dāng)成異常直接 close就會(huì)出現(xiàn)連接無故斷開的問題。用本章代碼里的 writen 函數(shù)配合 EPOLLOUT 事件基本能覆蓋多數(shù)場(chǎng)景。// 正確姿勢(shì)收到 EAGAIN 就停止寫入等待 EPOLLOUT 事件 if (errno EAGAIN || errno EWOULDBLOCK) { // 將 fd 注冊(cè)到 epoll監(jiān)聽 EPOLLOUT ev.events EPOLLIN | EPOLLOUT; epoll_ctl(epfd, EPOLL_CTL_MOD, fd, ev); break; }5.3 多線程 vs 多進(jìn)程的選型糾結(jié)這個(gè)問題幾乎每個(gè)系統(tǒng)編程初學(xué)者都會(huì)困惑。簡(jiǎn)單說幾條經(jīng)得住實(shí)戰(zhàn)檢驗(yàn)的建議多線程適合共享大量狀態(tài)線程間通信成本低任務(wù)粒度小線程池能夠高效復(fù)用單機(jī)多核并行計(jì)算一進(jìn)程內(nèi)搞定多進(jìn)程適合需要高可靠性隔離一個(gè)子進(jìn)程崩潰不影響主進(jìn)程模塊間權(quán)限不同希望用不同 UID 運(yùn)行某個(gè)第三方庫不安全不想讓它污染主進(jìn)程地址空間我的實(shí)操心得能用單線程 epoll 解決的問題絕不上多線程。曾經(jīng)有項(xiàng)目用 4 個(gè)線程處理 2 萬個(gè)連接光鎖競(jìng)爭(zhēng)就損失了 30% 的吞吐量。后來改成多進(jìn)程模型每個(gè)進(jìn)程各管各的 fd 集合再配合 SO_REUSEPORT 做內(nèi)核級(jí)負(fù)載均衡性能直接翻倍。這個(gè)思路在 Nginx、Envoy 等生產(chǎn)級(jí)項(xiàng)目里已經(jīng)被反復(fù)驗(yàn)證是真實(shí)有效的擴(kuò)展路徑。5.4 服務(wù)器對(duì)時(shí)與時(shí)間戳亂象一個(gè)容易讓人崩潰的 bug服務(wù)日志時(shí)間偶發(fā)跳變、晚于實(shí)際時(shí)間、或者出現(xiàn)負(fù)耗時(shí)。根因代碼混用了 CLOCK_REALTIME墻上時(shí)鐘和 CLOCK_MONOTONIC單調(diào)時(shí)鐘。CLOCK_REALTIME 會(huì)隨 NTP 校時(shí)、手動(dòng)調(diào)整發(fā)生跳變導(dǎo)致耗時(shí)計(jì)算瞬間變負(fù)。修改方案命脈指標(biāo)統(tǒng)一使用 CLOCK_MONOTONIC日志展示附帶北京時(shí)間就單獨(dú)調(diào)用 localtime_r 轉(zhuǎn)換 CLOCK_REALTIME 的輸出。二者不要混在一個(gè)計(jì)算鏈路里。補(bǔ)充一個(gè)技巧如果某個(gè)功能只是想計(jì)算一次超時(shí)可以使用 timerfd_create epoll把超時(shí)管理交給內(nèi)核不需要自己開定時(shí)線程。這種設(shè)計(jì)更利于事件循環(huán)的一致性——同一套事件循環(huán)里既管理 fd又管理定時(shí)器代碼結(jié)構(gòu)更整潔。5.5 崩潰時(shí)沒有 core 文件怎么辦問題程序段錯(cuò)誤了但 /var/lib/systemd/coredump/ 里啥也沒有。排查順序ulimit -c是否為 0如果是改成ulimit -c unlimited/proc/sys/kernel/core_pattern是否被 systemd 接管如果是確認(rèn) systemd-coredump 服務(wù)存在且運(yùn)行代碼是否調(diào)用過signal(SIGSEGV, SIG_IGN)或者其他方式屏蔽了默認(rèn)行為如果現(xiàn)場(chǎng)不好復(fù)現(xiàn)也可以直接讓程序在崩潰時(shí)自己打印棧回溯。使用 backtrace 函數(shù)族和 backtrace_symbols_fd 寫到 stderr 或者日志文件能夠快速離線定位。#include execinfo.h #include unistd.h #include signal.h void crash_handler(int sig) { void *frames[32]; int n backtrace(frames, 32); backtrace_symbols_fd(frames, n, STDERR_FILENO); _exit(1); } // main 函數(shù)里注冊(cè) signal(SIGSEGV, crash_handler); signal(SIGABRT, crash_handler);注意backtrace 在異步信號(hào)處理函數(shù)中不保證完全安全但多數(shù)場(chǎng)景下足夠用來做初步定位。生產(chǎn)環(huán)境最好還是借助 core dump 文件做完整分析。6. 寫在最后的實(shí)踐總結(jié)系統(tǒng)編程這門手藝書看百遍不如手過一遍。這篇文章里提到的每個(gè)問題幾乎都是我在真實(shí)項(xiàng)目里踩過的坑——有些坑是用一個(gè)通宵換來的教訓(xùn)有的則是用線上事故的代價(jià)買回來的經(jīng)驗(yàn)。所以我想用自己的實(shí)踐體會(huì)收個(gè)尾。首先一定要養(yǎng)成“先 strace再 gdb最后翻源碼”的排查習(xí)慣。很多時(shí)候崩潰現(xiàn)場(chǎng)類問題strace 記錄的系統(tǒng)調(diào)用序列比任何日志都有說服力先確認(rèn)進(jìn)程究竟做了什么再打開源碼分析為什么這么做效率會(huì)高很多。其次內(nèi)核文檔和 man 手冊(cè)永遠(yuǎn)是第一手資料。網(wǎng)上博客魚龍混雜不少內(nèi)容都是互相抄抄到最后連參數(shù)名都被改錯(cuò)了。碰到不清楚的系統(tǒng)調(diào)用優(yōu)先查一下對(duì)應(yīng) man page 的 “NOTES” 和“BUGS” 段落里面的警告信息非常值錢。更進(jìn)一步直接看內(nèi)核源碼的注釋和提交記錄往往能發(fā)現(xiàn)很多設(shè)計(jì)者的真實(shí)意圖。最后系統(tǒng)編程是一場(chǎng)長(zhǎng)期主義。它對(duì)人的心智模型要求很高需要你同時(shí)理解 CPU 調(diào)度、內(nèi)存管理、I/O 協(xié)議棧等一堆底層知識(shí)。但正是這種“難”才構(gòu)成了行業(yè)壁壘。今天文章里的 epoll 模型、內(nèi)存惰性分配、EINTR 處理、core dump 排查都只是冰山一角。接下來你可以擴(kuò)展的方向是把單線程 epoll 升級(jí)為多進(jìn)程 SO_REUSEPORT 的架構(gòu)自己實(shí)現(xiàn)一個(gè)簡(jiǎn)單的線程池比較不同調(diào)度策略的優(yōu)劣深入研究一下 io_uring看看下一代異步 I/O 是怎么把系統(tǒng)調(diào)用開銷降到極致的。如果你正好在學(xué)這些內(nèi)容遇到具體問題卡住了歡迎帶著棧信息和 strace 日志來交流——好的問題往往比答案更值得討論。本文還有配套的精品資源點(diǎn)擊獲取