作者 |?京東云開發者-京東零售?石朝陽

在說 IO 多路復用模型之前，我們先來大致了解下 Linux 文件系統。在 Linux 系統中，不論是你的鼠標，鍵盤，還是打印機，甚至于連接到本機的 socket client 端，都是以文件描述符的形式存在于系統中，諸如此類，等等等等，所以可以這么說，一切皆文件。來看一下系統定義的文件描述符說明：

?? 從上面的列表可以看到，文件描述符 0,1,2 都已經被系統占用了，當系統啟動的時候，這三個描述符就存在了。其中 0 代表標準輸入，1 代表標準輸出，2 代表錯誤輸出。當我們創建新的文件描述符的時候，就會在 2 的基礎上進行遞增。可以這么說，文件描述符是為了管理被打開的文件而創建的系統索引，他代表了文件的身份 ID。對標 windows 的話，你可以認為和句柄類似，這樣就更容易理解一些。 由于網上對 linux 文件這塊的原理描述的文章已經非常多了，所以這里我不再做過多的贅述，感興趣的同學可以從 Wikipedia 翻閱一下。由于這塊內容比較復雜，不屬于本文普及的內容，建議讀者另行自研，這里我非常推薦馬士兵老師將 linux 文件系統這塊，講解的真的非常好。

select 模型

此模型是 IO 多路復用的最早期使用的模型之一，距今已經幾十年了，但是現在依舊有不少應用還在采用此種方式，可見其長生不老。首先來看下其具體的定義（來源于 man 二類文檔）：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *errorfds, struct timeval *timeout);

這里解釋下其具體參數：

參數一：nfds，也即 maxfd，最大的文件描述符遞增一。這里之所以傳最大描述符，為的就是在遍歷 fd_set 的時候，限定遍歷范圍。

參數二：readfds，可讀文件描述符集合。

參數三：writefds，可寫文件描述符集合。

參數四：errorfds，異常文件描述符集合。

參數五：timeout，超時時間。在這段時間內沒有檢測到描述符被觸發，則返回。

下面的宏處理，可以對 fd_set 集合（準確的說是 bitmap，一個描述符有變更，則會在描述符對應的索引處置 1）進行操作：

FD_CLR (inr fd,fd_set* set) 用來清除描述詞組 set 中相關 fd 的位，即 bitmap 結構中索引值為 fd 的值置為 0。

FD_ISSET (int fd,fd_set *set) 用來測試描述詞組 set 中相關 fd 的位是否為真，即 bitmap 結構中某一位是否為 1。

FD_SET（int fd,fd_set*set） 用來設置描述詞組 set 中相關 fd 的位，即將 bitmap 結構中某一位設置為 1，索引值為 fd。

FD_ZERO（fd_set *set） 用來清除描述詞組 set 的全部位，即將 bitmap 結構全部清零。

首先來看一段服務端采用了 select 模型的示例代碼：

