內核視角看Epoll LT/ET：數據結構與回調機制全解

作者：往日敬秋風 2025-07-15 09:58:16

讓我們一同踏入內核的奇妙世界，抽絲剝繭，深入探究 Epoll LT 和 ET 模式下的數據結構精妙設計與回調機制的運作邏輯，解鎖 Epoll 高效性能背后的神秘密碼。

在Linux網絡編程領域，Epoll 堪稱一顆璀璨明星，憑借其卓越性能，在高并發場景中大放異彩。想深度洞察 Epoll 的高效運作奧秘，從內核視角剖析其數據結構與回調機制是不二之選。Epoll 有水平觸發（LT）和邊緣觸發（ET）兩種模式，二者在事件通知時機與處理方式上大相徑庭，這也使得它們適用于不同的應用場景。而內核中的數據結構，如紅黑樹、就緒鏈表等，宛如精密齒輪，協同運作，支撐著 Epoll 精準且高效地管理大量文件描述符。

同時，回調機制則如同靈動紐帶，將內核與用戶空間緊密相連，確保事件能夠及時、準確地傳遞，讓應用程序迅速做出響應。接下來，讓我們一同踏入內核的奇妙世界，抽絲剝繭，深入探究 Epoll LT 和 ET 模式下的數據結構精妙設計與回調機制的運作邏輯，解鎖 Epoll 高效性能背后的神秘密碼。

Part1Epoll核心工作原理

1.1 Epoll 是什么

Epoll是Linux下多路復用IO接口select/poll的增強版本，誕生于 Linux 2.6 內核。它能顯著提高程序在大量并發連接中只有少量活躍的情況下的系統 CPU 利用率。在傳統的 select/poll 模型中，當需要處理大量的文件描述符時，每次調用都需要線性掃描全部的集合，導致效率隨著文件描述符數量的增加而呈現線性下降。

而 Epoll 采用了事件驅動機制，內核會將活躍的文件描述符主動通知給應用程序，應用程序只需處理這些活躍的文件描述符即可，大大減少了無效的掃描操作。這就好比在一個大型圖書館中，select/poll 需要逐本書籍去查找是否有讀者需要借閱，而 Epoll 則是當有讀者需要借閱某本書時，圖書館管理員主動將這本書找出來交給讀者，效率高下立判。

在 I/O 多路復用機制中，select 和 poll 是 epoll 的 “前輩”，但它們存在一些明顯的不足，而 epoll 正是為克服這些不足而出現的。

select 是最早被廣泛使用的 I/O 多路復用函數，它允許一個進程監視多個文件描述符。然而，select 存在一個硬傷，即單個進程可監視的文件描述符數量被限制在 FD_SETSIZE（通常為 1024），這在高并發場景下遠遠不夠。例如，一個大型的在線游戲服務器，可能需要同時處理成千上萬的玩家連接，select 的這個限制就成為了性能瓶頸。此外，select 每次調用時，都需要將所有文件描述符從用戶空間拷貝到內核空間，檢查完后再拷貝回用戶空間，并且返回后需要通過遍歷 fd_set 來找到就緒的文件描述符，時間復雜度為 O (n)。當文件描述符數量較多時，這種無差別輪詢會導致效率急劇下降，大量的 CPU 時間浪費在遍歷操作上。

poll 在一定程度上改進了 select 的不足，它沒有了文件描述符數量的硬限制，使用 pollfd 結構體數組來表示文件描述符集合，并且將監聽事件和返回事件分開，簡化了編程操作。但 poll 本質上和 select 沒有太大差別，它同樣需要將用戶傳入的數組拷貝到內核空間，然后查詢每個 fd 對應的設備狀態。在處理大量文件描述符時，poll 每次調用仍需遍歷整個文件描述符數組，時間復雜度依然為 O (n)，隨著文件描述符數量的增加，性能也會顯著下降。而且，poll 在用戶態與內核態之間的數據拷貝開銷也不容忽視。

epoll 則在設計上有了質的飛躍。它沒有文件描述符數量的上限，能輕松處理成千上萬的并發連接，這使得它非常適合高并發的網絡應用場景。epoll 采用事件驅動模式，通過 epoll_ctl 函數將文件描述符和感興趣的事件注冊到內核的事件表中，內核使用紅黑樹來管理這些文件描述符，保證了插入、刪除和查找的高效性。當有事件發生時，內核會將就緒的文件描述符加入到就緒鏈表中，應用程序通過 epoll_wait 函數獲取這些就緒的文件描述符，只需處理有狀態變化的文件描述符即可，避免了遍歷所有文件描述符的開銷，時間復雜度為 O (1)。這種高效的機制使得 epoll 在高并發情況下能夠保持良好的性能，大大提升了系統的吞吐量和響應速度。

1.2 Epoll 的核心接口

