Linux内核epoll机制深度解析：从源码到高性能网络编程实战

引言：为什么我们需要 epoll？

在现代互联网架构中，C10K、C100K乃至C1000K问题始终是后端工程师绕不开的技术挑战。当并发连接数从几千飙升到几十万甚至上百万时，传统的 select 和 poll 多路复用机制就暴露出了根本性的性能瓶颈。Linux 内核在 2.5.44 版本中引入了 epoll（event poll），它不仅仅是一个新的系统调用，更是一种全新的 I/O 事件通知范式，至今仍是 Nginx、Redis、Netty 等高性能框架的核心支柱。

本文将深入 epoll 的内核实现源码，从红黑树与双向链表的数据结构讲起，到 epoll_ctl 和 epoll_wait 的详细工作原理，再到水平触发（LT）与边沿触发（ET）的本质差异，最后通过实际的高性能网络编程案例，帮助你真正掌握这个让网络编程效率提升十倍的关键技术。

一、从 select/poll 到 epoll：性能瓶颈的突破

1.1 select 的三座大山

select 是 POSIX 标准定义的多路复用接口，几乎所有 Unix 系统都支持。然而它的设计存在三个根本问题：

第一，文件描述符集合大小受限。 select 使用 FD_SETSIZE（通常 1024）作为上限，这意味着它天生无法处理大规模并发。其 fd_set 是一个固定长度的位图（bitmap），你不能超过这个限制。

第二，线性扫描的 O(n) 复杂度。 select 返回后，调用方必须遍历整个 fd_set 来确定哪些描述符就绪。当你监视 10000 个描述符但只有 10 个就绪时，CPU 时间被大量浪费在无意义的遍历上。

第三，每次调用必须重新设置参数。 select 会修改传入的 fd_set，因此每次调用都需要重新构建描述符集合，这在频繁调用的场景下造成显著的内存拷贝开销。

1.2 poll 的改进与局限

poll 解决了 FD_SETSIZE 的限制，它使用 pollfd 数组而非位图，理论上能监视任意数量的描述符。但 poll 依然没有解决线性扫描的 O(n) 问题 —— 每次调用仍然需要传递全部监视的描述符，内核仍然需要遍历整个列表检查状态。

1.3 epoll 的 O(1) 事件通知模型

epoll 的核心思想是内核维护一个"就绪列表"，只返回就绪的事件。这意味着：

• 注册时一次性告诉内核你要监视哪些 fd 和哪些事件
• 内核主动在事件就绪时将 fd 加入就绪队列
• epoll_wait 只需要检查就绪队列，无需遍历全部监视的描述符
• 时间复杂度从 O(n) 降为 O(1)

这一设计使得 epoll 在连接数巨大但活跃比例低的场景下（如 API 网关、消息队列），性能远超 select/poll。

二、epoll 在内核中的数据结构

2.1 epoll 实例的创建：epoll_create1

当用户调用 epoll_create1(flags) 时，内核执行以下步骤（基于 Linux 6.x 内核源码分析）：

// fs/eventpoll.c
SYSCALL_DEFINE1(epoll_create1, int, flags)
{
    return do_epoll_create(flags);
}

static int do_epoll_create(int flags)
{
    struct eventpoll *ep;
    
    // 分配 eventpoll 结构体
    ep = kzalloc(sizeof(*ep), GFP_KERNEL);
    
    // 初始化红黑树根节点（用于管理所有监视的 fd）
    RB_CLEAR_ROOT(&ep->rbr);
    
    // 初始化就绪队列（双向链表）
    INIT_LIST_HEAD(&ep->rdllist);
    
    // 初始化等待队列（用于 epoll_wait 的阻塞）
    init_waitqueue_head(&ep->wq);
    
    // 初始化"额外唤醒"等待队列（用于 epoll 嵌套监视）
    init_waitqueue_head(&ep->poll_wait);
    
    // 返回文件描述符
    return epoll_alloc_fd(ep, flags);
}

这里有两个核心数据结构值得我们深入理解：

2.2 红黑树（Red-Black Tree）

内核使用红黑树来管理所有被监视的文件描述符。每个节点是一个 struct epitem，它通过 ffd 字段关联到具体的文件描述符。

选择红黑树而非哈希表的原因在于：

