如果你寫過一個(gè)基于select或poll的 TCP 服務(wù)器大概率遇到過這樣的尷尬連接數(shù)一旦漲到幾千輪詢掃描 FD 的開銷直接吃掉大部分 CPU而換成“每個(gè)連接開一個(gè)線程”的思路線程上下文切換又讓你不敢繼續(xù)往上加連接數(shù)。我第一次被epoll驚艷是在一臺配置很普通的機(jī)器上單線程事件循環(huán)扛住了上萬條長連接當(dāng)時(shí)我就意識到高并發(fā)網(wǎng)絡(luò)服務(wù)這條路繞不開“事件驅(qū)動”這四個(gè)字而把事件驅(qū)動做規(guī)范、做優(yōu)雅的經(jīng)典框架就是Epoll-Reactor模式。這篇文章我會從 Reactor 模式的思想出發(fā)講到epoll為什么適合當(dāng)事件分發(fā)器再到如何用 C 語言徒手寫一個(gè)最小可運(yùn)行的Epoll-Reactor服務(wù)端最后聊多線程演進(jìn)和我在實(shí)際調(diào)優(yōu)中踩過的坑。適合正在學(xué) Linux 網(wǎng)絡(luò)編程的初學(xué)者也給想重構(gòu)舊 IO 模型的老開發(fā)一點(diǎn)對比參考。整個(gè)鏈路我會盡量說人話但你也能感受到這套模式背后真正的設(shè)計(jì)功力。1. Reactor模式先搞清楚它解決了什么問題1.1 傳統(tǒng)阻塞IO模型為什么撐不住高并發(fā)很多人剛學(xué)網(wǎng)絡(luò)編程時(shí)寫的第一個(gè)服務(wù)端大概是這樣的socket、bind、listen然后在一個(gè)while循環(huán)里accept拿到客戶端連接后read數(shù)據(jù)、處理、write返回。這個(gè)模型有個(gè)肉眼可見的問題read會阻塞如果當(dāng)前客戶端不發(fā)送數(shù)據(jù)服務(wù)端就卡在那個(gè)連接的read調(diào)用上其他客戶端完全無法連接。于是新手進(jìn)階版的解決方案出來了主線程只做accept每來一個(gè)連接就創(chuàng)建一個(gè)子線程去服務(wù)它。這套“一個(gè)連接一個(gè)線程”的模型在小規(guī)模場景下非常好用代碼也好寫。但連接數(shù)一旦上千線程數(shù)跟著上千問題就來了每個(gè)線程默認(rèn)棧空間不小8MB 虛擬內(nèi)存上千線程內(nèi)存壓力很嚇人線程切換成本高CPU 大量時(shí)間浪費(fèi)在保存和恢復(fù)寄存器、內(nèi)核棧上真正讀到的數(shù)據(jù)可能只有幾十字節(jié)大部分線程在阻塞等待資源利用率極低。所以我們需要一種機(jī)制讓操作系統(tǒng)告訴我們“哪個(gè) socket 現(xiàn)在可讀了、哪個(gè) socket 現(xiàn)在可寫了”我們只需要在事件發(fā)生的時(shí)候去處理。這就是 IO 多路復(fù)用。1.2 事件驅(qū)動與Reactor的核心角色select和poll雖然能實(shí)現(xiàn)多路復(fù)用但它們本質(zhì)上還是在每次調(diào)用時(shí)把所有 fd 集合從用戶態(tài)拷貝到內(nèi)核態(tài)內(nèi)核再挨個(gè)遍歷 fd 判斷狀態(tài)返回后應(yīng)用還得再遍歷一次才能知道哪些 fd 有事件。這個(gè) O(n) 的復(fù)雜度在連接數(shù)萬級時(shí)同樣會拖垮性能。Reactor 模式在這樣的背景下被廣泛采用。它不是一個(gè)庫也不是某個(gè)框架的專利而是一種設(shè)計(jì)思想把“等待事件”和“處理事件”拆開。組件上主要分成三個(gè)部分事件源這里就是 socket fd、監(jiān)聽 fd 等事件分發(fā)器Dispatcher/Reactor負(fù)責(zé)注冊、監(jiān)聽這些事件源并在事件發(fā)生時(shí)把回調(diào)調(diào)度給對應(yīng)的處理器事件處理器Handler真正執(zhí)行業(yè)務(wù)邏輯的地方比如解析 HTTP 請求、回復(fù)數(shù)據(jù)。打個(gè)比方阻塞 IO 就像一個(gè)小餐館每個(gè)顧客點(diǎn)菜都要一個(gè)服務(wù)員全程陪著服務(wù)員一多后廚反而亂Reactor 模式則是前廳只保留一個(gè)領(lǐng)班領(lǐng)班盯著所有桌子的“按鈴”哪個(gè)桌子按鈴了就叫對應(yīng)的服務(wù)員去服務(wù)服務(wù)員忙完就回到待命狀態(tài)。epoll就是這個(gè)最敏感的“按鈴系統(tǒng)”它能精準(zhǔn)告訴你哪一桌按了鈴。搞清楚了這個(gè)背景你就明白為什么會有Epoll-Reactor這個(gè)組合Reactor 負(fù)責(zé)頂層架構(gòu)epoll負(fù)責(zé)高效事件通知兩者天然契合。2. Epoll三個(gè)API如何撐起事件通知機(jī)制2.1 為什么是epoll而不是select/pollselect的問題不光是 O(n) 遍歷它對 fd 數(shù)量還有硬性限制默認(rèn)上限是 1024雖然能改內(nèi)核參數(shù)和宏重新編譯但 fd_set 的位掩碼設(shè)計(jì)本身就不適合大規(guī)模 fd。poll擺脫了 1024 上限卻仍然要把全部 fd 傳給內(nèi)核每次調(diào)用都有全量拷貝的成本。epoll之所以是“事件驅(qū)動”的是因?yàn)樗寖?nèi)核維護(hù)了一棵紅黑樹來保存你關(guān)心的 fd同時(shí)維護(hù)一個(gè)就緒鏈表來記錄真正發(fā)生事件的 fd。每次epoll_wait返回時(shí)應(yīng)用拿到的就是已經(jīng)準(zhǔn)備好的事件不需要自己再遍歷所有 fd。也就是說復(fù)雜度從 O(n) 變成了 O(就緒事件數(shù))連接數(shù)越大收益越明顯。我第一次跑壓測時(shí)看到這個(gè)數(shù)據(jù)非常震撼同樣的連接數(shù)select在 2000 連接時(shí) CPU 已經(jīng)接近 30%而epoll在一萬連接時(shí)單核 CPU 仍然保持個(gè)位數(shù)。這不是微優(yōu)化是數(shù)量級的差別。2.2 三個(gè)核心API的細(xì)節(jié)理解epoll使用起來很簡單一共三個(gè)函數(shù)int epoll_create1(int flags); int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);epoll_create1傳EPOLL_CLOEXEC是一個(gè)好習(xí)慣防止exec后 fd 意外泄漏到子進(jìn)程。epoll_ctl的op基本就是EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL三件套。struct epoll_event是這個(gè)系統(tǒng)最關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)struct epoll_event { uint32_t events; /* 感興趣的事件 */ epoll_data_t data; /* 用戶自定義數(shù)據(jù) */ }; typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t;這里的data是聯(lián)合體日常使用我會優(yōu)先選擇ptr而不是fd。因?yàn)轫?xiàng)目里的連接一旦多起來你需要保存客戶端地址、接收緩沖區(qū)、超時(shí)時(shí)間等一堆狀態(tài)只用fd的話每次還得從 map 或數(shù)組里查直接用ptr把一個(gè)結(jié)構(gòu)體指針掛上去事件回來時(shí)一步到位拿到這個(gè)連接的上下文效率高且語義清晰。事件類型方面最常用的幾個(gè)EPOLLIN對應(yīng)的 fd 有數(shù)據(jù)可讀或?qū)Χ岁P(guān)閉了連接半關(guān)閉EPOLLOUT對應(yīng)的 fd 可以寫入不會阻塞EPOLLET邊沿觸發(fā)模式這是與默認(rèn)水平觸發(fā)最大的分水嶺EPOLLONESHOT事件只觸發(fā)一次處理完需要重新注冊這是多線程模型下防止事件重復(fù)分發(fā)的關(guān)鍵手段EPOLLRDHUP對端關(guān)閉連接從 2.6.17 內(nèi)核開始支持可以更早知道關(guān)閉事件。事件標(biāo)志里EPOLLERR和EPOLLHUP通常是自動上報(bào)的你不一定需要主動注冊但代碼里要處理這種事件否則連接出錯(cuò)了你可能完全無感知。3. 把Epoll改裝成Reactor架構(gòu)與組件劃分3.1 單線程Reactor的動態(tài)流程Epoll-Reactor最簡單的形態(tài)是單線程事件循環(huán)運(yùn)行邏輯大致這樣創(chuàng)建epoll描述符把監(jiān)聽 socket 注冊到epoll掛上accept回調(diào)循環(huán)調(diào)用epoll_wait等待事件拿到事件后通過data.ptr找到對應(yīng)的 handler 結(jié)構(gòu)體調(diào)用該 handler 注冊的事件處理函數(shù)處理完回到第 3 步繼續(xù)等待下一個(gè)事件。整個(gè)流程里只有一個(gè)線程在跑。這意味著回調(diào)函數(shù)里絕對不能做耗時(shí)的同步操作比如數(shù)據(jù)庫查詢、外部 HTTP 調(diào)用、復(fù)雜計(jì)算。你要是做了其實(shí)阻塞的不是整個(gè)線程嗎對所有連接的事件處理都被你拖住了。所以在單線程場景下業(yè)務(wù)必須足夠短平快或者把耗時(shí)任務(wù)異步化、投遞到線程池去執(zhí)行。3.2 模塊劃分與事件處理器設(shè)計(jì)要把epoll用得像 Reactor最好先定義幾個(gè)基礎(chǔ)結(jié)構(gòu)/* 事件處理器抽象 */ struct event_handler { int fd; uint32_t events; int (*callback)(struct event_handler *self); void *args; /* 業(yè)務(wù)上下文 */ struct reactor *reactor; /* 所屬 reactor */ struct event_handler *next; /* 鏈表指針便于統(tǒng)一管理 */ }; /* reactor 核心 */ struct reactor { int epfd; int stop; struct event_handler *handlers; struct epoll_event *events; int maxevents; };這段設(shè)計(jì)里最重要的思想是所有 fd 都包裝成 event_handler連接關(guān)閉后整個(gè)結(jié)構(gòu)體統(tǒng)一釋放。fd 不外露也就減少了很多裸close帶來的問題。處理器不關(guān)心它處理的是監(jiān)聽 fd 還是普通連接只要事件發(fā)生就執(zhí)行自己注冊的callback。監(jiān)聽 fd 的回調(diào)是on_accept普通連接的回調(diào)是on_read/on_write/on_close。這種“統(tǒng)一接口 各自實(shí)現(xiàn)”的寫法就是 Reactor 模式里“可擴(kuò)展組件”的精髓。3.3 回調(diào)函數(shù)設(shè)計(jì)經(jīng)驗(yàn)回調(diào)函數(shù)簽名我建議統(tǒng)一返回int用返回值表示“這個(gè) handler 是否要繼續(xù)保留”。比如返回 0 表示正常返回 -1 表示需要關(guān)閉連接、釋放資源。這樣在主循環(huán)里可以統(tǒng)一做善后處理而不是每個(gè)回調(diào)內(nèi)部各寫一套 close 邏輯。還有一點(diǎn)是觸發(fā)模式的選擇。LT水平觸發(fā)模式下只要緩沖區(qū)還有數(shù)據(jù)epoll_wait會不斷上報(bào)EPOLLIN代碼不容易漏數(shù)據(jù)但如果你對某個(gè)呆滯連接反復(fù)讀、反復(fù)上報(bào)CPU 會空轉(zhuǎn)。ET邊沿觸發(fā)模式下每次狀態(tài)變化只上報(bào)一次你必須一次讀完或?qū)懙紼AGAIN對代碼邏輯要求更高一旦沒循環(huán)讀完數(shù)據(jù)就留在緩沖區(qū)不會再有事件通知。我自己做高并發(fā)服務(wù)時(shí)讀事件偏向 ET 非阻塞 while 循環(huán)讀因?yàn)樗茱@著減少無謂的系統(tǒng)調(diào)用但如果團(tuán)隊(duì)里新手多、代碼維護(hù)壓力大LT 反而更穩(wěn)妥。沒有絕對好壞只有合不合適。4. 手寫一個(gè)最小Epoll-Reactor服務(wù)端4.1 基礎(chǔ)結(jié)構(gòu)初始化先看主循環(huán)和初始化部分#include stdio.h #include stdlib.h #include string.h #include unistd.h #include errno.h #include fcntl.h #include sys/socket.h #include netinet/in.h #include sys/epoll.h #define MAX_EVENTS 1024 static int set_nonblock(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags 0) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } static int epfd; struct conn { int fd; int close_flag; char read_buf[4096]; int read_len; char write_buf[4096]; int write_len; int write_offset; };這里我把conn結(jié)構(gòu)體當(dāng)成這個(gè)連接的“所有狀態(tài)”。為什么不用兩個(gè)結(jié)構(gòu)體區(qū)分連接和 handler早期我試過發(fā)現(xiàn)一個(gè)連接既要有 epoll 事件信息又要有業(yè)務(wù)緩沖區(qū)分拆之后每次都要互轉(zhuǎn)指針非常容易越界或重復(fù)釋放。合并的好處是一份內(nèi)存管到底關(guān)連接時(shí)一個(gè)free就完事。4.2 事件循環(huán)主體核心循環(huán)void reactor_run() { struct epoll_event events[MAX_EVENTS]; while (1) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); if (n 0) { if (errno EINTR) continue; /* 被信號中斷重來 */ perror(epoll_wait); break; } for (int i 0; i n; i) { struct conn *c events[i].data.ptr; uint32_t evs events[i].events; if (evs (EPOLLERR | EPOLLHUP)) { /* 錯(cuò)誤事件優(yōu)先處理 */ conn_close(c); continue; } if (evs EPOLLIN) { conn_on_read(c); } if (evs EPOLLOUT) { conn_on_write(c); } } } }這里有幾個(gè)容易忽略的地方。第一epoll_wait的timeout參數(shù)我用了-1表示永久阻塞。如果你的程序有周期性任務(wù)比如心跳掃描、超時(shí)關(guān)閉空閑連接就不能這樣寫建議改成50或100毫秒的超時(shí)讓 loop 能反復(fù)醒來做定時(shí)檢查。但要注意超時(shí)太短會讓進(jìn)程在沒事件時(shí)頻繁空轉(zhuǎn)CPU 飆高。第二events[i].data.ptr必須是剛才 4.1 里我們注冊進(jìn)去的conn指針。如果注冊時(shí)掛的是fd這里還得自己查。我建議一律掛指針但你要保證這個(gè)指針的生命周期在epoll_wait期間是有效的。很多詭異崩潰都來自這里一個(gè)連接已經(jīng) close 并 free但內(nèi)核 epoll 里還殘留著它的指針事件來了一訪問就是野指針。為了避免這種情況關(guān)閉連接時(shí)一定要先epoll_ctl(..., EPOLL_CTL_DEL, fd, NULL)再close(fd)再free(conn)順序不能亂。先 close 再 DEL 也不是不行但一旦 fd 被系統(tǒng)回收后復(fù)用而 epoll 里還掛著舊信息新連接就把舊事件頂?shù)袅诉@就會產(chǎn)生各種難以復(fù)現(xiàn)的 bug。4.3 監(jiān)聽fd的accept回調(diào)監(jiān)聽 socket 的注冊方式比較特殊它的事件處理器掛在監(jiān)聽 fd 上而不是普通連接上static void accept_cb() { struct sockaddr_in addr; socklen_t len sizeof(addr); while (1) { int cfd accept(listen_fd, (struct sockaddr *)addr, len); if (cfd 0) { if (errno EAGAIN || errno EINTR) break; perror(accept); break; } set_nonblock(cfd); struct conn *c calloc(1, sizeof(*c)); c-fd cfd; c-events EPOLLIN | EPOLLET; struct epoll_event ev; ev.events c-events; ev.data.ptr c; if (epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, ev) 0) { perror(epoll_ctl add); close(cfd); free(c); continue; } } }accept這里用了while (1)這是 ET 模式的關(guān)鍵。因?yàn)閍ccept只能通知你一次“有連接到達(dá)”如果只 accept 一個(gè)就回主循環(huán)同一批剩下的待連接連接就不會再觸發(fā)EPOLLIN了。千萬要在一次事件里把所有積壓的連接都 accept 完直到返回EAGAIN。還有一個(gè)細(xì)節(jié)accept拿到的cfd必須立刻設(shè)非阻塞。不管是 LT 還是 ETRead 操作如果不設(shè)非阻塞一遇到緩沖區(qū)沒數(shù)據(jù)就卡死整個(gè)線程。這個(gè)失誤我見過太多次癥狀就是“服務(wù)器一壓測就?！睂?shí)際上線程卡在某次 read 上了。4.4 讀寫回調(diào)與善后邏輯讀回調(diào)static void conn_on_read(struct conn *c) { char tmp[4096]; while (1) { ssize_t n read(c-fd, tmp, sizeof(tmp)); if (n 0) { /* 追加到 conn 的讀緩沖越界要防 */ if (c-read_len n (int)sizeof(c-read_buf)) { /* 緩沖區(qū)滿按業(yè)務(wù)規(guī)則處理關(guān)連接或報(bào)錯(cuò) */ conn_close(c); return; } memcpy(c-read_buf c-read_len, tmp, n); c-read_len n; } else if (n 0) { /* 對端關(guān)閉 */ conn_close(c); return; } else { if (errno EAGAIN) return; /* 數(shù)據(jù)讀完正常返回 */ if (errno EINTR) continue; conn_close(c); return; } } }n 0說明對端正常關(guān)閉了這時(shí)做關(guān)閉動作。n 0 errno EAGAIN表示當(dāng)前沒有更多數(shù)據(jù)對 ET 模式而言正是退出循環(huán)的信號。如果你用的是 LT 模式其實(shí)不需要 while 循環(huán)多讀一次也無妨但如果緩沖區(qū)有大量數(shù)據(jù)LT 會反復(fù)喚醒這就是 ET 更高效的原因之一。寫回調(diào)一般發(fā)生在什么時(shí)機(jī)一個(gè)常見場景是業(yè)務(wù)處理完需要給客戶端回寫數(shù)據(jù)。如果你直接在on_read里send數(shù)據(jù)量小還好數(shù)據(jù)量大時(shí)send可能只發(fā)了一部分剩余部分要等EPOLLOUT事件。這時(shí)就要在on_read里把沒發(fā)完的數(shù)據(jù)暫存到c-write_buf然后注冊EPOLLOUT。寫回調(diào)再繼續(xù)發(fā)發(fā)完后記得要把EPOLLOUT從關(guān)心事件里摘掉不然這個(gè) socket 永遠(yuǎn)可寫epoll_wait會瘋狂上報(bào)寫事件形成忙輪詢白白燒 CPU。4.5 連接關(guān)閉的統(tǒng)一出口我強(qiáng)烈建議所有連接關(guān)閉都走一個(gè)函數(shù)conn_close不要在業(yè)務(wù)回調(diào)里散落close(fd)、free(c)static void conn_close(struct conn *c) { if (c-close_flag) return; epoll_ctl(epfd, EPOLL_CTL_DEL, c-fd, NULL); close(c-fd); c-close_flag 1; free(c); }這樣能避免重復(fù)關(guān)閉。如果不設(shè)close_flag同一個(gè) fd 可能在讀回調(diào)和寫回調(diào)里各走一次關(guān)閉第二次的epoll_ctl(DEL)就會失敗報(bào)文件描述符不存在雖然不致命但排查時(shí)非常干擾視線。更隱蔽的問題是對端斷開后錯(cuò)誤包和讀事件先后到達(dá)兩次觸達(dá)同一連接沒有保護(hù)就直接 double free程序直接崩。5. 多線程演進(jìn)單Reactor與主從Reactor怎么選5.1 三種常見方案的對比手寫版單線程Epoll-Reactor能解決大部分長連接高并發(fā)場景但面對圖像處理、復(fù)雜業(yè)務(wù)計(jì)算這類 CPU 密集型任務(wù)單線程回調(diào)再快也只有一個(gè)核在跑。這就得考慮多線程。網(wǎng)上的多線程 Reactor 方案五花八門歸納起來大致是三類單 Reactor 業(yè)務(wù)線程池主線程只有 epoll 做事件監(jiān)聽和 IO 讀寫把業(yè)務(wù)計(jì)算丟給線程池。這個(gè)方案實(shí)現(xiàn)簡單但主線程如果還在做讀緩沖拷貝和大包解析壓力依然大單 Reactor 多線程 IO讓多個(gè)線程各自創(chuàng)建 epoll監(jiān)聽不同的 fd 集合。連接分配時(shí)可以按哈希但遷移和負(fù)載均衡很麻煩主從 Reactor 多線程一個(gè)主 Reactor 只負(fù)責(zé) accept把接受的連接均勻分發(fā)給多個(gè)子 Reactor每個(gè)子 Reactor 有自己獨(dú)立的 epoll 和事件循環(huán)線程業(yè)務(wù)處理再配合線程池。這也是很多高性能網(wǎng)絡(luò)庫采用的結(jié)構(gòu)。我個(gè)人的經(jīng)驗(yàn)連接數(shù)一萬以內(nèi)單 Reactor 線程池足夠連接數(shù)十幾萬甚至上百萬主從 Reactor 的擴(kuò)展優(yōu)勢才會顯現(xiàn)因?yàn)閱尉€程 epoll_wait 在大規(guī)模條件下也有鎖和系統(tǒng)調(diào)用開銷。5.2 線程池引入后的安全隱患多線程場景下最坑的是“一個(gè)連接的事件被兩個(gè)線程同時(shí)處理”。epoll_wait返回后你把這個(gè) fd 的事件交給線程池同時(shí)主循環(huán)繼續(xù)等待下一個(gè)事件。如果該 fd 又變可讀了主循環(huán)再次投遞兩個(gè)線程同時(shí)操作同一個(gè) connection 的緩沖區(qū)數(shù)據(jù)競爭立刻出現(xiàn)。解決辦法有兩個(gè)思路。一個(gè)是用EPOLLONESHOT保證事件觸發(fā)一次后這個(gè) fd 在重新注冊前不會再上報(bào)事件這樣事件不會同時(shí)進(jìn)來另一個(gè)是給每個(gè)連接加鎖但鎖的開銷很大而且容易寫錯(cuò)。實(shí)踐中我更推薦EPOLLONESHOT 業(yè)務(wù)線程池組合線程池處理完業(yè)務(wù)后調(diào)用epoll_ctl(..., EPOLL_CTL_MOD, fd, ...)重新注冊事件。注意重新注冊時(shí)一定要帶上你需要的全部事件類型別只把EPOLLIN加回。如果同時(shí)關(guān)心EPOLLOUT而注冊時(shí)漏掉寫事件就永遠(yuǎn)不會觸發(fā)。5.3 線程池隊(duì)列的背壓問題線程池任務(wù)隊(duì)列不是無限長的。如果你的業(yè)務(wù)處理速度跟不上事件上報(bào)速度任務(wù)隊(duì)列會越積越長內(nèi)存飆升延遲變大。我踩過一次非常慘的坑壓測時(shí)把事件全部塞進(jìn)無界隊(duì)列內(nèi)存漲到幾個(gè) G壓測結(jié)束后任務(wù)還在慢慢跑線上本來就該快速失敗拒絕新連接結(jié)果我硬生生跑成了排隊(duì)調(diào)用。所以任務(wù)隊(duì)列要有上限滿了就斷開新連接或丟棄任務(wù)。網(wǎng)絡(luò)服務(wù)最怕的不是瞬時(shí)壓力而是資源耗盡后的連鎖雪崩。6. 調(diào)優(yōu)、避坑與問題排查速查6.1 系統(tǒng)參數(shù)與 epoll_wait 超時(shí)寫網(wǎng)絡(luò)服務(wù)之前先看一眼系統(tǒng)的 fd 限制。默認(rèn)的ulimit -n可能是 1024一個(gè)連接占一個(gè) fd你最多只能同時(shí)開 1000 個(gè)連接再往上是Too many open files。測試前先改ulimit -n 100000系統(tǒng)級的file-max也要注意/proc/sys/fs/file-max表示內(nèi)核全局可用文件句柄數(shù)。高并發(fā)調(diào)優(yōu)時(shí)經(jīng)常需要調(diào)高但它受到內(nèi)存限制不能隨手改到天文數(shù)字。epoll_wait的maxevents參數(shù)也有講究它不能大于你傳入的 events 數(shù)組長度。常見誤用是數(shù)組就分配 128maxevents 傳 1024內(nèi)核拷貝越界直接報(bào)錯(cuò)。那我數(shù)組分配多大合適一般 1024 夠用如果你知道高峰可能有上萬事件同時(shí)就緒就分配對應(yīng)大小。賦值時(shí)最好用sizeof(events) / sizeof(events[0])而不是硬編碼避免改數(shù)組時(shí)忘了改參數(shù)。6.2 信號中斷與EINTR問題epoll_wait是阻塞調(diào)用一旦進(jìn)程收到信號它可能被直接打斷返回 -1errno設(shè)為EINTR。新手最容易在這個(gè)地方犯渾看到epoll_wait返回 -1 就 panic直接打印錯(cuò)誤退出進(jìn)程或者不加判斷繼續(xù)走循環(huán)。正確做法是遇到EINTR就continue不要把它當(dāng)異常。這一點(diǎn)我在 4.2 的代碼里已經(jīng)寫出來了但再強(qiáng)調(diào)一次因?yàn)榫€上很多偶發(fā)性的“CPU 跳高”或者“服務(wù)假死”都和它有關(guān)。還有一個(gè)延伸問題如果在信號處理函數(shù)里做了不安全的操作比如打印、調(diào)用非異步信號安全函數(shù)可能破壞主循環(huán)狀態(tài)。我的習(xí)慣是信號處理函數(shù)里只設(shè)置一個(gè)volatile sig_atomic_t標(biāo)志主循環(huán)里再檢查這個(gè)標(biāo)志決定是否平滑退出。6.3 我踩過的幾個(gè)坑整理下面這張表是我自己在實(shí)現(xiàn) Epoll-Reactor 過程中踩過的典型問題很值得復(fù)制下來貼在工位上具體現(xiàn)象根因分析解決方案壓測時(shí)線程卡死CPU 0%accept 或 read 后沒設(shè)置非阻塞ET 模式下讀到緩沖區(qū)空就一直阻塞所有連接 fd 在 accept 后立刻O_NONBLOCKEPOLLOUT瘋狂觸發(fā)CPU 滿載寫回調(diào)處理完數(shù)據(jù)沒取消EPOLLOUT事件寫完后epoll_ctl(MOD)把 events 改為只關(guān)心EPOLLIN隨機(jī)段錯(cuò)誤壓測必現(xiàn)連接關(guān)閉后沒從 epoll 刪除fd 被復(fù)用后 data.ptr 懸掛統(tǒng)一conn_close先 DEL 再 close 再 free數(shù)據(jù)明明發(fā)了一部分客戶端收不全ET 模式下沒循環(huán) send剩余數(shù)據(jù)沒有寫回調(diào)補(bǔ)充寫緩沖未清空時(shí)注冊EPOLLOUT發(fā)完再摘除客戶端斷開后服務(wù)端沒感知只注冊了EPOLLIN沒處理EPOLLRDHUP或讀返回 0注冊EPOLLIN | EPOLLRDHUPread 返回 0 時(shí)關(guān)閉連接數(shù)一高就Too many open files用戶級/進(jìn)程級 fd 限制未調(diào)修改ulimit -n必要時(shí)調(diào)整/etc/security/limits.conf6.4 日志與調(diào)試心得遇到疑難 bug不要憑眼睛瞪著屏幕猜。我調(diào)試 epoll 相關(guān)的崩潰問題時(shí)最有效的工具是帶 fd 號的信息日志。每個(gè)關(guān)鍵步驟都打印事件注冊ADD fd12 eventsEPOLLIN事件分發(fā)READY fd12 eventsEPOLLIN|EPOLLOUT連接關(guān)閉CLOSE fd12當(dāng)你發(fā)現(xiàn)某個(gè) fd 關(guān)閉后還收到 READY大概率是資源生命周期管理出問題了順著日志就能鎖定到哪一行的回調(diào)沒有正確清理。這比 gdb 打斷點(diǎn)更高效因?yàn)楦卟l(fā)下的崩潰往往很難原地復(fù)現(xiàn)。再補(bǔ)一個(gè)小建議在epoll_ctl失敗時(shí)除了perror最好把當(dāng)前 fd 號和操作類型也打出來。EBADF、EEXIST、ENOENT這三個(gè)錯(cuò)誤碼在調(diào)優(yōu)階段出現(xiàn)頻率極高看到日志你能秒懂是重復(fù)添加、重復(fù)刪除還是 fd 已失效。最后分享一個(gè)我自己的經(jīng)驗(yàn)剛學(xué) Epoll-Reactor 的時(shí)候不要急著上多線程、主從 Reactor先拿單線程版本跑通一個(gè)小型消息推送服務(wù)故意壓幾次斷開連接場景把所有生命周期問題暴露出來再演進(jìn)線程池也不遲。這套模式看著只有幾段代碼真正的復(fù)雜度全在連接狀態(tài)的收放之間把“善后邏輯”梳理清楚了高并發(fā)這條路才算真正邁過門檻。