Epoll 提供了三個核心接口，它們是 Epoll 機制的關鍵所在，就像三把鑰匙，開啟了高效 I/O 處理的大門。下面我們詳細介紹這三個系統調用的功能、參數和返回值，并結合代碼示例展示它們的使用方法。

(1)epoll_create

#include <sys/epoll.h>
int epoll_create(int size);
int epoll_create1(int flags);

epoll_create用于創建一個 epoll 實例，返回一個文件描述符，后續對 epoll 的操作都將通過這個文件描述符進行。在 Linux 2.6.8 之后，size參數被忽略，但仍需傳入一個大于 0 的值。epoll_create1是epoll_create的增強版本，flags參數可以設置為 0，功能與epoll_create相同；也可以設置為EPOLL_CLOEXEC，表示在執行exec系列函數時自動關閉該文件描述符。

例如：

int epfd = epoll_create1(0);
if (epfd == -1) {
    perror("epoll_create1");
    return 1;
}

上述代碼創建了一個 epoll 實例，并檢查創建是否成功。如果返回值為 - 1，說明創建失敗，通過perror打印錯誤信息。

(2)epoll_ctl

#include <sys/epoll.h>
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

epoll_ctl用于控制 epoll 實例，對指定的文件描述符fd執行操作op。epfd是epoll_create返回的 epoll 實例文件描述符；op有三個取值：EPOLL_CTL_ADD表示將文件描述符fd添加到 epoll 實例中，并監聽event指定的事件；EPOLL_CTL_MOD用于修改已添加的文件描述符fd的監聽事件；EPOLL_CTL_DEL則是將文件描述符fd從 epoll 實例中刪除，此時event參數可以為 NULL。

event是一個指向epoll_event結構體的指針，該結構體定義如下：

typedef union epoll_data {
    void        *ptr;
    int          fd;
    uint32_t     u32;
    uint64_t     u64;
} epoll_data_t;

struct epoll_event {
    uint32_t     events;      /* Epoll events */
    epoll_data_t data;        /* User data variable */
};

events字段表示要監聽的事件類型，常見的有EPOLLIN（表示對應的文件描述符可以讀）、EPOLLOUT（表示對應的文件描述符可以寫）、EPOLLRDHUP（表示套接字的一端已經關閉，或者半關閉）、EPOLLERR（表示對應的文件描述符發生錯誤）、EPOLLHUP（表示對應的文件描述符被掛起）等。data字段是一個聯合體，可用于存儲用戶自定義的數據，通常會將fd存儲在這里，以便在事件觸發時識別是哪個文件描述符。

例如，將標準輸入（STDIN_FILENO）添加到 epoll 實例中，監聽可讀事件：

struct epoll_event event;
event.events = EPOLLIN;
event.data.fd = STDIN_FILENO;
if (epoll_ctl(epfd, EPOLL_CTL_ADD, STDIN_FILENO, &event) == -1) {
    perror("epoll_ctl");
    close(epfd);
    return 1;
}

上述代碼將標準輸入的文件描述符添加到 epoll 實例中，監聽可讀事件EPOLLIN。如果epoll_ctl調用失敗，打印錯誤信息并關閉 epoll 實例。

(3)epoll_wait

#include <sys/epoll.h>
int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll_wait用于等待 epoll 實例上的事件發生。epfd是 epoll 實例的文件描述符；events是一個指向epoll_event結構體數組的指針，用于存儲發生的事件；maxevents表示events數組最多能容納的事件數量；timeout是超時時間，單位為毫秒。如果timeout為 - 1，表示無限期等待，直到有事件發生；如果為 0，則立即返回，不等待任何事件；如果為正數，則等待指定的毫秒數，超時后返回。

返回值為發生的事件數量，如果返回 0 表示超時且沒有事件發生；如果返回 - 1，表示發生錯誤，可通過errno獲取具體錯誤信息。

例如：

struct epoll_event events[10];
int nfds = epoll_wait(epfd, events, 10, -1);
if (nfds == -1) {
    perror("epoll_wait");
    close(epfd);
    return 1;
}
for (int i = 0; i < nfds; i++) {
    if (events[i].data.fd == STDIN_FILENO) {
        char buffer[1024];
        ssize_t count = read(STDIN_FILENO, buffer, sizeof(buffer));
        if (count == -1) {
            perror("read");
            return 1;
        }
        printf("Read %zd bytes\n", count);
    }
}

上述代碼使用epoll_wait等待 epoll 實例上的事件發生，最多等待 10 個事件，無限期等待。當有事件發生時，遍歷events數組，檢查是否是標準輸入的可讀事件。如果是，讀取標準輸入的數據并打印讀取的字節數。

通過這三個系統調用，我們可以創建 epoll 實例，注冊文件描述符及其感興趣的事件，然后等待事件發生并處理，實現高效的 I/O 多路復用。

1.3 Epoll 的底層數據結構

epoll之所以性能卓越，離不開其精心設計的數據結構。epoll主要依賴紅黑樹和雙向鏈表這兩種數據結構來實現高效的事件管理，再配合三個核心API，讓它在處理大量并發連接時游刃有余。