• O(log n) 的插入、删除、查找效率，对于大规模 fd 管理足够高效
• 没有哈希冲突问题，性能可预测
• fd 是整数，红黑树可以直接以 fd 值作为键值进行排序
• 内核红黑树 API 成熟稳定，维护成本低

2.3 就绪队列（Ready List）

就绪队列是一个双向链表（struct list_head rdllist），当某个被监视的文件描述符有事件就绪时，内核的 ep_poll_callback 回调函数会将对应的 epitem 节点加入这个链表。

epoll_wait 的核心操作就是检查这个链表：如果非空就直接返回其中的事件数据，如果为空就阻塞等待（直到超时或有事件触发）。

2.4 回调机制：ep_poll_callback

当底层驱动（如网卡驱动、tty 驱动、管道驱动）检测到 I/O 事件时，会调用在文件操作结构中注册的 poll 方法。epoll 通过 ep_ptable_queue_proc 在文件的等待队列上注册了一个回调函数 ep_poll_callback。

// 回调函数的核心逻辑
static int ep_poll_callback(wait_queue_entry_t *wait, unsigned mode, int sync, void *key)
{
    struct epitem *epitem = ep_item_from_wait(wait);
    struct eventpoll *ep = epitem->ep;
    
    // 加入就绪队列
    list_add_tail_irqsave(&epitem->rdllink, &ep->rdllist);
    
    // 唤醒正在 epoll_wait 阻塞的进程
    wake_up(&ep->wq);
}

这就是 epoll 高效的关键所在：它不在每次检查时轮询所有 fd，而是让内核在事件发生时主动"推送"就绪事件到队列中。

三、epoll_ctl：精确控制监视集

3.1 三种操作模式

// 添加监视
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);

// op 参数：
// EPOLL_CTL_ADD  - 添加新监视项
// EPOLL_CTL_MOD  - 修改已有的监视项
// EPOLL_CTL_DEL  - 删除监视项

3.2 EPOLL_CTL_ADD 的完整执行路径

当内核处理 EPOLL_CTL_ADD 时，执行以下关键步骤：

1. 查找 fd 对应的 file 结构体：通过 current->files->fdt 查找 fd 对应的 file 对象
2. 初始化 epitem 的红黑树节点：将 ffd（文件指针 + fd）编码到红黑树节点中
3. 初始化等待队列项：将关心的事件类型编码到 wait_queue_entry_t 的 private 字段中，回调函数设为 ep_poll_callback
4. 调用文件的 poll 方法：即 file->f_op->poll(file, pt)，获取当前 fd 的就绪状态，此时会将 ep_poll_callback 注册到文件的等待队列中
5. 插入红黑树：通过 rb_link_node 和 rb_insert_color 将 epitem 插入红黑树
6. 检查已有事件并触发：如果 poll 返回了就绪事件，直接将 epitem 加入就绪队列并唤醒等待进程

3.3 EPOLL_CTL_DEL 的特殊处理

EPOLL_CTL_DEL 需要特别处理一个竞态条件：如果此时有正在执行的事件回调函数引用了这个 epitem，直接释放内存会导致 use-after-free。内核通过 epitem.state = EPOLLITEM_DROMING 标记延迟释放，使用 rcu（Read-Copy-Update）机制确保安全。

四、epoll_wait：以最小开销获取就绪事件

4.1 函数原型

int epoll_wait(int epfd, struct epoll_event *events,
               int maxevents, int timeout);

// events: 用户空间数组，内核将就绪事件写入这里
// maxevents: 最多返回多少个事件（通常等于 events 数组长度）
// timeout: 超时时间（毫秒），-1 表示永久阻塞

4.2 用户态与内核态的零拷贝协作

epoll_wait 的一个关键优势是返回时无需再次遍历所有监视的 fd。内核只需要做以下操作：

1. 检查 rdllist 就绪队列是否为空
2. 如果为空且 timeout != 0，将当前进程加入等待队列并进入可中断睡眠
3. 如果非空，将就绪队列中的 epitem 节点的事件拷贝到用户空间 events 数组
4. 返回就绪事件数量

这个拷贝操作是 O(k) 的，其中 k 是就绪事件数（通常 k << n），而不是 O(n) 的。

五、水平触发（LT）与边沿触发（ET）

5.1 两者的本质区别

