在 Linux 系統(tǒng)之中有一個核心武器：epoll 池，在高并發(fā)的，高吞吐的 IO 系統(tǒng)中常常見到 epoll 的身影。

IO 多路復(fù)用

在 Go 里最核心的是 Goroutine ，也就是所謂的協(xié)程，協(xié)程最妙的一個實現(xiàn)就是異步的代碼長的跟同步代碼一樣。比如在 Go 中，網(wǎng)絡(luò) IO 的 read，write 看似都是同步代碼，其實底下都是異步調(diào)用，一般流程是：

write （ /* IO 參數(shù) */ ）

請求入隊

等待完成

后臺 loop 程序

發(fā)送網(wǎng)絡(luò)請求

喚醒業(yè)務(wù)方

Go 配合協(xié)程在網(wǎng)絡(luò) IO 上實現(xiàn)了異步流程的代碼同步化。核心就是用 epoll 池來管理網(wǎng)絡(luò) fd 。

實現(xiàn)形式上，后臺的程序只需要 1 個就可以負(fù)責(zé)管理多個 fd 句柄，負(fù)責(zé)應(yīng)對所有的業(yè)務(wù)方的 IO 請求。這種一對多的 IO 模式我們就叫做 IO 多路復(fù)用。

多路是指？多個業(yè)務(wù)方（句柄）并發(fā)下來的 IO 。

復(fù)用是指？復(fù)用這一個后臺處理程序。

站在 IO 系統(tǒng)設(shè)計人員的角度，業(yè)務(wù)方咱們沒辦法提要求，因為業(yè)務(wù)是上帝，只有你服從的份，他們要創(chuàng)建多個 fd，那么你就需要負(fù)責(zé)這些 fd 的處理，并且最好還要并發(fā)起來。

業(yè)務(wù)方?jīng)]法提要求，那么只能要求后臺 loop 程序了！

要求什么呢？快！快！快！這就是最核心的要求，處理一定要快，要給每一個 fd 通道最快的感受，要讓每一個 fd 覺得，你只在給他一個人跑腿。

那有人又問了，那我一個 IO 請求（比如 write ）對應(yīng)一個線程來處理，這樣所有的 IO 不都并發(fā)了嗎？是可以，但是有瓶頸，線程數(shù)一旦多了，性能是反倒會差的。

這里不再對比多線程和 IO 多路復(fù)用實現(xiàn)高并發(fā)之間的區(qū)別，詳細(xì)的可以去了解下 nginx 和 redis 高并發(fā)的秘密。

1 最樸實的實現(xiàn)方式？

我不用任何其他系統(tǒng)調(diào)用，能否實現(xiàn) IO 多路復(fù)用？

可以的。那么寫個 for 循環(huán)，每次都嘗試 IO 一下，讀/寫到了就處理，讀/寫不到就 sleep 下。這樣我們不就實現(xiàn)了 1 對多的 IO 多路復(fù)用嘛。

while True：

for each 句柄數(shù)組 {

read/write（fd， /* 參數(shù) */）

}

sleep（1s）

慢著，有個問題，上面的程序可能會被卡死在第三行，使得整個系統(tǒng)不得運行，為什么？

默認(rèn)情況下，我們 create 出的句柄是阻塞類型的。我們讀數(shù)據(jù)的時候，如果數(shù)據(jù)還沒準(zhǔn)備好，是會需要等待的，當(dāng)我們寫數(shù)據(jù)的時候，如果還沒準(zhǔn)備好，默認(rèn)也會卡住等待。所以，在上面?zhèn)未a第三行是可能被直接卡死，而導(dǎo)致整個線程都得到不到運行。

舉個例子，現(xiàn)在有 11，12，13 這 3 個句柄，現(xiàn)在 11 讀寫都沒有準(zhǔn)備好，只要 read/write（11， /*參數(shù)*/） 就會被卡住，但 12，13 這兩個句柄都準(zhǔn)備好了，那遍歷句柄數(shù)組 11，12，13 的時候就會卡死在前面，后面 12，13 則得不到運行。這不符合我們的預(yù)期，因為我們 IO 多路復(fù)用的 loop 線程是公共服務(wù)，不能因為一個 fd 就直接癱瘓。

那這個問題怎么解決？

只需要把 fd 都設(shè)置成非阻塞模式。這樣 read/write 的時候，如果數(shù)據(jù)沒準(zhǔn)備好，返回 EAGIN 的錯誤即可，不會卡住線程，從而整個系統(tǒng)就運轉(zhuǎn)起來了。比如上面句柄 11 還未就緒，那么 read/write（11， /*參數(shù)*/） 不會阻塞，只會報個 EAGIN 的錯誤，這種錯誤需要特殊處理，然后 loop 線程可以繼續(xù)執(zhí)行 12，13 的讀寫。