epoll工作在應用程序和內核協議棧之間。
epoll是在內核協議棧和vfs都有的情況下才有的。

epoll 的核心數據結構是：1個紅黑樹和1個雙向鏈表。還有3個核心API。

可以看到，鏈表和紅黑樹使用的是同一個結點。實際上是紅黑樹管理所有的IO，當內部IO就緒的時候就會調用epoll的回調函數，將相應的IO添加到就緒鏈表上。數據結構有epitm和eventpoll，分別代表紅黑樹和單個結點，在單個結點上分別使用rbn和rblink使得結點同時指向兩個數據結構。

(1)紅黑樹的巧妙運用

epoll 使用紅黑樹來管理所有注冊的文件描述符。紅黑樹是一種自平衡的二叉搜索樹，它有著非常優秀的性質：每個節點要么是紅色，要么是黑色；根節點是黑色；所有葉子節點（通常是 NULL 節點）是黑色；如果一個節點是紅色，那么它的兩個子節點都是黑色；從任一節點到其每個葉子的所有路徑都包含相同數目的黑色節點。這些性質保證了紅黑樹的高度近似平衡，使得查找、插入和刪除操作的時間復雜度都穩定在 O (log n)，這里的 n 是紅黑樹中節點的數量。

因為鏈表在查詢，刪除的時候毫無疑問時間復雜度是O(n)；
數組查詢很快，但是刪除和新增時間復雜度是O(n)；
二叉搜索樹雖然查詢效率是lgn，但是如果不是平衡的，那么就會退化為線性查找，復雜度直接來到O(n)；
B+樹是平衡多路查找樹，主要是通過降低樹的高度來存儲上億級別的數據，但是它的應用場景是內存放不下的時候能夠用最少的IO訪問次數從磁盤獲取數據。比如數據庫聚簇索引，成百上千萬的數據內存無法滿足查找就需要到內存查找，而因為B+樹層高很低，只需要幾次磁盤IO就能獲取數據到內存，所以在這種磁盤到內存訪問上B+樹更適合。

因為我們處理上萬級的fd，它們本身的存儲空間并不會很大，所以傾向于在內存中去實現管理，而紅黑樹是一種非常優秀的平衡樹，它完全是在內存中操作，而且查找，刪除和新增時間復雜度都是lgn，效率非常高，因此選擇用紅黑樹實現epoll是最佳的選擇。

當然不選擇用AVL樹是因為紅黑樹是不符合AVL樹的平衡條件的，紅黑樹用非嚴格的平衡來換取增刪節點時候旋轉次數的降低，任何不平衡都會在三次旋轉之內解決；而AVL樹是嚴格平衡樹，在增加或者刪除節點的時候，根據不同情況，旋轉的次數比紅黑樹要多。所以紅黑樹的插入效率更高。

我們來具體分析一下。假如我們有一個服務器，需要監聽 1000 個客戶端的連接，每個連接對應一個文件描述符。如果使用普通的鏈表來管理這些文件描述符，當我們要查找某個特定的文件描述符時，最壞情況下需要遍歷整個鏈表，時間復雜度是 O (n)，也就是需要 1000 次比較操作。但如果使用紅黑樹，由于其平衡特性，即使在最壞情況下，查找一個文件描述符也只需要 O (log n) 次比較操作，對于 1000 個節點的紅黑樹，log?1000 約等于 10 次左右，相比鏈表效率大大提高。同樣，在插入新的文件描述符（比如有新的客戶端連接）和刪除文件描述符（比如客戶端斷開連接）時，紅黑樹的 O (log n) 時間復雜度也比鏈表的 O (n) 高效得多。

再對比一下其他數據結構。數組雖然查詢效率高，時間復雜度為 O (1)，但插入和刪除操作比較麻煩，平均時間復雜度為 O (n) 。二叉搜索樹在理想情況下查找、插入和刪除的時間復雜度是 O (log n)，但如果樹的平衡性被破壞，比如節點插入順序不當，就可能退化為鏈表，時間復雜度變成 O (n)。

B + 樹主要用于磁盤存儲，適合處理大量數據且需要頻繁磁盤 I/O 的場景，在內存中管理文件描述符不如紅黑樹高效。所以，綜合考慮，紅黑樹是 epoll 管理大量文件描述符的最佳選擇，它能夠快速地定位和操作文件描述符，大大提高了 epoll 的性能。

(2)就緒socket列表-雙向鏈表

除了紅黑樹，epoll 還使用雙向鏈表來存儲就緒的 socket。當某個文件描述符上有事件發生（比如有數據可讀、可寫），對應的 socket 就會被加入到這個雙向鏈表中。雙向鏈表的優勢在于它可以快速地插入和刪除節點，時間復雜度都是 O (1) 。這對于 epoll 來說非常重要，因為在高并發場景下，就緒的 socket 可能隨時增加或減少。