水平触发（Level Triggered, LT）是 epoll 的默认模式。只要 fd 处于可读/可写状态，epoll_wait 就会持续报告该 fd 就绪。

边沿触发（Edge Triggered, ET）只在 fd 状态变化时（如从不可读变为可读）报告一次。如果你没有一次性处理完数据，不会收到第二次通知。

5.2 LT 模式下的行为

// LT 模式示例：缓冲区有 200 字节，你只读取了 100 字节
// 下次 epoll_wait 调用时，仍然会报告该 fd 可读（因为还有 100 字节未读）
int n = read(fd, buf, 100);  // 读取 100 字节
// ... 处理 ...
// epoll_wait 再次返回，报告同一个 fd 可读（剩余 100 字节）

优点：编程简单，不用担心遗漏事件。缺点：如果 fd 始终有数据但没有被读取完，会产生无效的系统调用和上下文切换。

5.3 ET 模式下的行为

// ET 模式示例：网卡收到了 200 字节数据
// epoll_wait 报告 fd 可读
// 你必须循环 read 直到返回 EAGAIN/EWOULDBLOCK
while ((n = read(fd, buf, sizeof(buf))) > 0) {
    process_data(buf, n);
}
if (n == 0) close(fd);  // 对端关闭
if (n < 0 && errno != EAGAIN) handle_error();

优点：减少了重复的事件通知，在高并发场景下效率更高。缺点：必须使用非阻塞套接字，且必须循环读取/写入直到返回 EAGAIN，编程复杂度较高。

5.4 内核实现的差异

在内核源码中，ET 模式在就绪队列上的处理有本质不同：

// LT 模式：将节点重新加入就绪队列
if (epi->event.events & EPOLLLIST) {
    list_add_tail(&epi->rdllink, &ep->rdllist);
}

// ET 模式：只在状态变化时加入一次，不重新排队
// 通过 ep_send_events 的"已报告"标记实现

六、内核源码中的关键魔法：RCU 与锁机制

6.1 红黑树写操作的 fasync_lock

epoll_ctl(ADD/MOD/DEL) 操作红黑树时，使用 fasync_lock（一个互斥锁）保护。这是 epoll 中最昂贵的锁，因为红黑树的插入删除需要加锁。不过好消息是，epoll_ctl 是低频操作（只在添加/修改/删除 fd 时调用），所以锁竞争通常不是瓶颈。

6.2 就绪队列的 lockless 读取

epoll_wait 检查就绪队列时使用了一个技巧：它持有 ep->lock（一个自旋锁），然后扫描 rdllist 并拷贝事件。但如果此时有新的事件被回调加入队列，ep_poll_callback 会调用 wake_up(&ep->wq) 唤醒下一个 epoll_wait 调用者，而不是试图获取锁。

这种设计使得在负载较高时，多个 CPU 可以并行处理 epoll_wait 的红黑树读操作和事件回调的写操作。

6.3 RCU 延迟释放

当 EPOLL_CTL_DEL 删除一个节点时，如果此时有正在执行的回调函数持有该节点的引用，直接释放内存会导致崩溃。内核的解决方案是：

1. 标记节点状态为 EPOLLITEM_DROMING
2. 不立即释放内存
3. 使用 call_rcu(&epi->rcu, ep_free_rcu) 在所有 RCU 读者完成后释放

RCU 是一种无锁同步机制，读者不需要加锁，写者通过延迟释放保证安全性。

七、高性能实战：编写基于 epoll 的 Reactor 模式服务器

7.1 Reactor 模式架构

Reactor 模式是高性能网络服务的核心架构，其核心组件包括：

1. 事件分发器（Demultiplexer）：epoll_wait 负责收集就绪事件
2. 事件处理器（Event Handler）：为每个连接分配独立的读写回调
3. Reactor：主循环，不断分发事件给对应的处理器

7.2 完整的非阻塞 Reactor 实现（C 语言）

#include <sys/epoll.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#define MAX_EVENTS 1024
#define BUFFER_SIZE 4096
#define PORT 8080

// 连接上下文
typedef struct {
    int fd;
    char read_buf[BUFFER_SIZE];
    char write_buf[BUFFER_SIZE];
    int read_pos;
    int write_pos;
    // 可以在这里扩展超时时间、处理状态机等
} conn_t;