以上就是最樸實的 IO 多路復(fù)用的實現(xiàn)了。但好像在生產(chǎn)環(huán)境沒見過這種 IO 多路復(fù)用的實現(xiàn)？為什么？

因為還不夠高級。for 循環(huán)每次要定期 sleep 1s，這個會導(dǎo)致吞吐能力極差，因為很可能在剛好要 sleep 的時候，所有的 fd 都準(zhǔn)備好 IO 數(shù)據(jù)，而這個時候卻要硬生生的等待 1s，可想而知。。。

那有同學(xué)又要質(zhì)疑了，那 for 循環(huán)里面就不 sleep 嘛，這樣不就能及時處理了嗎？

及時是及時了，但是 CPU 估計要跑飛了。不加 sleep ，那在沒有 fd 需要處理的時候，估計 CPU 都要跑到 100% 了。這個也是無法接受的。

糾結(jié)了，那 sleep 吞吐不行，不 sleep 浪費 cpu，怎么辦？

這種情況用戶態(tài)很難有所作為，只能求助內(nèi)核來提供機制協(xié)助來。因為內(nèi)核才能及時的管理這些事件的通知和調(diào)度。

我們再梳理下 IO 多路復(fù)用的需求和原理。IO 多路復(fù)用就是 1 個線程處理 多個 fd 的模式。我們的要求是：這個 “1” 就要盡可能的快，避免一切無效工作，要把所有的時間都用在處理句柄的 IO 上，不能有任何空轉(zhuǎn)，sleep 的時間浪費。

有沒有一種工具，我們把一籮筐的 fd 放到里面，只要有一個 fd 能夠讀寫數(shù)據(jù)，后臺 loop 線程就要立馬喚醒，全部馬力跑起來。其他時間要把 cpu 讓出去。

能做到嗎？能，但這種需求只能內(nèi)核提供機制滿足你。

2 這事 Linux 內(nèi)核必須要給個說法？

是的，想要不用 sleep 這種辣眼睛的實現(xiàn)，Linux 內(nèi)核必須出手了，畢竟 IO 的處理都是內(nèi)核之中，數(shù)據(jù)好沒好內(nèi)核最清楚。

內(nèi)核一口氣提供了 3 種工具 select，poll，epoll 。

為什么有 3 種？

歷史不斷改進，矬 -》 較矬 -》 臥槽、高效 的演變而已。

Linux 還有其他方式可以實現(xiàn) IO 多路復(fù)用嗎？

好像沒有了！

這 3 種到底是做啥的？

這 3 種都能夠管理 fd 的可讀可寫事件，在所有 fd 不可讀不可寫無所事事的時候，可以阻塞線程，切走 cpu 。fd 有情況的時候，都要線程能夠要能被喚醒。

而這三種方式以 epoll 池的效率最高。為什么效率最高？

其實很簡單，這里不詳說，其實無非就是 epoll 做的無用功最少，select 和 poll 或多或少都要多余的拷貝，盲猜（遍歷才知道）fd ，所以效率自然就低了。

舉個例子，以 select 和 epoll 來對比舉例，池子里管理了 1024 個句柄，loop 線程被喚醒的時候，select 都是蒙的，都不知道這 1024 個 fd 里誰 IO 準(zhǔn)備好了。這種情況怎么辦？只能遍歷這 1024 個 fd ，一個個測試。假如只有一個句柄準(zhǔn)備好了，那相當(dāng)于做了 1 千多倍的無效功。

epoll 則不同，從 epoll_wait 醒來的時候就能精確的拿到就緒的 fd 數(shù)組，不需要任何測試，拿到的就是要處理的。

epoll 池原理

下面我們看一下 epoll 池的使用和原理。

1 epoll 涉及的系統(tǒng)調(diào)用

epoll 的使用非常簡單，只有下面 3 個系統(tǒng)調(diào)用。

epoll_create

epollctl

epollwait

就這？是的，就這么簡單。

epollcreate 負(fù)責(zé)創(chuàng)建一個池子，一個監(jiān)控和管理句柄 fd 的池子；

epollctl 負(fù)責(zé)管理這個池子里的 fd 增、刪、改；

epollwait 就是負(fù)責(zé)打盹的，讓出 CPU 調(diào)度，但是只要有“事”，立馬會從這里喚醒；

2 epoll 高效的原理