//創建server端套接字，獲取文件描述符
    int listenfd = socket(PF_INET,SOCK_STREAM,0);
    if(listenfd < 0) return -1;
    //綁定服務器
    bind(listenfd,(struct sockaddr*)&address,sizeof(address));
    //監聽服務器
    listen(listenfd,5); 
    struct sockaddr_in client;
    socklen_t addr_len = sizeof(client);
    //接收客戶端連接
    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);
    //讀緩沖區
    char buff[1024]; 
    //讀文件操作符
    fd_set read_fds;  
    while(1)
    {
        memset(buff,0,sizeof(buff));
        //注意：每次調用select之前都要重新設置文件描述符connfd，因為文件描述符表會在內核中被修改
        FD_ZERO(&read_fds);
        FD_SET(connfd,&read_fds);
        //注意：select會將用戶態中的文件描述符表放到內核中進行修改，內核修改完畢后再返回給用戶態，開銷較大
        ret = select(connfd+1,&read_fds,NULL,NULL,NULL);
        if(ret < 0)
        {
            printf("Fail to select!
");
            return -1;
        }
        //檢測文件描述符表中相關請求是否可讀
        if(FD_ISSET(connfd, &read_fds))
        {
            ret = recv(connfd,buff,sizeof(buff)-1,0);
            printf("receive %d bytes from client: %s 
",ret,buff);
        }
    }

上面的代碼我加了比較詳細的注釋了，大家應該很容易看明白，說白了大概流程其實如下：

首先，創建 socket 套接字，創建完畢后，會獲取到此套接字的文件描述符。

然后，bind 到指定的地址進行監聽 listen。這樣，服務端就在特定的端口啟動起來并進行監聽了。

之后，利用開啟 accept 方法來監聽客戶端的連接請求。一旦有客戶端連接，則將獲取到當前客戶端連接的 connection 文件描述符。

雙方建立連接之后，就可以進行數據互傳了。需要注意的是，在循環開始的時候，務必每次都要重新設置當前 connection 的文件描述符，是因為文件描描述符表在內核中被修改過，如果不重置，將會導致異常的情況。

重新設置文件描述符后，就可以利用 select 函數從文件描述符表中，來輪詢哪些文件描述符就緒了。此時系統會將用戶態的文件描述符表發送到內核態進行調整，即將準備就緒的文件描述符進行置位，然后再發送給用戶態的應用中來。

用戶通過 FD_ISSET 方法來輪詢文件描述符，如果數據可讀，則讀取數據即可。

舉個例子，假設此時連接上來了 3 個客戶端，connection 的文件描述符分別為 4,8,12，那么其 read_fds 文件描述符表（bitmap 結構）的大致結構為 00010001000100000....0，由于 read_fds 文件描述符的長度為 1024 位，所以最多允許 1024 個連接。

而在 select 的時候，涉及到用戶態和內核態的轉換，所以整體轉換方式如下：

所以，綜合起來，select 整體還是比較高效和穩定的，但是呈現出來的問題也不少，這些問題進一步限制了其性能發揮：

文件描述符表為 bitmap 結構，且有長度為 1024 的限制。

fdset 無法做到重用，每次循環必須重新創建。

頻繁的用戶態和內核態拷貝，性能開銷較大。

需要對文件描述符表進行遍歷，O (n) 的輪詢時間復雜度。

poll 模型

考慮到 select 模型的幾個限制，后來進行了改進，這也就是 poll 模型，既然是 select 模型的改進版，那么肯定有其亮眼的地方，一起來看看吧。當然，這次我們依舊是先翻閱 linux man 二類文檔，因為這是官方的文檔，對其有著最為精準的定義。

int poll(struct pollfd *fds, nfds_t nfds, int timeout);

其實，從運行機制上說來，poll 所做的功能和 select 是基本上一樣的，都是等待并檢測一組文件描述符就緒，然后在進行后續的 IO 處理工作。只不過不同的是，select 中，采用的是 bitmap 結構，長度限定在 1024 位的文件描述符表，而 poll 模型則采用的是 pollfd 結構的數組 fds，也正是由于 poll 模型采用了數組結構，則不會有 1024 長度限制，使其能夠承受更高的并發。

pollfd 結構內容如下：

struct pollfd {
    int   fd;         /* 文件描述符 */
    short events;     /* 關心的事件 */
    short revents;    /* 實際返回的事件 */
};

從上面的結構可以看出，fd 很明顯就是指文件描述符，也就是當客戶端連接上來后，fd 會將生成的文件描述符保存到這里；而 events 則是指用戶想關注的事件；revents 則是指實際返回的事件，是由系統內核填充并返回，如果當前的 fd 文件描述符有狀態變化，則 revents 的值就會有相應的變化。

events 事件列表如下：

revents 事件列表如下：

從列表中可以看出，revents 是包含 events 的。接下來結合示例來看一下：

//創建server端套接字，獲取文件描述符
    int listenfd = socket(PF_INET,SOCK_STREAM,0);
    if(listenfd < 0) return -1;
    //綁定服務器
    bind(listenfd,(struct sockaddr*)&address,sizeof(address));
    //監聽服務器
    listen(listenfd,5); 
    struct pollfd pollfds[1];
    socklen_t addr_len = sizeof(client);
    //接收客戶端連接
    int connfd = accept(listenfd,(struct sockaddr*)&client,&addr_len);
    //放入fd數組
    pollfds[0].fd = connfd;
    pollfds[0].events = POLLIN;
    //讀緩沖區
    char buff[1024]; 
    //讀文件操作符
    fd_set read_fds;  
    while(1)
    {
        memset(buff,0,sizeof(buff));
        /**
         ** SELECT模型專用
         ** 注意：每次調用select之前都要重新設置文件描述符connfd，因為文件描述符表會在內核中被修改
         ** FD_ZERO(&read_fds);
         ** FD_SET(connfd,&read_fds);
        ** 注意：select會將用戶態中的文件描述符表放到內核中進行修改，內核修改完畢后再返回給用戶態，開銷較大
        ** ret = select(connfd+1,&read_fds,NULL,NULL,NULL);
        **/
        ret = poll(pollfds, 1, 1000);
        if(ret < 0)
        {
            printf("Fail to poll!
");
            return -1;
        }
        /**
         ** SELECT模型專用
         ** 檢測文件描述符表中相關請求是否可讀
         ** if(FD_ISSET(connfd, &read_fds))
         ** {
         **   ret = recv(connfd,buff,sizeof(buff)-1,0);
         **   printf("receive %d bytes from client: %s 
",ret,buff);
         ** }
         **/
        //檢測文件描述符數組中相關請求
        if(pollfds[0].revents & POLLIN){
            pollfds[0].revents = 0;
            ret = recv(connfd,buff,sizeof(buff)-1,0);
            printf("receive %d bytes from client: %s 
",ret,buff);
        }
    }

由于源碼中，我做了比較詳細的注釋，同時將和 select 模型不一樣的地方都列了出來，這里就不再詳細解釋了。總體說來，poll 模型比 select 模型要好用一些，去掉了一些限制，但是仍然避免不了如下的問題：

用戶態和內核態仍需要頻繁切換，因為 revents 的賦值是在內核態進行的，然后再推送到用戶態，和 select 類似，整體開銷較大。

仍需要遍歷數組，時間復雜度為 O（N）。

epoll 模型

如果說 select 模型和 poll 模型是早期的產物，在性能上有諸多不盡人意之處，那么自 linux 2.6 之后新增的 epoll 模型，則徹底解決了性能問題，一舉使得單機承受百萬并發的課題變得極為容易。現在可以這么說，只需要一些簡單的設置更改，然后配合上 epoll 的性能，實現單機百萬并發輕而易舉。同時，由于 epoll 整體的優化，使得之前的幾個比較耗費性能的問題不再成為羈絆，所以也成為了 linux 平臺上進行網絡通訊的首選模型。

講解之前，還是 linux man 文檔鎮樓：linux man epoll 4 類文檔 linux man epoll 7 類文檔，倆文檔結合著讀，會對 epoll 有個大概的了解。和之前提到的 select 和 poll 不同的是，此二者皆屬于系統調用函數，但是 epoll 則不然，他是存在于內核中的數據結構，可以通過 epoll_create，epoll_ctl 及 epoll_wait 三個函數結合來對此數據結構進行操控。

說道 epoll_create 函數，其作用是在內核中創建一個 epoll 數據結構實例，然后將返回此實例在系統中的文件描述符。此 epoll 數據結構的組成其實是一個鏈表結構，我們稱之為 interest list，里面會注冊連接上來的 client 的文件描述符。

其簡化工作機制如下：

說道 epoll_ctl 函數，其作用則是對 epoll 實例進行增刪改查操作。有些類似我們常用的 CRUD 操作。這個函數操作的對象其實就是 epoll 數據結構，當有新的 client 連接上來的時候，他會將此 client 注冊到 epoll 中的 interest list 中，此操作通過附加 EPOLL_CTL_ADD 標記來實現；當已有的 client 掉線或者主動下線的時候，他會將下線的 client 從 epoll 的 interest list 中移除，此操作通過附加 EPOLL_CTL_DEL 標記來實現；當有 client 的文件描述符有變更的時候，他會將 events 中的對應的文件描述符進行更新，此操作通過附加 EPOLL_CTL_MOD 來實現；當 interest list 中有 client 已經準備好了，可以進行 IO 操作的時候，他會將這些 clients 拿出來，然后放到一個新的 ready list 里面。

其簡化工作機制如下：

說道 epoll_wait 函數，其作用就是掃描 ready list，處理準備就緒的 client IO，其返回結果即為準備好進行 IO 的 client 的個數。通過遍歷這些準備好的 client，就可以輕松進行 IO 處理了。

上面這三個函數是 epoll 操作的基本函數，但是，想要徹底理解 epoll，則需要先了解這三塊內容，即：inode，鏈表，紅黑樹。

在 linux 內核中，針對當前打開的文件，有一個 open file table，里面記錄的是所有打開的文件描述符信息；同時也有一個 inode table，里面則記錄的是底層的文件描述符信息。這里假如文件描述符 B fork 了文件描述符 A，雖然在 open file table 中，我們看新增了一個文件描述符 B，但是實際上，在 inode table 中，A 和 B 的底層是一模一樣的。這里，將 inode table 中的內容理解為 windows 中的文件屬性，會更加貼切和易懂。這樣存儲的好處就是，無論上層文件描述符怎么變化，由于 epoll 監控的數據永遠是 inode table 的底層數據，那么我就可以一直能夠監控到文件的各種變化信息，這也是 epoll 高效的基礎。更多詳細信息，請參閱這兩篇文章：Nonblocking IO & The method to epoll's madness.

簡化流程如下：

數據存儲這塊解決了，那么針對連接上來的客戶端 socket，該用什么數據結構保存進來呢？這里用到了紅黑樹，由于客戶端 socket 會有頻繁的新增和刪除操作，而紅黑樹這塊時間復雜度僅僅為 O (logN)，還是挺高效的。有人會問為啥不用哈希表呢？當大量的連接頻繁的進行接入或者斷開的時候，擴容或者其他行為將會產生不少的 rehash 操作，而且還要考慮哈希沖突的情況。雖然查詢速度的確可以達到 o (1)，但是 rehash 或者哈希沖突是不可控的，所以基于這些考量，我認為紅黑樹占優一些。

客戶端 socket 怎么管理這塊解決了，接下來，當有 socket 有數據需要進行讀寫事件處理的時候，系統會將已經就緒的 socket 添加到雙向鏈表中，然后通過 epoll_wait 方法檢測的時候，其實檢查的就是這個雙向鏈表，由于鏈表中都是就緒的數據，所以避免了針對整個客戶端 socket 列表進行遍歷的情況，使得整體效率大大提升。整體的操作流程為：

首先，利用 epoll_create 在內核中創建一個 epoll 對象。其實這個 epoll 對象，就是一個可以存儲客戶端連接的數據結構。

然后，客戶端 socket 連接上來，會通過 epoll_ctl 操作將結果添加到 epoll 對象的紅黑樹數據結構中。

然后，一旦有 socket 有事件發生，則會通過回調函數將其添加到 ready list 雙向鏈表中。

最后，epoll_wait 會遍歷鏈表來處理已經準備好的 socket，然后通過預先設置的水平觸發或者邊緣觸發來進行數據的感知操作。

從上面的細節可以看出，由于 epoll 內部監控的是底層的文件描述符信息，可以將變更的描述符直接加入到 ready list，無需用戶將所有的描述符再進行傳入。同時由于 epoll_wait 掃描的是已經就緒的文件描述符，避免了很多無效的遍歷查詢，使得 epoll 的整體性能大大提升，可以說現在只要談論 linux 平臺的 IO 多路復用，epoll 已經成為了不二之選。

水平觸發和邊緣觸發

上面說到了 epoll，主要講解了 client 端怎么連進來，但是并未詳細的講解 epoll_wait 怎么被喚醒的，這里我將來詳細的講解一下。

水平觸發，意即 Level Trigger，邊緣觸發，意即 Edge Trigger，如果單從字面意思上理解，則不太容易，但是如果將硬件設計中的水平沿，上升沿，下降沿的概念引進來，則理解起來就容易多了。比如我們可以這樣認為：

如果將上圖中的方塊看做是 buffer 的話，那么理解起來則就更加容易了，比如針對水平觸發，buffer 只要是一直有數據，則一直通知；而邊緣觸發，則 buffer 容量發生變化的時候，才會通知。雖然可以這樣簡單的理解，但是實際上，其細節處理部分，比圖示中展現的更加精細，這里來詳細的說一下。

邊緣觸發

針對讀操作，也就是當前 fd 處于 EPOLLIN 模式下，即可讀。此時意味著有新的數據到來，接收緩沖區可讀，以下 buffer 都指接收緩沖區：

buffer 由空變為非空，意即有數據進來的時候，此過程會觸發通知。

buffer 原本有些數據，這時候又有新數據進來的時候，數據變多，此過程會觸發通知。

buffer 中有數據，此時用戶對操作的 fd 注冊 EPOLL_CTL_MOD 事件的時候，會觸發通知。

針對寫操作，也就是當前 fd 處于 EPOLLOUT 模式下，即可寫。此時意味著緩沖區可以寫了，以下 buffer 都指發送緩沖區：

buffer 滿了，這時候發送出去一些數據，數據變少，此過程會觸發通知。

buffer 原本有些數據，這時候又發送出去一些數據，數據變少，此過程會觸發通知。

這里就是 ET 這種模式觸發的幾種情形，可以看出，基本上都是圍繞著接收緩沖區或者發送緩沖區的狀態變化來進行的。

晦澀難懂？不存在的，舉個栗子：

在服務端，我們開啟邊緣觸發模式，然后將 buffer size 設為 10 個字節，來看看具體的表現形式。

服務端開啟，客戶端連接，發送單字符 A 到服務端，輸出結果如下：

-->ET Mode: it was triggered once

get 1 bytes of content: A

-->wait to read!

可以看到，由于 buffer 從空到非空，邊緣觸發通知產生，之后在 epoll_wait 處阻塞，繼續等待后續事件。

這里我們變一下，輸入 ABCDEFGHIJKLMNOPQ，可以看到，客戶端發送的字符長度超過了服務端 buffer size，那么輸出結果將是怎么樣的呢？

-->ET Mode: it was triggered once

get 9 bytes of content: ABCDEFGHI

get 8 bytes of content: JKLMNOPQ

-->wait to read!

可以看到，這次發送，由于發送的長度大于 buffer size，所以內容被折成兩段進行接收，由于用了邊緣觸發方式，buffer 的情況是從空到非空，所以只會產生一次通知。

水平觸發

水平觸發則簡單多了，他包含了邊緣觸發的所有場景，簡而言之如下：

當接收緩沖區不為空的時候，有數據可讀，則讀事件會一直觸發。

當發送緩沖區未滿的時候，可以繼續寫入數據，則寫事件一直會觸發。

同樣的，為了使表達更清晰，我們也來舉個栗子，按照上述入輸入方式來進行。

服務端開啟，客戶端連接并發送單字符 A，可以看到服務端輸出情況如下：

-->LT Mode: it was triggered once!

get 1 bytes of content: A

這個輸出結果，毋庸置疑，由于 buffer 中有數據，所以水平模式觸發，輸出了結果。

服務端開啟，客戶端連接并發送 ABCDEFGHIJKLMNOPQ，可以看到服務端輸出情況如下：

-->LT Mode: it was triggered once!

get 9 bytes of content: ABCDEFGHI

-->LT Mode: it was triggered once!

get 8 bytes of content: JKLMNOPQ

從結果中，可以看出，由于 buffer 中數據讀取完畢后，還有未讀完的數據，所以水平模式會一直觸發，這也是為啥這里水平模式被觸發了兩次的原因。

有了這兩個栗子的比對，不知道聰明的你，get 到二者的區別了嗎？

在實際開發過程中，實際上 LT 更易用一些，畢竟系統幫助我們做了大部分校驗通知工作，之前提到的 SELECT 和 POLL，默認采用的也都是這個。但是需要注意的是，當有成千上萬個客戶端連接上來開始進行數據發送，由于 LT 的特性，內核會頻繁的處理通知操作，導致其相對于 ET 來說，比較的耗費系統資源，所以，隨著客戶端的增多，其性能也就越差。

而邊緣觸發，由于監控的是 FD 的狀態變化，所以整體的系統通知并沒有那么頻繁，高并發下整體的性能表現也要好很多。但是由于此模式下，用戶需要積極的處理好每一筆數據，帶來的維護代價也是相當大的，稍微不注意就有可能出錯。所以使用起來須要非常小心才行。

至于二者如何抉擇，諸位就仁者見仁智者見智吧。

行文到這里，關于 epoll 的講解基本上完畢了，大家從中是不是學到了很多干貨呢？由于從 netty 研究到 linux epoll 底層，其難度非常大，可以用曲高和寡來形容，所以在這塊探索的文章是比較少的，很多東西需要自己照著 man 文檔和源碼一點一點的琢磨（linux 源碼詳見 eventpoll.c 等）。這里我來糾正一下搜索引擎上，說 epoll 高性能是因為利用 mmap 技術實現了用戶態和內核態的內存共享，所以性能好，我前期被這個觀點誤導了好久，后來下來了 linux 源碼，翻了一下，并沒有在 epoll 中翻到 mmap 的技術點，所以這個觀點是錯誤的。這些錯誤觀點的文章，國內不少，國外也不少，希望大家能審慎抉擇，避免被錯誤帶偏。

所以，epoll 高性能的根本就是，其高效的文件描述符處理方式加上頗具特性邊的緣觸發處理模式，以極少的內核態和用戶態的切換，實現了真正意義上的高并發。

編輯：黃飛

?