// 设置为非阻塞模式
int set_nonblocking(int fd) {
    int flags = fcntl(fd, F_GETFL, 0);
    if (flags == -1) return -1;
    flags |= O_NONBLOCK;
    return fcntl(fd, F_SETFL, flags);
}

// 添加 fd 到 epoll（ET 模式）
int epoll_add(int epoll_fd, int fd, uint32_t events, void *data) {
    struct epoll_event ev;
    ev.events = events | EPOLLET;  // 边沿触发
    ev.data.ptr = data;
    return epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev);
}

// 修改 fd 事件
int epoll_mod(int epoll_fd, int fd, uint32_t events, void *data) {
    struct epoll_event ev;
    ev.events = events | EPOLLET;
    ev.data.ptr = data;
    return epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd, &ev);
}

// 处理接受新连接
void handle_accept(int epoll_fd, int listen_fd) {
    struct sockaddr_in client_addr;
    socklen_t addr_len = sizeof(client_addr);
    
    // 在 ET 模式下，必须循环 accept 直到 EAGAIN
    while (1) {
        int client_fd = accept(listen_fd, 
                               (struct sockaddr*)&client_addr, &addr_len);
        if (client_fd < 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) break;
            if (errno == EINTR) continue;
            perror("accept");
            break;
        }
        
        set_nonblocking(client_fd);
        
        // 分配连接上下文
        conn_t *conn = malloc(sizeof(conn_t));
        conn->fd = client_fd;
        conn->read_pos = 0;
        conn->write_pos = 0;
        
        // 以可读事件加入 epoll
        epoll_add(epoll_fd, client_fd, EPOLLIN, conn);
        
        printf("New connection: fd=%d\n", client_fd);
    }
}

// 处理读事件（ET 模式必须循环读取）
void handle_read(int epoll_fd, conn_t *conn) {
    while (1) {
        int n = read(conn->fd, conn->read_buf + conn->read_pos, 
                     BUFFER_SIZE - conn->read_pos);
        if (n > 0) {
            conn->read_pos += n;
            
            // 检查是否收到完整请求（简单 HTTP 协议判断：找到 \r\n\r\n）
            if (memmem(conn->read_buf, conn->read_pos, "\r\n\r\n", 4)) {
                // 构建响应（简单的 HTTP 200 应答）
                const char *response = 
                    "HTTP/1.1 200 OK\r\n"
                    "Content-Length: 13\r\n"
                    "Connection: close\r\n\r\n"
                    "Hello, epoll!";
                memcpy(conn->write_buf, response, strlen(response));
                conn->write_pos = strlen(response);
                
                // 切换到写模式
                epoll_mod(epoll_fd, conn->fd, EPOLLOUT, conn);
                break;
            }
        } else if (n == 0) {
            // 对端关闭连接
            epoll_ctl(epoll_fd, EPOLL_CTL_DEL, conn->fd, NULL);
            close(conn->fd);
            free(conn);
            return;
        } else { // n < 0
            if (errno == EAGAIN || errno == EWOULDBLOCK) break; // 数据读完了
            if (errno == EINTR) continue; // 被信号中断
            perror("read");
            epoll_ctl(epoll_fd, EPOLL_CTL_DEL, conn->fd, NULL);
            close(conn->fd);
            free(conn);
            return;
        }
    }
}

// 处理写事件（ET 模式必须循环写入）
void handle_write(conn_t *conn) {
    while (conn->write_pos > 0) {
        int n = write(conn->fd, conn->write_buf, conn->write_pos);
        if (n > 0) {
            memmove(conn->write_buf, conn->write_buf + n, conn->write_pos - n);
            conn->write_pos -= n;
        } else if (n < 0) {
            if (errno == EAGAIN || errno == EWOULDBLOCK) break;
            if (errno == EINTR) continue;
            perror("write");
            break;
        }
    }
    
    if (conn->write_pos == 0) {
        // 响应发送完毕，关闭连接（或切换到读模式处理下一个请求）
        close(conn->fd);
        free(conn);
    }
}

