先聊一個(gè)我在面試?yán)锝?jīng)常問的問題一個(gè)read調(diào)用打到內(nèi)核里數(shù)據(jù)沒到的時(shí)候你的程序到底在等什么這個(gè)問題看著基礎(chǔ)但能講清楚的人真不多。很多人都會(huì)背“阻塞IO、非阻塞IO、多路復(fù)用、信號(hào)驅(qū)動(dòng)IO、異步IO”可真到線上服務(wù)扛不住、CPU飆高、連接一多就卡的時(shí)候往往發(fā)現(xiàn)自己其實(shí)沒搞懂這些模型之間的區(qū)別更不知道從 select 到 epoll 到底改進(jìn)了什么。我個(gè)人做網(wǎng)絡(luò)服務(wù)這些年最大的體會(huì)是五大 IO 模型不是五個(gè)孤立的概念它是一條“怎么把CPU從等數(shù)據(jù)里解放出來”的演進(jìn)路線。而多路轉(zhuǎn)接就是這條路上最關(guān)鍵的一站。這篇文章我會(huì)把五個(gè)模型逐個(gè)拆開再重點(diǎn)把 select、poll、epoll 這三代多路轉(zhuǎn)接講透最后放一些我實(shí)際踩過的坑和排查思路。不管你是剛起步看內(nèi)核的開發(fā)者還是已經(jīng)在寫高并發(fā)服務(wù)的工程師這篇文章都能給你一個(gè)可以直接拿去對照實(shí)踐的框架。1. 為什么搞懂 IO 模型是基本功1.1 一次 read 調(diào)用到底經(jīng)歷了什么一個(gè)最簡單的阻塞read看起來就是你調(diào)用它它給你返回?cái)?shù)據(jù)。實(shí)際上內(nèi)核做了兩件事第一等數(shù)據(jù)到達(dá)接收緩沖區(qū)第二把數(shù)據(jù)從內(nèi)核緩沖區(qū)拷貝到用戶態(tài)緩沖區(qū)。阻塞就阻塞在第一步。對網(wǎng)絡(luò) socket 來說數(shù)據(jù)從網(wǎng)卡到內(nèi)核接收隊(duì)列中間要經(jīng)過中斷、協(xié)議棧處理、TCP 校驗(yàn)、順序重組等一堆環(huán)節(jié)。在數(shù)據(jù)沒到之前發(fā)起read的線程如果選擇等待那它就只能掛在那什么事情都不做。這就好比你去奶茶店點(diǎn)單店員跟你說“稍等前面還有三杯”你就在柜臺(tái)前站著盯著操作臺(tái)既不玩手機(jī)也不走開——這就是阻塞。非阻塞的情況是你問店員“好了沒”她說“沒好”你轉(zhuǎn)頭去逛了一圈過兩分鐘再回來問一次。這期間你確實(shí)做了別的事但反復(fù)回來問是有代價(jià)的。多路轉(zhuǎn)接則是另一種思路你把一百個(gè)訂單號(hào)都告訴店員讓她好了就喊一聲“哪個(gè)號(hào)好了”然后你在休息區(qū)睡一覺有聲音了再過去取。這一下就把“一個(gè)人盯一個(gè)奶茶杯”變成了“一個(gè)人盯一百個(gè)奶茶杯”。搞懂這個(gè)底層邏輯比記住幾個(gè) API 重要得多。因?yàn)榫€上服務(wù)真正的問題往往不是“CPU 不夠快”而是大量線程堵在read上白白掛死系統(tǒng)線程上下文切換被打爆。1.2 五大模型怎么用一張表看懂先給一張總表后續(xù)每一節(jié)再展開。這張表我建議你直接存下來面試和方案選型都能用。模型數(shù)據(jù)沒到時(shí)的行為應(yīng)用進(jìn)程能繼續(xù)干活嗎數(shù)據(jù)拷貝由誰完成典型實(shí)現(xiàn)阻塞 IO進(jìn)程睡眠等待不能同步拷貝應(yīng)用參與等待read/recv非阻塞 IO立即返回EAGAIN應(yīng)用輪詢能但要反復(fù)檢查同步拷貝應(yīng)用參與等待O_NONBLOCKreadIO 多路轉(zhuǎn)接阻塞在select/epoll_wait但一次等很多 fd能被通知后處理就緒 fd同步拷貝但只處理已就緒 fdselect/poll/epoll信號(hào)驅(qū)動(dòng) IO注冊信號(hào)數(shù)據(jù)就緒時(shí)內(nèi)核發(fā)信號(hào)能信號(hào)到了再去讀同步拷貝應(yīng)用收到信號(hào)后讀取SIGIO/O_ASYNC異步 IO發(fā)起請求后完全不管能完成回調(diào)/事件通知內(nèi)核完成全部讀拷貝再通知io_uring/aio_*還有一對特別容易混的概念阻塞/非阻塞說的是發(fā)起 IO 的線程自己能不能被掛起同步/異步說的是數(shù)據(jù)從內(nèi)核到用戶態(tài)的整個(gè) IO 過程是不是需要應(yīng)用參與到底。阻塞 IO、非阻塞 IO、多路轉(zhuǎn)接、信號(hào)驅(qū)動(dòng)都是“同步”的只有真正的異步模型比如 io_uring能讓你發(fā)完請求就不管內(nèi)核把數(shù)據(jù)都放到你的緩沖區(qū)之后再叫你。2. 五大 IO 模型逐個(gè)拆解2.1 阻塞 IO最省心也最貴阻塞 IO 是默認(rèn)套路。一個(gè) socket 默認(rèn)就是阻塞模式accept會(huì)一直等到有連接進(jìn)來read會(huì)一直等到有數(shù)據(jù)。寫代碼的人是爽了邏輯一行到底但服務(wù)扛不住。你寫一個(gè)最簡單的多線程服務(wù)來一個(gè)連接開一個(gè)線程。連接少的時(shí)候沒事連接到幾千個(gè)線程數(shù)和 CPU 核數(shù)嚴(yán)重失真操作系統(tǒng)為了切換這些等待中的線程要瘋狂保存恢復(fù)上下文這些線程大多數(shù)都阻塞在read上一個(gè)數(shù)據(jù)都沒等來。內(nèi)存也被線程棧吃掉一個(gè)線程默認(rèn)棧 8MB4000 個(gè)線程光棧就 32GB服務(wù)器直接給你臉色看。所以阻塞 IO 適合連接少、每個(gè)連接都有持續(xù)大流量傳輸?shù)膱鼍氨热缟倭块L連接做文件傳輸。你要是想用它撐上萬客戶端不是不行但要把線程池、IO 超時(shí)、連接數(shù)量管理全部做得非常精細(xì)成本遠(yuǎn)大于收益。2.2 非阻塞 IO從“死等”變成“反復(fù)問”非阻塞 IO 是給 socket 加上O_NONBLOCK標(biāo)志數(shù)據(jù)沒到的時(shí)候read立刻返回 -1errno是EAGAIN或EWOULDBLOCK。這樣單線程就能同時(shí)“盯”多個(gè)連接每個(gè)都讀一次讀不到就去干別的回頭再讀。但這個(gè)方案的致命傷是輪詢。假設(shè)你有 10000 個(gè)連接每次想知道有沒有數(shù)據(jù)就要對這 10000 個(gè) fd 全部執(zhí)行一遍非阻塞read或者用ioctl(fd, FIONREAD)去查可讀字節(jié)數(shù)。大部分調(diào)用都是無功而返CPU 被這種空轉(zhuǎn)的系統(tǒng)調(diào)用燒掉了性能反而更差。非阻塞真正的價(jià)值不是單獨(dú)用而是作為多路轉(zhuǎn)接的輔助手段epoll 通知你“這個(gè) fd 可讀”之后你用一個(gè)非阻塞的read去盡量把數(shù)據(jù)讀完讀到EAGAIN就收手這樣既不會(huì)阻塞在某個(gè)連接上也不會(huì)因?yàn)槁x拖垮事件循環(huán)。2.3 信號(hào)驅(qū)動(dòng) IO內(nèi)核主動(dòng)喊你但細(xì)節(jié)勸退信號(hào)驅(qū)動(dòng) IO 的思路是給 fd 綁定SIGIO信號(hào)數(shù)據(jù)就緒時(shí)內(nèi)核發(fā)信號(hào)給進(jìn)程進(jìn)程在信號(hào)處理函數(shù)里再去讀取。聽著比非阻塞輪詢省 CPU因?yàn)樗挥梅磸?fù)“問”內(nèi)核。但現(xiàn)實(shí)里這個(gè)模型很尷尬。信號(hào)處理函數(shù)運(yùn)行時(shí)的上下文限制很多你不能在里面隨便調(diào)用非異步安全函數(shù)不同 Unix 系系統(tǒng)對SIGIO的語義還不完全一致Linux 上對 socket 的支持和 BSD 系表現(xiàn)也有差異。寫起來既要處理信號(hào)又要處理主循環(huán)一不小心就把狀態(tài)搞亂了。在 Linux 服務(wù)端信號(hào)驅(qū)動(dòng) IO 一直是“聽說過、很少用”的狀態(tài)。它算一種過渡思路能幫你理解“內(nèi)核主動(dòng)通知”這件事但真正把這個(gè)理念發(fā)揚(yáng)光大的是后面的多路轉(zhuǎn)接和異步 IO。2.4 異步 IO發(fā)完請求就撒手異步 IO 是終極形態(tài)。你發(fā)起一個(gè)讀請求不需要等待不需要輪詢不需要信號(hào)內(nèi)核在數(shù)據(jù)到達(dá)并拷貝到你的用戶態(tài)緩沖區(qū)之后通過完成事件通知你。你全程不參與等待和拷貝干別的事情去。Linux 上早期的aio_read/io_submit主要面向磁盤 IO限制不少。近幾年真正把異步 IO 做出名堂的是io_uring它用內(nèi)核與用戶態(tài)共享的 SQ/CQ 環(huán)形隊(duì)列來提交請求和收割結(jié)果減少了系統(tǒng)調(diào)用次數(shù)性能非常猛?，F(xiàn)在很多存儲(chǔ)引擎和高性能網(wǎng)絡(luò)框架都在向 io_uring 靠攏。不過 io_uring 對內(nèi)核版本有要求實(shí)際落地時(shí)還要處理注冊固定文件、固定內(nèi)存緩沖區(qū)、內(nèi)核線程池等一堆細(xì)節(jié)?，F(xiàn)階段做網(wǎng)絡(luò)服務(wù)主流的可靠選擇仍然是 epollio_uring 更像是給未來備著的大殺器等你真有百萬級 IOPS 需求時(shí)再上。2.5 模型的演進(jìn)邏輯從等一個(gè)到等一批把五個(gè)模型串起來看脈絡(luò)很清楚阻塞 IO 讓線程等單個(gè)數(shù)據(jù)非阻塞 IO 讓線程反復(fù)查單個(gè)數(shù)據(jù)多路轉(zhuǎn)接讓線程一次等一批數(shù)據(jù)信號(hào)驅(qū)動(dòng)讓內(nèi)核主動(dòng)通知單個(gè) fd異步 IO 讓內(nèi)核把整個(gè) IO 干完再通知。演進(jìn)的核心動(dòng)力是“規(guī)避無效等待”。你希望 CPU 要么在算業(yè)務(wù)邏輯要么在真正等到數(shù)據(jù)時(shí)被喚醒而不是在一個(gè)個(gè)沒數(shù)據(jù)的 fd 上空轉(zhuǎn)。多路轉(zhuǎn)接之所以至今還是網(wǎng)絡(luò)服務(wù)的中流砥柱正是因?yàn)樗谩耙粋€(gè)等待點(diǎn)管理海量連接”的方式把無效等待的浪費(fèi)壓到了理論最低。3. 多路轉(zhuǎn)接第一代select 為什么撐不住萬級連接3.1 select 的原理和基本流程select 的核心是把一批 fd 放進(jìn)三個(gè)集合可讀、可寫、異常交給內(nèi)核去等。內(nèi)核會(huì)遍歷這些 fd檢查它們有沒有變化然后再把結(jié)果寫回集合。使用流程大致是FD_ZERO清空集合FD_SET把 fd 放進(jìn)去調(diào)用select(nfds, readfds, writefds, exceptfds, timeout)。nfds要填最大 fd 加 1。返回后用FD_ISSET(fd, readfds)判斷哪個(gè) fd 就緒。一個(gè)常見誤區(qū)是 nfds 的填法。很多人直接填 1024寫大一點(diǎn)不影響內(nèi)核只看你填的 bit 范圍填大了會(huì)多掃描很多無效位填小了又會(huì)漏掉高位 fd。正確姿勢是遍歷時(shí)維護(hù)一個(gè)max_fd每次取最大的那個(gè)再加 1。3.2 select 的三個(gè)硬傷第一個(gè)硬傷是 fd 數(shù)量上限。fd_set在 glibc 里默認(rèn)最多 1024 個(gè) bit也就是最多監(jiān)聽 1024 個(gè) fd。你可以通過重新定義FD_SETSIZE再包含頭文件來把這個(gè)值加大但很多底層邏輯是按位圖來的改起來既不優(yōu)雅也不可移植生產(chǎn)環(huán)境根本不敢亂動(dòng)。第二個(gè)硬傷是每次調(diào)用都要重新填寫集合。select 返回時(shí)會(huì)把內(nèi)核就緒狀態(tài)寫回到同一個(gè)集合里把你原來“想監(jiān)聽哪些 fd”的信息沖掉了。下一次調(diào)用前必須把所有 fd 重新FD_SET一遍這個(gè)復(fù)制和遍歷成本是實(shí)打?qū)嵉?O(n)。第三個(gè)硬傷是內(nèi)核和用戶態(tài)的掃描成本。內(nèi)核要遍歷所有 fd 判斷是否就緒返回后用戶還要遍歷整個(gè)集合找出到底哪個(gè)就緒。連接數(shù)一多比如一萬個(gè) fd 里只有兩個(gè)就緒你卻要翻一萬次集合浪費(fèi)很嚴(yán)重。這就是 select 面對 C10K 直接力不從心的根本原因。3.3 一個(gè) select 的代碼骨架下面這個(gè)例子只演示骨架重點(diǎn)是集合處理流程。為了聚焦我省略了完整錯(cuò)誤處理和地址初始化。#include stdio.h #include sys/select.h #include sys/socket.h #include netinet/in.h #include unistd.h #include string.h int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8080); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); fd_set read_fds; FD_ZERO(read_fds); FD_SET(listen_fd, read_fds); while (1) { fd_set tmp read_fds; // 必須備份 struct timeval tv {5, 0}; int ret select(listen_fd 1, tmp, NULL, NULL, tv); if (ret 0) break; if (ret 0) continue; // 超時(shí) if (FD_ISSET(listen_fd, tmp)) { int client_fd accept(listen_fd, NULL, NULL); if (client_fd 0) { FD_SET(client_fd, read_fds); // 后續(xù)還應(yīng)該更新 listen_fd 與 client_fd 的最大值 } } } }注意這個(gè)例子里我用了tmp read_fds來避免集合被內(nèi)核改寫這是每個(gè)寫 select 的人都該養(yǎng)成的習(xí)慣。還有維護(hù)max_fd的邏輯沒有寫完整實(shí)際項(xiàng)目里如果新增的 client_fd 比 listen_fd 大必須同步更新 nfds否則高位的 fd 永遠(yuǎn)等不到通知。4. poll 和 epoll多路轉(zhuǎn)接的進(jìn)化之路4.1 poll改掉了數(shù)量限制但沒改掉掃描本質(zhì)poll 比 select 更進(jìn)一步它不再用位圖而是用一個(gè)struct pollfd數(shù)組。每個(gè)元素包含fd、events你要監(jiān)聽的事件和revents內(nèi)核回填的就緒事件。內(nèi)核只改revents不會(huì)破壞你原來的events所以不需要像 select 那樣每次重新設(shè)置。數(shù)量上限也解除了poll 理論上可以監(jiān)聽任意多個(gè) fd只要內(nèi)存扛得住。它的事件類型更豐富POLLIN、POLLOUT、POLLERR、POLLHUP用起來比位圖清晰。但 poll 的核心問題還在內(nèi)核每次都要把整個(gè) pollfd 數(shù)組從用戶態(tài)拷進(jìn)去然后線性掃描一遍所有 fd。返回后用戶也要線性掃一遍數(shù)組才能知道誰就緒。連接數(shù)越大掃描成本越明顯。也就是說poll 優(yōu)化了“易用性”但沒有優(yōu)化“復(fù)雜度”O(jiān)(n) 的本質(zhì)沒變。4.2 epoll紅黑樹加就緒鏈表解決復(fù)雜度epoll 和 select/poll 最大的區(qū)別是它把“每次傳入一批 fd”變成了“先把 fd 注冊進(jìn)內(nèi)核由內(nèi)核長期維護(hù)”。這套設(shè)計(jì)由三個(gè)接口組成epoll_create創(chuàng)建 epoll 實(shí)例epoll_ctl增刪改 fd 的監(jiān)聽事件epoll_wait等待就緒事件返回。用戶注冊過的 fd 會(huì)掛在一棵紅黑樹上內(nèi)核不需要再從用戶態(tài)重新拷貝整個(gè)集合同時(shí)內(nèi)核在設(shè)備驅(qū)動(dòng)層掛了一個(gè)回調(diào)只要 fd 上有數(shù)據(jù)到達(dá)回調(diào)就會(huì)把這個(gè) fd 塞進(jìn)就緒鏈表。epoll_wait只需要把就緒鏈表里的那幾個(gè) entry 拷貝到用戶態(tài)數(shù)組復(fù)雜度從 O(n) 降到了 O(就緒數(shù))。這就很漂亮了一萬個(gè)連接里只有兩三個(gè)活躍你只處理兩三個(gè)。4.3 LT 和 ET要命的邊緣觸發(fā)epoll 的工作模式有兩種很多人就是在這踩坑。水平觸發(fā)LT是默認(rèn)模式。只要 fd 的緩沖區(qū)里還有數(shù)據(jù)可讀每次epoll_wait都會(huì)告訴你這個(gè) fd 可讀。這個(gè)模式的優(yōu)點(diǎn)是你不怕漏讀這次沒讀完下次還會(huì)通知你。缺點(diǎn)是如果數(shù)據(jù)頻繁到來而你處理得慢同一個(gè) fd 會(huì)被反復(fù)喚醒造成一定程度的忙喚醒。邊緣觸發(fā)ET模式要在注冊事件時(shí)加上EPOLLET。它只在 fd 狀態(tài)發(fā)生“變化”時(shí)通知一次比如緩沖區(qū)從無數(shù)據(jù)變成有數(shù)據(jù)。如果這次通知你只讀了一部分?jǐn)?shù)據(jù)讀完之后內(nèi)核不會(huì)因?yàn)椤斑€有剩余數(shù)據(jù)”而再次告訴你。你必須用非阻塞 fd在EPOLLIN觸發(fā)后循環(huán)調(diào)用read直到返回EAGAIN把數(shù)據(jù)盡可能讀完否則剩下的數(shù)據(jù)可能要等下一次新數(shù)據(jù)到達(dá)時(shí)才觸發(fā)業(yè)務(wù)上很容易造成消息延遲甚至粘包截?cái)?。我個(gè)人的建議是新手做練習(xí)直接用 LT能把業(yè)務(wù)寫明白線上追求性能再用 ET但一定要配合非阻塞 fd 和嚴(yán)格的“循環(huán)讀至 EAGAIN”邏輯。4.4 一個(gè)可落地的 epoll 服務(wù)端骨架下面這段代碼不是能直接扔上線的高可用工程但核心骨架是完整的我用 ET 模式加非阻塞 fd#include stdio.h #include sys/epoll.h #include sys/socket.h #include netinet/in.h #include fcntl.h #include unistd.h #include string.h #include errno.h static void set_nonblock(int fd); // 用 fcntl 加 O_NONBLOCK int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8080); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); set_nonblock(listen_fd); int epfd epoll_create1(EPOLL_CLOEXEC); struct epoll_event ev; ev.events EPOLLIN; ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[64]; char buf[4096]; while (1) { int n epoll_wait(epfd, events, 64, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (events[i].events EPOLLERR) { close(fd); continue; } if (fd listen_fd) { while (1) { // ET 模式下 accept 也要循環(huán)處理 int cfd accept(listen_fd, NULL, NULL); if (cfd 0) break; set_nonblock(cfd); ev.events EPOLLIN | EPOLLET; ev.data.fd cfd; epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, ev); } } else { while (1) { // ET 模式下 read 必須讀到 EAGAIN ssize_t r read(fd, buf, sizeof(buf)); if (r 0) { // 處理業(yè)務(wù)數(shù)據(jù)這里只做展示 } else if (r 0) { close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) break; close(fd); break; } } } } } }這段骨架里有兩個(gè)容易被忽略的細(xì)節(jié)一是 listen_fd 也設(shè)成了非阻塞否則 ET 模式下 accept 循環(huán)可能被最后一個(gè)空連接卡住二是read返回 0 表示對端關(guān)閉必須從 epoll 狀態(tài)里摘除并 close否則會(huì)一直觸發(fā)EPOLLERR或EPOLLHUP。5. 實(shí)操選型、常見問題與避坑記錄5.1 不同場景到底選哪個(gè)模型選型不是越新越好要結(jié)合連接規(guī)模、活躍度、業(yè)務(wù)是否重 IO。場景特征推薦方案理由連接量小幾十到幾百邏輯簡單阻塞 IO 線程池代碼清晰維護(hù)成本最低連接量中等但每個(gè)連接流量穩(wěn)定poll 或 LT 模式 epoll避免 ET 帶來的復(fù)雜讀取邏輯連接上萬但活躍連接比例低epoll LT/ET事件驅(qū)動(dòng)復(fù)雜度最優(yōu)空閑連接不消耗 CPU連接多且每個(gè)連接頻繁大數(shù)據(jù)讀寫epoll 多線程 worker 非阻塞讀寫分擔(dān)避免單線程事件循環(huán)被慢客戶端拖死磁盤 IO 密集比如日志/存儲(chǔ)引擎io_uring / 異步 IO內(nèi)核完成拷貝后回調(diào)減少同步等待還有一個(gè)被問爛了的問題既然多路轉(zhuǎn)接監(jiān)聽的是 fd而 fd 本質(zhì)是內(nèi)核對象那 Redis 早期為什么用 ae 事件庫包 epoll答案是單線程模型下事件循環(huán)把所有連接等好之后命令處理還是同步的這并不矛盾。事件驅(qū)動(dòng)解決的是“等網(wǎng)絡(luò)事件”的問題不是“讓業(yè)務(wù)邏輯異步”的問題。理解這個(gè)分界能避免很多架構(gòu)上的誤判。5.2 常見問題速查表問題現(xiàn)象排查與解決select/poll 連接數(shù)一多性能崩CPU 高空轉(zhuǎn)明顯改 epoll或者先查是否有 fd 沒設(shè)置非阻塞導(dǎo)致 while 循環(huán)卡住ET 模式下丟數(shù)據(jù)只 read 一次就處理剩余數(shù)據(jù)被留在內(nèi)核緩沖必須循環(huán) read 直到EAGAIN并用應(yīng)用層緩沖拼接完整消息epoll_ctl返回EEXIST重復(fù)添加同一個(gè) fd先EPOLL_CTL_DEL再 ADD或直接EPOLL_CTL_MOD修改事件epoll_ctl返回ENOENT試圖刪除不存在的 fd檢查 fd 是否已經(jīng)被 close多線程并發(fā) close 容易導(dǎo)致這種問題accept返回EMFILE進(jìn)程 fd 數(shù)耗盡提高ulimit -n并可先臨時(shí) accept 后立刻 close 來緩解設(shè)計(jì)上要限制單連接資源多個(gè)線程同時(shí)epoll_wait出現(xiàn)驚群多個(gè)線程同時(shí)被喚醒使用EPOLLEXCLUSIVE或每個(gè)線程獨(dú)立一個(gè) epoll fd或用SO_REUSEPORT 分流管理調(diào)用read返回 0對端已關(guān)閉這不只是“沒有數(shù)據(jù)”必須 close 并移除監(jiān)聽否則會(huì)一直觸發(fā)事件5.3 幾個(gè)我實(shí)際踩過的坑先說 ET 模式下的消息截?cái)鄦栴}。有一次我把一個(gè)服務(wù)改成 ET結(jié)果上游發(fā)來的一條超大消息在第一次觸發(fā)時(shí)只讀完一部分處理邏輯卻直接按完整消息解析了剩下半截?cái)?shù)據(jù)留在內(nèi)核緩沖里。因?yàn)?ET 不再重復(fù)通知服務(wù)就一直等直到下一條新消息到來才觸發(fā)把兩條消息拼在一起徹底亂套。后來我把讀取邏輯改成“循環(huán)讀至 EAGAIN再交給一個(gè)按長度拆包的應(yīng)用層緩沖”才算真正解決。這個(gè)教訓(xùn)很值錢ET 省下來的喚醒次數(shù)要靠更嚴(yán)謹(jǐn)?shù)淖x取代碼來保障。再說驚群。多線程各持一個(gè) epoll fd 還好但如果是多個(gè)線程epoll_wait同一個(gè) epoll fd內(nèi)核版本較老時(shí)一個(gè)事件可能把多個(gè)等待線程同時(shí)喚醒只有一個(gè)線程搶到 accept其他線程白醒。線上壓測時(shí)我看到這種問題特別頭疼。解決辦法是給 epoll 事件加EPOLLEXCLUSIVE或者用多個(gè) epoll fd 配合SO_REUSEPORT做多核分?jǐn)偂：髞砦腋矚g后者因?yàn)槊總€(gè)線程獨(dú)立 epoll fd還能避免跨線程處理連接時(shí)的鎖競爭。還有一次排查epoll_wait瘋狂返回EPOLLERR查了半天才意識(shí)到是連接被對端重置后我又忘記從監(jiān)聽里移除。每次epoll_wait都會(huì)把這個(gè)壞 fd 扔回來形成醒死循環(huán)。所以你在事件處理里看到EPOLLERR或EPOLLHUP時(shí)第一反應(yīng)不是讀數(shù)據(jù)而是清理資源。這也是很多新人的盲區(qū)。5.4 壓測和上線前的小經(jīng)驗(yàn)我自己每次寫完一個(gè)事件驅(qū)動(dòng)服務(wù)都會(huì)先做三件事。第一把所有新 accept 回來的連接都設(shè)成非阻塞即使我用的是 LT 模式也要防住某個(gè)連接在read時(shí)把整個(gè)事件循環(huán)拖死。第二把listen_fd也設(shè)非阻塞因?yàn)樵?accept 循環(huán)里如果最后一個(gè) accept 剛好遇到空隊(duì)列阻塞的 accept 會(huì)卡住循環(huán)導(dǎo)致后續(xù)連接全部處理不了。第三編譯時(shí)別忽略警告多線程環(huán)境下一定要用accept4(..., SOCK_NONBLOCK | SOCK_CLOEXEC)這類原子操作避免 fd 泄漏和線程間競態(tài)。線程模型方面如果業(yè)務(wù)邏輯里包含數(shù)據(jù)庫查詢、外部 RPC、復(fù)雜計(jì)算等耗時(shí)操作不要在事件循環(huán)線程里直接做。事件循環(huán)只負(fù)責(zé)快速接收數(shù)據(jù)然后把任務(wù)投遞到工作線程池。等結(jié)果回來需要往 fd 寫數(shù)據(jù)時(shí)再通過事件通知主循環(huán)。這個(gè)模型的本質(zhì)是把“IO 就緒”和“業(yè)務(wù)計(jì)算”徹底分層你可以先按“事件循環(huán) 線程池”的模板起步后面再加背壓、限流、超時(shí)管理。最后再分享一個(gè)細(xì)節(jié)epoll 的timeout參數(shù)單位是毫秒但這個(gè)精度并不準(zhǔn)它受內(nèi)核調(diào)度和負(fù)載影響實(shí)際喚醒可能晚幾毫秒甚至幾十毫秒。定時(shí)任務(wù)、心跳超時(shí)這類邏輯不要把寶全押在 epoll 的超時(shí)上最好單獨(dú)維護(hù)一個(gè)定時(shí)器堆比如小根堆或時(shí)間輪把最緊急的過期時(shí)間作為epoll_wait的超時(shí)值。這樣既不用 spins也不會(huì)因?yàn)?sleep 太久誤了超時(shí)判斷。