就緒列表存儲的是就緒的socket，所以它應能夠快速的插入數據；程序可能隨時調用epoll_ctl添加監視socket，也可能隨時刪除。當刪除時，若該socket已經存放在就緒列表中，它也應該被移除。（事實上，每個epoll_item既是紅黑樹節點，也是鏈表節點，刪除紅黑樹節點，自然刪除了鏈表節點）所以就緒列表應是一種能夠快速插入和刪除的數據結構。雙向鏈表就是這樣一種數據結構，epoll使用雙向鏈表來實現就緒隊列（rdllist）。

想象一下，在一個繁忙的在線游戲服務器中，同時有大量玩家在線。每個玩家的連接都由一個 socket 表示，當某個玩家發送了操作指令（比如移動、攻擊等），對應的 socket 就有數據可讀，需要被加入到就緒列表中等待服務器處理。如果使用單向鏈表，插入節點時雖然也能實現，但刪除節點時，由于單向鏈表只能從前往后遍歷，找到要刪除節點的前驅節點比較麻煩，時間復雜度會達到 O (n) 。而雙向鏈表每個節點都有指向前驅和后繼節點的指針，無論是插入還是刪除節點，都可以在 O (1) 時間內完成。當服務器處理完某個 socket 的事件后，如果該 socket 不再有就緒事件，就可以快速地從雙向鏈表中刪除，不會影響其他節點的操作。

雙向鏈表和紅黑樹在 epoll 中協同工作。紅黑樹負責管理所有注冊的文件描述符，保證文件描述符的增刪查操作高效進行；而雙向鏈表則專注于存儲就緒的 socket，讓應用程序能夠快速獲取到有事件發生的 socket 并進行處理。當一個 socket 的事件發生時，epoll 會先在紅黑樹中找到對應的節點，然后將其加入到雙向鏈表中。這樣，epoll_wait 函數只需要遍歷雙向鏈表，就能獲取到所有就緒的 socket，避免了對大量未就緒 socket 的無效遍歷，大大提高了事件處理的效率。

(3)紅黑樹和就緒隊列的關系

紅黑樹的結點和就緒隊列的結點的同一個節點，所謂的加入就緒隊列，就是將結點的前后指針聯系到一起。所以就緒了不是將紅黑樹結點delete掉然后加入隊列。他們是同一個結點，不需要delete。

struct epitem {
RB_ ENTRY(epitem) rbn;
LIST_ ENTRY(epitem) rdlink;
int rdy; //exist in List
int sockfd;
struct epoll_ event event ;
};
struct eventpoll {
ep_ _rb_ tree rbr;
int rbcnt ;
LIST_ HEAD( ,epitem) rdlist;
int rdnum;
int waiting;
pthread_ mutex_ t mtx; //rbtree update
pthread_ spinlock_ t 1ock; //rdList update
pthread_ cond_ _t cond; //bLock for event
pthread_ mutex_ t cdmtx; //mutex for cond
};|

Epoll 還利用了mmap機制來減少內核態和用戶態之間的數據拷貝。在傳統的I/O模型中，內核將數據從內核緩沖區拷貝到用戶緩沖區時，需要進行兩次數據拷貝，而Epoll通過mmap將內核空間和用戶空間的一塊內存映射到相同的物理地址，使得內核可以直接將數據寫入用戶空間的內存，減少了一次數據拷貝，提高了數據傳輸的效率。

Part2LT與ET模式詳解

2.1 LT（水平觸發）模式

(1)觸發原理：LT 模式就像是一個勤勞且執著的快遞小哥，當被監控的文件描述符上有可讀寫事件發生時，epoll_wait 就會像收到通知的小哥一樣，立刻通知處理程序去讀寫。而且，如果一次沒處理完，下次調用 epoll_wait 它還會繼續通知，就如同小哥發現你沒取走快遞，會反復提醒你一樣。這是因為在 LT 模式下，只要文件描述符對應的緩沖區中還有未處理的數據，或者緩沖區還有可寫入的空間，對應的事件就會一直被觸發。

(2)實際表現：以網絡通信中的數據接收為例，當一個 socket 接收到數據時，內核會將數據放入接收緩沖區。在 LT 模式下，只要接收緩沖區中有數據，每次調用 epoll_wait 都會返回該 socket 的可讀事件，通知應用程序去讀取數據。哪怕應用程序只讀取了部分數據，下次 epoll_wait 依然會返回該 socket 的可讀事件，直到接收緩沖區中的數據被全部讀完。下面是一段簡單的代碼示例，展示了 LT 模式下數據讀取的過程：

#include <sys/epoll.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define MAX_EVENTS 10
#define BUFFER_SIZE 1024