int main() {
    // 1. 创建监听 socket
    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;
    addr.sin_family = AF_INET;
    addr.sin_addr.s_addr = INADDR_ANY;
    addr.sin_port = htons(PORT);
    
    bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr));
    listen(listen_fd, SOMAXCONN);
    set_nonblocking(listen_fd);
    
    // 2. 创建 epoll 实例
    int epoll_fd = epoll_create1(EPOLL_CLOEXEC);
    
    // 3. 将监听 fd 加入 epoll
    struct epoll_event ev;
    ev.events = EPOLLIN;
    ev.data.fd = listen_fd;
    epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev);
    
    struct epoll_event events[MAX_EVENTS];
    
    printf("Server started on port %d\n", PORT);
    
    // 4. 主事件循环
    while (1) {
        int nready = epoll_wait(epoll_fd, events, MAX_EVENTS, -1);
        
        for (int i = 0; i < nready; i++) {
            if (events[i].data.fd == listen_fd) {
                // 有新连接
                handle_accept(epoll_fd, listen_fd);
            } else {
                conn_t *conn = (conn_t *)events[i].data.ptr;
                
                if (events[i].events & EPOLLIN) {
                    handle_read(epoll_fd, conn);
                }
                if (events[i].events & EPOLLOUT) {
                    handle_write(conn);
                }
                if (events[i].events & (EPOLLERR | EPOLLHUP)) {
                    // 错误处理
                    epoll_ctl(epoll_fd, EPOLL_CTL_DEL, conn->fd, NULL);
                    close(conn->fd);
                    free(conn);
                }
            }
        }
    }
    
    close(epoll_fd);
    return 0;
}

编译后用 ab -n 100000 -c 1000 http://localhost:8080/ 压测，你会发现这个极简服务器的 QPS 远超同等条件下的 select/poll 方案。

八、epoll 的高级特性与使用技巧

8.1 EPOLLONESHOT：防止惊群效应

在多线程 epoll_wait 场景下，同一个 EPOLLIN 事件可能被多个线程同时返回，造成"惊群"。设置 EPOLLONESHOT 可以确保一个 fd 在就绪事件被处理后从 epoll 中暂时"休眠"，不会被重复报告，需要在处理完后通过 EPOLL_CTL_MOD 重新激活。

ev.events = EPOLLIN | EPOLLET | EPOLLONESHOT;
ev.data.ptr = conn;
epoll_ctl(epoll_fd, EPOLL_CTL_ADD, fd, &ev);

// 处理完成后重新激活
ev.events = EPOLLIN | EPOLLET | EPOLLONESHOT;
epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd, &ev);

8.2 eventfd：用户态事件通知

eventfd 是 Linux 2.6.22 引入的一个文件描述符，它本质上是一个内核维护的 64 位计数器。其他线程或进程可以通过 write 来增加值，epoll 监控该 fd 可以实现"用户态触发事件" —— 这是一种优雅的方式将异步操作通知集成到 epoll 主循环中。

#include <sys/eventfd.h>

int efd = eventfd(0, EFD_NONBLOCK);
// 将 efd 加入 epoll

// 在另一个线程中触发事件
uint64_t u = 1;
write(efd, &u, sizeof(u));  // epoll_wait 会立即中断并报告 efd 可读

8.3 signalfd：通过 epoll 处理信号

传统的事件循环要同时处理信号和 I/O 事件非常困难，因为信号处理函数会中断阻塞调用。signalfd 将信号转化为文件描述符上的可读事件，使得信号可以被优雅地集成到 epoll 循环中。

#include <signal.h>
#include <sys/signalfd.h>

sigset_t mask;
sigemptyset(&mask);
sigaddset(&mask, SIGINT);
sigaddset(&mask, SIGTERM);

// 首先阻塞信号（防止默认处理）
sigprocmask(SIG_BLOCK, &mask, NULL);

int sfd = signalfd(-1, &mask, SFD_NONBLOCK);
// 将 sfd 加入 EPOLLIN | EPOLLET 到 epoll

// 在 epoll_wait 返回后检查 sfd 是否就绪
// 如果就绪，读取 signalfd_siginfo 获取信号信息

8.4 timerfd：高精度定时器

timerfd 将定时器转化为文件描述符事件，精确到微秒级，比 setitimer 等方式更适合集成到事件循环中。

#include <sys/timerfd.h>

int tfd = timerfd_create(CLOCK_MONOTONIC, TFD_NONBLOCK);

struct itimerspec its;
its.it_value.tv_sec = 1;      // 第一次超时时间
its.it_value.tv_nsec = 0;
its.it_interval.tv_sec = 1;   // 周期性超时
its.it_interval.tv_nsec = 0;
timerfd_settime(tfd, 0, &its, NULL);