Linux 下，epoll 一直被吹爆，作為高并發(fā) IO 實現(xiàn)的秘密武器。其中原理其實非常樸實：epoll 的實現(xiàn)幾乎沒有做任何無效功。 我們從使用的角度切入來一步步分析下。

首先，epoll 的第一步是創(chuàng)建一個池子。這個使用 epoll_create 來做：

原型：

int epoll_create（int size）;

示例：

epollfd = epoll_create（1024）;

if （epollfd == -1） {

perror（“epoll_create”）;

exit（EXIT_FAILURE）;

}

這個池子對我們來說是黑盒，這個黑盒是用來裝 fd 的，我們暫不糾結(jié)其中細(xì)節(jié)。我們拿到了一個 epollfd ，這個 epollfd 就能唯一代表這個 epoll 池。注意，這里又有一個細(xì)節(jié)：用戶可以創(chuàng)建多個 epoll 池。

然后，我們就要往這個 epoll 池里放 fd 了，這就要用到 epoll_ctl 了

原型：

int epoll_ctl（int epfd， int op， int fd， struct epoll_event *event）;

示例：

if （epoll_ctl（epollfd， EPOLL_CTL_ADD， 11， &ev） == -1） {

perror（“epoll_ctl： listen_sock”）;

exit（EXIT_FAILURE）;

}

上面，我們就把句柄 11 放到這個池子里了，op（EPOLL_CTL_ADD）表明操作是增加、修改、刪除，event 結(jié)構(gòu)體可以指定監(jiān)聽事件類型，可讀、可寫。

第一個跟高效相關(guān)的問題來了，添加 fd 進池子也就算了，如果是修改、刪除呢？怎么做到快速？

這里就涉及到你怎么管理 fd 的數(shù)據(jù)結(jié)構(gòu)了。

最常見的思路：用 list ，可以嗎？功能上可以，但是性能上拉垮。list 的結(jié)構(gòu)來管理元素，時間復(fù)雜度都太高 O（n），每次要一次次遍歷鏈表才能找到位置。池子越大，性能會越慢。

那有簡單高效的數(shù)據(jù)結(jié)構(gòu)嗎？

有，紅黑樹。Linux 內(nèi)核對于 epoll 池的內(nèi)部實現(xiàn)就是用紅黑樹的結(jié)構(gòu)體來管理這些注冊進程來的句柄 fd。紅黑樹是一種平衡二叉樹，時間復(fù)雜度為 O（log n），就算這個池子就算不斷的增刪改，也能保持非常穩(wěn)定的查找性能。

現(xiàn)在思考第二個高效的秘密：怎么才能保證數(shù)據(jù)準(zhǔn)備好之后，立馬感知呢？

epoll_ctl 這里會涉及到一點。秘密就是：回調(diào)的設(shè)置。在 epoll_ctl 的內(nèi)部實現(xiàn)中，除了把句柄結(jié)構(gòu)用紅黑樹管理，另一個核心步驟就是設(shè)置 poll 回調(diào)。

思考來了：poll 回調(diào)是什么？怎么設(shè)置？

先說說 file_operations-》poll 是什么？

在 文件描述符 fd 究竟是什么 說過，Linux 設(shè)計成一切皆是文件的架構(gòu)，這個不是說說而已，而是隨處可見。實現(xiàn)一個文件系統(tǒng)的時候，就要實現(xiàn)這個文件調(diào)用，這個結(jié)構(gòu)體用 struct file_operations 來表示。這個結(jié)構(gòu)體有非常多的函數(shù)，精簡了一些，如下：

struct file_operations {

ssize_t （*read） （struct file *， char __user *， size_t， loff_t *）;

ssize_t （*write） （struct file *， const char __user *， size_t， loff_t *）;

__poll_t （*poll） （struct file *， struct poll_table_struct *）;

int （*open） （struct inode *， struct file *）;

int （*fsync） （struct file *， loff_t， loff_t， int datasync）;

// 。。。。

};

你看到了 read，write，open，fsync，poll 等等，這些都是對文件的定制處理操作，對于文件的操作其實都是在這個框架內(nèi)實現(xiàn)邏輯而已，比如 ext2 如果有對 read/write 做定制化，那么就會是 ext2_read，ext2_write，ext4 就會是 ext4_read，ext4_write。在 open 具體“文件”的時候會賦值對應(yīng)文件系統(tǒng)的 file_operations 給到 file 結(jié)構(gòu)體。

那我們很容易知道 read 是文件系統(tǒng)定制 fd 讀的行為調(diào)用，write 是文件系統(tǒng)定制 fd 寫的行為調(diào)用，file_operations-》poll 呢？