int main() {
    int sockfd, epfd, nfds;
    struct sockaddr_in servaddr, cliaddr;
    socklen_t clilen = sizeof(cliaddr);
    char buffer[BUFFER_SIZE];

    // 創建socket
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }

    // 初始化服務器地址
    memset(&servaddr, 0, sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    servaddr.sin_port = htons(8888);

    // 綁定socket
    if (bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1) {
        perror("bind");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    // 監聽socket
    if (listen(sockfd, 5) == -1) {
        perror("listen");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    // 創建epoll實例
    epfd = epoll_create1(0);
    if (epfd == -1) {
        perror("epoll_create1");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    // 將監聽socket添加到epoll實例中
    struct epoll_event event;
    event.events = EPOLLIN;
    event.data.fd = sockfd;
    if (epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &event) == -1) {
        perror("epoll_ctl: add listen socket");
        close(sockfd);
        close(epfd);
        exit(EXIT_FAILURE);
    }

    struct epoll_event events[MAX_EVENTS];
    while (1) {
        // 等待事件發生
        nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);
        if (nfds == -1) {
            perror("epoll_wait");
            break;
        }

        for (int i = 0; i < nfds; ++i) {
            if (events[i].data.fd == sockfd) {
                // 處理新連接
                int connfd = accept(sockfd, (struct sockaddr *)&cliaddr, &clilen);
                if (connfd == -1) {
                    perror("accept");
                    continue;
                }

                // 將新連接的socket添加到epoll實例中
                event.events = EPOLLIN;
                event.data.fd = connfd;
                if (epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &event) == -1) {
                    perror("epoll_ctl: add conn socket");
                    close(connfd);
                }
            } else {
                // 處理已連接socket的讀事件
                int connfd = events[i].data.fd;
                int n = recv(connfd, buffer, sizeof(buffer) - 1, 0);
                if (n == -1) {
                    perror("recv");
                    close(connfd);
                    epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
                } else if (n == 0) {
                    // 對端關閉連接
                    close(connfd);
                    epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
                } else {
                    buffer[n] = '\0';
                    printf("Received: %s\n", buffer);
                }
            }
        }
    }

    close(sockfd);
    close(epfd);
    return 0;
}

在這段代碼中，當有新的連接到來時，將新連接的 socket 添加到 epoll 實例中。對于已連接的 socket，在 LT 模式下，只要有數據可讀，recv 函數就會被調用讀取數據，即使一次沒有讀完，下次 epoll_wait 依然會觸發可讀事件。

2.2 ET（邊緣觸發）模式

(1)觸發原理：ET 模式則像是一個 “高冷” 的快遞小哥，只有當被監控的文件描述符上的事件狀態發生變化，即從無到有時才會觸發通知，而且只通知一次。在 ET 模式下，對于讀事件，只有當 socket 的接收緩沖區由空變為非空時才會觸發；對于寫事件，只有當 socket 的發送緩沖區由滿變為非滿時才會觸發。這就要求應用程序在接收到 ET 模式的通知后，必須盡可能地一次性處理完所有相關數據，因為后續不會再收到重復的通知。

(2)實際表現：在實際應用中，ET 模式下的數據讀取需要特別注意。由于只通知一次，所以通常需要循環讀取數據，直到返回 EAGAIN 錯誤，表示緩沖區中已經沒有數據可讀了。以 socket 接收數據為例，代碼示例如下：

#include <sys/epoll.h>
#include <sys/socket.h>
#include <arpa/inet.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fcntl.h>

#define MAX_EVENTS 10
#define BUFFER_SIZE 1024

// 設置文件描述符為非阻塞模式
void setnonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags == -1) {
        perror("fcntl F_GETFL");
        return;
    }
    if (fcntl(fd, F_SETFL, flags | O_NONBLOCK) == -1) {
        perror("fcntl F_SETFL");
    }
}