// 将 tfd 加入 epoll
// 每次定时器到期，tfd 可读，读取 8 字节 uint64_t 获取过期次数

九、epoll 与 io_uring 的对比

io_uring 是 Linux 5.1 引入的最新异步 I/O 框架，它不仅仅是事件通知机制，而是真正实现了异步 I/O（包括网络、磁盘、甚至更复杂的操作）。两者并非替代关系，而是互补：

维度	epoll	io_uring
定位	事件通知（告诉你"fd 就绪"）	异步 I/O 执行（帮你完成 I/O）
Linux 版本	2.5.44	5.1+
编程模型	先 epoll_wait 知道就绪，再 read/write	同时提交多个 I/O 请求，内核异步执行并通知完成
适用场景	已有事件驱动框架（Nginx、Redis）	追求极致性能的新项目（如 ScyllaDB、QEMU）
学习成本	低	极高（涉及共享内存 ring buffer、SQE/CQE）
成熟度	极高，生态完善	快速发展中，部分子系统尚未完全适配

对于绝大多数应用场景，epoll 依然是首选 —— 它稳定、足够高效、生态庞大。io_uring 适合那些在 epoll 方案下仍然遇到性能瓶颈的场景（如大量随机磁盘 I/O + 网络混合服务的场景）。

十、常见陷阱与最佳实践总结

陷阱 1：忘记设置 O_NONBLOCK。 ET 模式必须配合非阻塞套接字，否则单次 read/write 可能会阻塞整个事件循环。

陷阱 2：处理 EAGAIN 不彻底。 ET 模式下必须循环 read/write 直到 EAGAIN，否则会遗漏事件。一个常见错误是只读一次发现读少了就 break。

陷阱 3：注册了可读但从不读取且用 ET 模式。 这将导致 fd 永久丢失未来的可读事件通知，因为 ET 只在状态变化时报告一次。

陷阱 4：在多线程环境中不加锁地使用同一个 epoll_fd。 虽然内核 epoll 实现内部有锁保护数据结构，但多个线程同时调用 epoll_wait 在 ET 模式下会导致事件被多个线程消费（竞争消费问题），应使用 EPOLLONESHOT 或统一的事件分发。

最佳实践 1：统一事件源。 使用 timerfd、eventfd、signalfd 将定时器、线程间通知、信号全部整合到同一个 epoll 循环，形成一个"统一事件源"架构，避免多线程/多锁的复杂度。

最佳实践 2：连接上下文封装。 不要只存储 fd，而是将每个连接关联到一个完整的上下文结构体（包含读写缓冲区、状态机、超时时间戳），通过 ev.data.ptr 传递。

最佳实践 3：超时管理。 定期清理长时间无活动的连接。可以在连接上下文中维护 last_active 字段，每次事件更新，由定时器定期扫描清理过期连接。

最佳实践 4：避免在回调中执行阻塞操作。 Reactor 模式的核心假设就是事件处理是非阻塞的。如果必须执行耗时操作（如数据库查询、文件读取），切换到单独的 worker 线程池完成，然后通过 eventfd 或管道将结果通知回事件循环。

最佳实践 5：合理分配 maxevents。 epoll_wait 的 maxevents 参数决定了单次调用能返回的最大事件数组长度。如果处理速度跟不上事件到达速度，可以分批处理；如果追求延迟，可以减小 maxevents 并减少 timeout。

总结

epoll 的设计哲学体现了操作系统内核中一个深刻的工程原则：将轮询转化为通知。通过红黑树管理监视集合、就绪队列记录就绪事件、回调机制实时推送，epoll 实现了从 O(n) 到 O(1) 的质变，这正是它在二十年后依然是 Linux 高性能网络编程基石的根本原因。

从 select 到 poll 再到 epoll，每一次 I/O 多路复用机制的演进，都伴随着互联网对并发处理能力需求的指数级增长。理解 epoll，不仅仅是为了写出更快的代码，更是为了建立一种"事件驱动"的编程思维模型 —— 而这，正是现代云原生基础设施的核心灵魂。

当你下次启动 Nginx 或 Redis 时，不妨想想：在那些每秒处理数十万次请求的繁华背后，正是数十万个红黑树节点和就绪队列项在默默工作，承载着整个互联网的心跳。