這個是定制監(jiān)聽事件的機制實現(xiàn)。通過 poll 機制讓上層能直接告訴底層，我這個 fd 一旦讀寫就緒了，請底層硬件（比如網(wǎng)卡）回調(diào)的時候自動把這個 fd 相關(guān)的結(jié)構(gòu)體放到指定隊列中，并且喚醒操作系統(tǒng)。

舉個例子：網(wǎng)卡收發(fā)包其實走的異步流程，操作系統(tǒng)把數(shù)據(jù)丟到一個指定地點，網(wǎng)卡不斷的從這個指定地點掏數(shù)據(jù)處理。請求響應(yīng)通過中斷回調(diào)來處理，中斷一般拆分成兩部分：硬中斷和軟中斷。poll 函數(shù)就是把這個軟中斷回來的路上再加點料，只要讀寫事件觸發(fā)的時候，就會立馬通知到上層，采用這種事件通知的形式就能把浪費的時間窗就完全消失了。

劃重點：這個 poll 事件回調(diào)機制則是 epoll 池高效最核心原理。

劃重點：epoll 池管理的句柄只能是支持了 file_operations-》poll 的文件 fd。換句話說，如果一個“文件”所在的文件系統(tǒng)沒有實現(xiàn) poll 接口，那么就用不了 epoll 機制。

第二個問題：poll 怎么設(shè)置？

在 epoll_ctl 下來的實現(xiàn)中，有一步是調(diào)用 vfs_poll 這個里面就會有個判斷，如果 fd 所在的文件系統(tǒng)的 file_operations 實現(xiàn)了 poll ，那么就會直接調(diào)用，如果沒有，那么就會報告響應(yīng)的錯誤碼。

static inline __poll_t vfs_poll（struct file *file， struct poll_table_struct *pt）

{

if （unlikely（！file-》f_op-》poll））

return DEFAULT_POLLMASK;

return file-》f_op-》poll（file， pt）;

}

你肯定好奇 poll 調(diào)用里面究竟是實現(xiàn)了什么？

總結(jié)概括來說：掛了個鉤子，設(shè)置了喚醒的回調(diào)路徑。epoll 跟底層對接的回調(diào)函數(shù)是：ep_poll_callback，這個函數(shù)其實很簡單，做兩件事情：

把事件就緒的 fd 對應(yīng)的結(jié)構(gòu)體放到一個特定的隊列（就緒隊列，ready list）；

喚醒 epoll ，活來啦！

當(dāng) fd 滿足可讀可寫的時候就會經(jīng)過層層回調(diào)，最終調(diào)用到這個回調(diào)函數(shù)，把對應(yīng) fd 的結(jié)構(gòu)體放入就緒隊列中，從而把 epoll 從 epoll_wait 出喚醒。

這個對應(yīng)結(jié)構(gòu)體是什么？

結(jié)構(gòu)體叫做 epitem ，每個注冊到 epoll 池的 fd 都會對應(yīng)一個。

就緒隊列需要用很高級的數(shù)據(jù)結(jié)構(gòu)嗎？

就緒隊列就簡單了，因為沒有查找的需求了呀，只要是在就緒隊列中的 epitem ，都是事件就緒的，必須處理的。所以就緒隊列就是一個最簡單的雙指針鏈表。

小結(jié)下：epoll 之所以做到了高效，最關(guān)鍵的兩點：

內(nèi)部管理 fd 使用了高效的紅黑樹結(jié)構(gòu)管理，做到了增刪改之后性能的優(yōu)化和平衡；

epoll 池添加 fd 的時候，調(diào)用 file_operations-》poll ，把這個 fd 就緒之后的回調(diào)路徑安排好。通過事件通知的形式，做到最高效的運行；

epoll 池核心的兩個數(shù)據(jù)結(jié)構(gòu)：紅黑樹和就緒列表。紅黑樹是為了應(yīng)對用戶的增刪改需求，就緒列表是 fd 事件就緒之后放置的特殊地點，epoll 池只需要遍歷這個就緒鏈表，就能給用戶返回所有已經(jīng)就緒的 fd 數(shù)組；

3 哪些 fd 可以用 epoll 來管理？

再來思考另外一個問題：由于并不是所有的 fd 對應(yīng)的文件系統(tǒng)都實現(xiàn)了 poll 接口，所以自然并不是所有的 fd 都可以放進 epoll 池，那么有哪些文件系統(tǒng)的 file_operations 實現(xiàn)了 poll 接口？

首先說，類似 ext2，ext4，xfs 這種常規(guī)的文件系統(tǒng)是沒有實現(xiàn)的，換句話說，這些你最常見的、真的是文件的文件系統(tǒng)反倒是用不了 epoll 機制的。