int main() {
    int sockfd, epfd, nfds;
    struct sockaddr_in servaddr, cliaddr;
    socklen_t clilen = sizeof(cliaddr);
    char buffer[BUFFER_SIZE];

    // 創建socket
    sockfd = socket(AF_INET, SOCK_STREAM, 0);
    if (sockfd == -1) {
        perror("socket");
        exit(EXIT_FAILURE);
    }

    // 初始化服務器地址
    memset(&servaddr, 0, sizeof(servaddr));
    servaddr.sin_family = AF_INET;
    servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
    servaddr.sin_port = htons(8888);

    // 綁定socket
    if (bind(sockfd, (struct sockaddr *)&servaddr, sizeof(servaddr)) == -1) {
        perror("bind");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    // 監聽socket
    if (listen(sockfd, 5) == -1) {
        perror("listen");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    // 創建epoll實例
    epfd = epoll_create1(0);
    if (epfd == -1) {
        perror("epoll_create1");
        close(sockfd);
        exit(EXIT_FAILURE);
    }

    // 將監聽socket添加到epoll實例中
    struct epoll_event event;
    event.events = EPOLLIN;
    event.data.fd = sockfd;
    if (epoll_ctl(epfd, EPOLL_CTL_ADD, sockfd, &event) == -1) {
        perror("epoll_ctl: add listen socket");
        close(sockfd);
        close(epfd);
        exit(EXIT_FAILURE);
    }

    struct epoll_event events[MAX_EVENTS];
    while (1) {
        // 等待事件發生
        nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);
        if (nfds == -1) {
            perror("epoll_wait");
            break;
        }

        for (int i = 0; i < nfds; ++i) {
            if (events[i].data.fd == sockfd) {
                // 處理新連接
                int connfd = accept(sockfd, (struct sockaddr *)&cliaddr, &clilen);
                if (connfd == -1) {
                    perror("accept");
                    continue;
                }

                // 設置新連接的socket為非阻塞模式
                setnonblocking(connfd);

                // 將新連接的socket添加到epoll實例中，使用ET模式
                event.events = EPOLLIN | EPOLLET;
                event.data.fd = connfd;
                if (epoll_ctl(epfd, EPOLL_CTL_ADD, connfd, &event) == -1) {
                    perror("epoll_ctl: add conn socket");
                    close(connfd);
                }
            } else {
                // 處理已連接socket的讀事件
                int connfd = events[i].data.fd;
                while (1) {
                    int n = recv(connfd, buffer, sizeof(buffer) - 1, 0);
                    if (n == -1) {
                        if (errno == EAGAIN || errno == EWOULDBLOCK) {
                            // 沒有數據可讀，退出循環
                            break;
                        } else {
                            perror("recv");
                            close(connfd);
                            epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
                            break;
                        }
                    } else if (n == 0) {
                        // 對端關閉連接
                        close(connfd);
                        epoll_ctl(epfd, EPOLL_CTL_DEL, connfd, NULL);
                        break;
                    } else {
                        buffer[n] = '\0';
                        printf("Received: %s\n", buffer);
                    }
                }
            }
        }
    }

    close(sockfd);
    close(epfd);
    return 0;
}

在這個示例中，首先將新連接的 socket 設置為非阻塞模式，然后以 ET 模式添加到 epoll 實例中。在處理讀事件時，通過循環調用 recv 函數，直到返回 EAGAIN 錯誤，確保將緩沖區中的數據全部讀取出來。

2.3 LT 與 ET 的對比

觸發次數：從觸發次數上看，LT 模式會多次觸發事件，直到相關緩沖區中的數據處理完畢或者可寫空間被充分利用；而 ET 模式僅在事件狀態發生變化時觸發一次，后續不會再因相同事件而觸發。這就像兩個快遞小哥，一個會反復通知你取快遞，直到你取走；另一個只通知你一次，取不取隨你。
數據處理方式：在數據處理方式上，LT 模式相對簡單，應用程序可以根據自己的節奏逐步處理數據，每次 epoll_wait 返回后處理一部分數據即可；而 ET 模式要求應用程序更加 “激進”，一旦接收到事件通知，就需要盡可能一次性將緩沖區中的數據全部處理完，否則可能會丟失數據。例如，在處理大量網絡數據包時，LT 模式可以每次讀取少量數據，慢慢處理；而 ET 模式則需要在一次事件通知中讀取完所有到達的數據包。
效率：從效率角度來說，ET 模式在處理大量并發連接且每個連接數據量較小的場景下具有更高的效率，因為它減少了不必要的事件觸發，降低了系統開銷；而 LT 模式雖然在某些情況下可能會產生一些冗余的觸發，但它的編程復雜度較低，更易于理解和實現，在一些對效率要求不是特別苛刻的場景中也能發揮很好的作用。例如，在一個高并發的 Web 服務器中，如果每個請求的數據量較小，ET 模式可以更高效地處理請求；而在一個對穩定性和開發效率要求較高的小型應用中，LT 模式可能是更好的選擇。

Part3回調機制詳解

epoll 的回調機制是其高效的關鍵所在。當一個文件描述符（比如 socket）就緒時（即有數據可讀、可寫或者發生錯誤等事件），內核會調用預先注冊的回調函數。這個回調函數的主要任務是將就緒的socket放入 epoll 的就緒鏈表中，然后喚醒正在等待的應用程序（通過 epoll_wait 阻塞的應用程序線程）。

3.1 回調函數的作用

在 Epoll 的世界里，回調函數就像是一個隱藏在幕后的 “幕后英雄”，默默地發揮著關鍵作用。具體來說，ep_poll_callback 回調函數在內核中扮演著將事件添加到就緒鏈表 rdllist 的重要角色。當被監聽的文件描述符上發生了對應的事件（如可讀、可寫等），內核就會調用 ep_poll_callback 函數。這個函數就像是一個 “快遞分揀員”，將發生事件的文件描述符及其對應的事件信息，準確無誤地添加到就緒鏈表 rdllist 中。

這樣，當應用程序調用 epoll_wait 時，就可以直接從就緒鏈表中獲取到這些就緒的事件，而無需再去遍歷整個紅黑樹，大大提高了事件獲取的效率。例如，在一個網絡服務器中，當有新的數據到達某個 socket 時，內核會調用 ep_poll_callback 將該 socket 的可讀事件添加到就緒鏈表，服務器程序通過 epoll_wait 就能及時獲取到這個事件，從而進行數據讀取和處理。

3.2 回調機制的工作流程

回調機制的工作流程是一個環環相扣的精密過程，從事件發生到最終被應用程序處理，每一步都緊密相連。當一個文件描述符上發生了感興趣的事件，比如一個 socket 接收到了數據。內核中的設備驅動程序會首先感知到這個事件。由于在調用 epoll_ctl 添加文件描述符時，已經為該文件描述符注冊了 ep_poll_callback 回調函數，所以設備驅動程序會調用這個回調函數。ep_poll_callback 函數被調用后，會將包含該文件描述符和事件信息的 epitem 結構體添加到 eventpoll 結構體的就緒鏈表 rdllist 中。這就好比將一封封 “快遞”（事件）放到了一個專門的 “收件箱”（就緒鏈表）里。

當應用程序調用 epoll_wait 時，它會檢查就緒鏈表 rdllist 是否有數據。如果有，就將鏈表中的事件復制到用戶空間的 epoll_event 數組中，并返回事件的數量。應用程序根據返回的事件，對相應的文件描述符進行處理，比如讀取 socket 中的數據。下面是一個簡化的代碼示例，來展示這個過程：

// 假設已經創建了epoll實例epfd
struct epoll_event events[MAX_EVENTS];
int nfds = epoll_wait(epfd, events, MAX_EVENTS, -1);
if (nfds > 0) {
    for (int i = 0; i < nfds; ++i) {
        int fd = events[i].data.fd;
        if (events[i].events & EPOLLIN) {
            // 處理讀事件，這里可以讀取fd中的數據
            char buffer[BUFFER_SIZE];
            int n = recv(fd, buffer, sizeof(buffer) - 1, 0);
            if (n > 0) {
                buffer[n] = '\0';
                printf("Received: %s\n", buffer);
            }
        }
    }
}

在這個示例中，epoll_wait 從就緒鏈表中獲取到就緒事件，應用程序通過遍歷 events 數組，對發生讀事件的文件描述符進行數據讀取操作。

Part4應用場景與選擇策略

4.1 LT模式的適用場景

LT 模式以其獨特的觸發特性，在一些特定的應用場景中發揮著重要作用。由于它對數據處理及時性要求不高，邏輯處理相對簡單，所以非常適合一些簡單的網絡服務。比如小型的 Web 服務器，這類服務器通常處理的并發連接數較少，業務邏輯也不復雜，可能只是簡單地返回一些靜態頁面或者處理少量的動態請求。

在這種情況下，使用 LT 模式可以降低開發的難度，開發者無需過多考慮數據一次性處理完的問題，可以按照常規的順序逐步處理數據，減少出錯的概率。再比如一些內部系統的 API 服務，這些服務往往只面向內部的少量用戶，對性能的要求不是特別高，使用 LT 模式可以快速搭建起服務，并且易于維護和調試。

4.2 ET模式的適用場景

ET 模式則是高并發、對效率要求極高場景的 “寵兒”。以 Nginx 為例，作為一款高性能的 Web 服務器，Nginx 每天要處理海量的并發請求，在這種情況下，ET 模式的優勢就凸顯出來了。由于 ET 模式只在事件狀態發生變化時觸發一次，這就大大減少了不必要的事件觸發，降低了系統開銷，使得 Nginx 能夠在高并發的環境下高效地處理大量請求。

再比如一些實時系統，如股票交易系統、實時通信系統等，這些系統對延遲和事件的精確控制要求極高，ET 模式可以確保在數據到達的第一時間觸發通知，并且通過一次性處理完數據的方式，保證系統的實時性和準確性。

4.3 如何根據需求選擇

在選擇 LT 或 ET 模式時，需要綜合考慮多個因素。從項目需求來看，如果項目的并發量較低，業務邏輯簡單，且開發周期較短，那么 LT 模式是一個不錯的選擇，它可以快速實現功能，降低開發成本。如果項目面臨高并發的場景，對性能要求苛刻，那么 ET 模式更能滿足需求，雖然開發難度會有所增加，但可以獲得更高的效率和更好的性能表現。

從開發難度來說，LT 模式編程相對簡單，易于理解和調試，適合初學者或者對性能要求不是特別高的項目；而 ET 模式需要開發者對非阻塞 I/O 和數據處理有更深入的理解，編程難度較大，適合有一定經驗的開發者。在實際的項目中，也可以根據不同的業務模塊來選擇不同的模式，比如對一些核心的、高并發的業務模塊使用 ET 模式，而對一些輔助性的、并發量較低的模塊使用 LT 模式，從而達到性能和開發效率的平衡。

Part5epoll使用中的注意事項

5.1 常見問題及解決方案

在使用 epoll 時，開發者常常會遇到一些棘手的問題，其中 ET 模式下數據讀取不完整以及 epoll 驚群問題較為典型。

在 ET 模式下，數據讀取不完整是一個常見的 “陷阱”。由于 ET 模式的特性，只有當文件描述符的狀態發生變化時才會觸發事件通知。在讀取數據時，如果沒有一次性將緩沖區中的數據全部讀完，后續即使緩沖區中仍有剩余數據，只要狀態不再變化，就不會再次觸發可讀事件通知。這就導致可能會遺漏部分數據，影響程序的正常運行。

例如，在一個網絡通信程序中，客戶端向服務器發送了一個較大的數據包，服務器在 ET 模式下接收數據。如果服務器在第一次讀取時只讀取了部分數據，而沒有繼續讀取剩余數據，那么剩余的數據就會被 “遺忘”，導致數據傳輸的不完整。解決這個問題的關鍵在于，當檢測到可讀事件時，要循環讀取數據，直到read函數返回EAGAIN錯誤，表示緩沖區中已無數據可讀。這樣才能確保將緩沖區中的數據全部讀取完畢，避免數據丟失。

epoll驚群問題也是使用epoll時需要關注的重點。epoll驚群通常發生在多個進程或線程使用各自的epoll實例監聽同一個socket的場景中。當有事件發生時，所有阻塞在epoll_wait上的進程或線程都會被喚醒，但實際上只有一個進程或線程能夠成功處理該事件，其他進程或線程在處理失敗后又會重新休眠。這會導致大量不必要的進程或線程上下文切換，浪費系統資源，降低程序性能。在一個多進程的 Web 服務器中，多個工作進程都使用 epoll 監聽同一個端口。當有新的 HTTP 請求到來時，所有工作進程的epoll_wait都會被喚醒，但只有一個進程能夠成功接受連接并處理請求，其他進程的喚醒操作就成為了無效的開銷。

為了避免epoll 驚群問題，可以使用epoll的EPOLLEXCLUSIVE模式，該模式在 Linux 4.5 + 內核版本中可用。當設置了EPOLLEXCLUSIVE標志后，epoll 在喚醒等待事件的進程或線程時，只會喚醒一個，從而避免了多個進程或線程同時被喚醒的情況，有效減少了系統資源的浪費。同時，也可以結合使用SO_REUSEPORT選項，每個進程或線程都有自己獨立的 socket 綁定到同一個端口，內核會根據四元組信息進行負載均衡，將新的連接分配給不同的進程或線程，進一步優化高并發場景下的性能。

5.2 性能優化建議

為了充分發揮 epoll 的優勢，提升程序性能，我們可以從以下幾個方面進行優化：

合理設置epoll_wait的超時時間至關重要。epoll_wait的timeout參數決定了等待事件發生的最長時間。如果設置為 - 1，表示無限期等待，直到有事件發生；設置為 0，則立即返回，不等待任何事件；設置為正數，則等待指定的毫秒數。在實際應用中，需要根據具體業務場景來合理選擇。

在一些對實時性要求極高的場景，如在線游戲服務器，可能需要將超時時間設置為較短的值，以確保能夠及時響應玩家的操作。但如果設置得過短，可能會導致頻繁的epoll_wait調用，增加系統開銷。因此，需要通過測試和調優，找到一個平衡點，既能滿足實時性需求，又能降低系統開銷。可以根據業務的平均響應時間和事件發生的頻率來估算合適的超時時間，然后在實際運行中根據性能指標進行調整。

批量處理事件也是提高 epoll 性能的有效方法。當epoll_wait返回多個就緒事件時，一次性處理多個事件可以減少函數調用和上下文切換的開銷。在一個高并發的文件服務器中，可能同時有多個客戶端請求讀取文件。當epoll_wait返回多個可讀事件時，可以將這些事件對應的文件描述符放入一個隊列中，然后批量讀取文件數據。可以使用線程池或協程來并行處理這些事件，進一步提高處理效率。通過批量處理事件，能夠充分利用系統資源，提高程序的吞吐量。

使用EPOLLONESHOT事件可以避免重復觸發帶來的性能問題。對于注冊了EPOLLONESHOT的文件描述符，操作系統最多觸發其上注冊的一個可讀、可寫或者異常的事件，且只觸發一次，除非使用epoll_ctl函數重置該文件描述符上注冊的EPOLLONESHOT事件。這在多線程環境中尤為重要，它可以確保一個 socket 在同一時刻只被一個線程處理，避免多個線程同時操作同一個 socket 導致的競態條件。

在一個多線程的網絡爬蟲程序中，每個線程負責處理一個網頁的下載和解析。通過為每個socket設置EPOLLONESHOT事件，可以保證每個socket在下載過程中不會被其他線程干擾，提高程序的穩定性和性能。在處理完事件后，要及時重置EPOLLONESHOT事件，以便該socket在后續有新事件發生時能夠再次被觸發。

責任編輯：龐桂玉來源：深度Linux