那誰支持呢？

最常見的就是網(wǎng)絡(luò)套接字：socket 。網(wǎng)絡(luò)也是 epoll 池最常見的應(yīng)用地點。Linux 下萬物皆文件，socket 實現(xiàn)了一套 socket_file_operations 的邏輯（ net/socket.c ）：

static const struct file_operations socket_file_ops = {

.read_iter = sock_read_iter，

.write_iter = sock_write_iter，

.poll = sock_poll，

// 。。。

};

我們看到 socket 實現(xiàn)了 poll 調(diào)用，所以 socket fd 是天然可以放到 epoll 池管理的。

還有支持的嗎？

有的，很多。其實 Linux 下還有兩個很典型的 fd ，常常也會放到 epoll 池里。

eventfd：eventfd 實現(xiàn)非常簡單，故名思義就是專門用來做事件通知用的。使用系統(tǒng)調(diào)用 eventfd 創(chuàng)建，這種文件 fd 無法傳輸數(shù)據(jù)，只用來傳輸事件，常常用于生產(chǎn)消費者模式的事件實現(xiàn)；

timerfd：這是一種定時器 fd，使用 timerfd_create 創(chuàng)建，到時間點觸發(fā)可讀事件；

小結(jié)一下：

ext2，ext4，xfs 等這種真正的文件系統(tǒng)的 fd ，無法使用 epoll 管理；

socket fd，eventfd，timerfd 這些實現(xiàn)了 poll 調(diào)用的可以放到 epoll 池進行管理；

其實，在 Linux 的模塊劃分中，eventfd，timerfd，epoll 池都是文件系統(tǒng)的一種模塊實現(xiàn)。

思考

前面我們已經(jīng)思考了很多知識點，有一些簡單有趣的知識點，提示給讀者朋友，這里只拋磚引玉。

問題：單核 CPU 能實現(xiàn)并行嗎？

不行。

問題：單線程能實現(xiàn)高并發(fā)嗎？

可以。

問題：那并發(fā)和并行的區(qū)別是？

一個看的是時間段內(nèi)的執(zhí)行情況，一個看的是時間時刻的執(zhí)行情況。

問題：單線程如何做到高并發(fā)？

IO 多路復(fù)用唄，今天講的 epoll 池就是了。

問題：單線程實現(xiàn)并發(fā)的有開源的例子嗎？

redis，nginx 都是非常好的學(xué)習(xí)例子。當(dāng)然還有我們 Golang 的 runtime 實現(xiàn)也盡顯高并發(fā)的設(shè)計思想。

總結(jié)

IO 多路復(fù)用的原始實現(xiàn)很簡單，就是一個 1 對多的服務(wù)模式，一個 loop 對應(yīng)處理多個 fd ；

IO 多路復(fù)用想要做到真正的高效，必須要內(nèi)核機制提供。因為 IO 的處理和完成是在內(nèi)核，如果內(nèi)核不幫忙，用戶態(tài)的程序根本無法精確的抓到處理時機；

fd 記得要設(shè)置成非阻塞的哦，切記；

epoll 池通過高效的內(nèi)部管理結(jié)構(gòu)，并且結(jié)合操作系統(tǒng)提供的 poll 事件注冊機制，實現(xiàn)了高效的 fd 事件管理，為高并發(fā)的 IO 處理提供了前提條件；

epoll 全名 eventpoll，在 Linux 內(nèi)核下以一個文件系統(tǒng)模塊的形式實現(xiàn)，所以有人常說 epoll 其實本身就是文件系統(tǒng)也是對的；

socketfd，eventfd，timerfd 這三種”文件“fd 實現(xiàn)了 poll 接口，所以網(wǎng)絡(luò) fd，事件fd，定時器fd 都可以使用 epoll_ctl 注冊到池子里。我們最常見的就是網(wǎng)絡(luò)fd的多路復(fù)用；

ext2，ext4，xfs 這種真正意義的文件系統(tǒng)反倒沒有提供 poll 接口實現(xiàn)，所以不能用 epoll 池來管理其句柄。那文件就無法使用 epoll 機制了嗎？不是的，有一個庫叫做 libaio ，通過這個庫我們可以間接的讓文件使用 epoll 通知事件，以后詳說，此處不表；

后記

epoll 池使用很簡潔，但實現(xiàn)不簡單。還是那句話，Linux 內(nèi)核幫你包圓了。今天并沒有羅列太多源碼實現(xiàn)，以很小的思考點為題展開，簡單講了一些 epoll 的思考。

編輯：jq