epoll 原理与高并发网络编程实战：从 C10K 到红黑树与就绪链表

1. 项目概述与问题场景

1.1 为什么 C10K 问题绕不开 epoll

做 Linux 后端开发的朋友，早晚都会撞上“如何同时处理成千上万个连接”这堵墙。我在刚转做服务端那会儿，第一个像样的网络程序用的是多线程 per-connection 模型，也就是每来一个客户端连接就pthread_create一个线程去处理。当时测试机只有 4 核 8 线程，跑到 800 多个并发连接的时候，机器 CPU 直接被打满，上下文切换的损耗占了将近 60%，连top命令敲下去都要卡两三秒才能出结果。那次经历让我意识到，靠“线程堆连接”这条路在大规模并发场景下根本走不远。

这个问题的学名叫 C10K，也就是 Concurrent 10K Connections——单机同时维持一万个网络连接。解决它的核心思路不是“继续堆线程”，而是“用少量线程监听大量连接，等连接可读/可写时再处理”。这种机制就是 I/O 复用，英文叫 I/O Multiplexing。Linux 下实现 I/O 复用的经典手段有三套：select、poll、epoll。其中select和poll是早期就有的，epoll是 Linux 2.6 内核引入的，专门为了解决前两者在大规模连接下的性能瓶颈。这篇文章我打算把 epoll 从原理到底层数据结构、从 API 用法到工程踩坑完整讲一遍，适合正在学 Linux 网络编程的入门读者，也适合准备面试、想彻底搞懂“为什么 epoll 快”的后端开发。

1.2 epoll 究竟解决了什么问题

要理解 epoll 的价值，得先知道select和poll有什么毛病。

select的工作方式是这样的：把关心的文件描述符集合（fd_set）拷贝到内核，内核逐个检查这些 fd 是否有事件发生，然后把结果拷回用户态，用户态再遍历所有 fd 找到就绪的那些去处理。这里有两个硬伤。第一，fd_set默认只有 1024 个 bit，能监视的连接数最多就是 1024 个，想扩大还得重新编译内核或者改宏定义，非常不优雅。第二，每次调用都要把整个 fd 集合从用户态拷贝到内核态、再从内核态拷回来，而且每次都是全量扫描，事件复杂度是 O(n)。连接数一上来，这个“拷贝 + 遍历”的开销会呈线性暴涨，性能曲线非常难看。

poll解决了fd_set大小限制的问题，它改用pollfd数组来承载 fd，不再有 1024 的上限。但“全量拷贝 + 全量遍历”这个核心缺陷依然存在，而且 fd 数量越多，每次调用的开销就越大。换句话说，poll 只是把 select 的水桶换大了一点，但漏水的地方还是那两处。

epoll 的思路完全不同。它不再每次调用都把全部 fd 交给内核去扫，而是先在用户态把关心的 fd 注册进内核里的一张表中，内核通过回调机制只把“真正就绪”的 fd 放进一个就绪链表。用户每次调用epoll_wait时，只需要从就绪链表里把已就绪的事件取走。这个机制让 epoll 的效率不再取决于“连接总数”，而只取决于“活跃连接数”。哪怕单机挂着 10 万个连接，如果同一时刻只有 100 个连接有数据可读，那么你的程序只需要处理这 100 个就好，剩下的 99900 个连接完全不会消耗 CPU。

我后面会详细拆解这个“回调机制”到底是怎么实现的，以及为什么它能把复杂度从 O(n) 降到 O(就绪连接数)。

2. epoll 核心机制与底层数据结构

2.1 三张关键“表”：eventpoll、红黑树、就绪链表

epoll 在内核里创建出来之后，会对应一个struct eventpoll实例。这个实例里最核心的东西是两棵结构：一棵是红黑树，一棵是双向链表。

红黑树用来存放所有注册到这个 epoll 实例上的 fd。为什么用红黑树不用哈希表？因为 fd 会频繁地增删，而且内核需要按 fd 的编号有序组织，红黑树在插入、删除、查找上的时间复杂度都是 O(log n)，兼顾了效率和有序性。你用epoll_ctl添加、修改、删除监视对象时，本质就是在操作这棵红黑树。

双向链表则是存放“就绪事件”的地方。内核检测到某个 fd 上有数据到达或者可以写入时，会通过回调函数把对应的epitem节点挂到这个就绪链表上。这个链表上的节点就是epoll_wait可以直接返回给用户的东西。

epoll_wait被用户态调用时，做的事情非常简单：检查就绪链表是不是空的，如果是空的就进入休眠等待（可以设置超时时间），一旦链表非空就把它里面的节点复制到用户态传入的事件数组里。整个过程完全不碰红黑树里那些“没反应的 fd”。

为了更直观地理解，你可以把 epoll 想象成一个物业前台。红黑树是前台手里的住户花名册，上面登记着每户业主的联系方式。就绪链表是“待处理事项便签条”，哪个业主家里漏水了，保安巡检发现后就写一张便签条贴在前台。你每次去前台问“有事吗”，前台只需要把便签条撕下来给你就行，完全不用把花名册里几千户人家挨个问一遍。这就是 epoll 高效的本质。

2.2 三个 API 的分工与底层逻辑

epoll 一共有三个系统调用，职责清晰，各管一段。

第一个是epoll_create，用来创建一个 epoll 实例。老版本的内核要求传入一个 size 参数，内核会按照这个大小预分配一些内存。但从 Linux 2.6.8 之后，这个 size 参数基本上被忽略掉了，内核会按需动态分配。你传 1 也行，传 1024 也行，不影响实际能注册的 fd 数量。不过为了代码的可读性，一般还是会传一个大于 0 的数字，很多人习惯写 1024，只是个约定俗成。

第二个是epoll_ctl，负责管理红黑树上的 fd。它有三个操作类型：EPOLL_CTL_ADD插入一个新节点、EPOLL_CTL_MOD修改已有节点的事件类型、EPOLL_CTL_DEL删除节点。每次调用都要传入一个struct epoll_event，里面有两个关键字段：events是你要关注的事件类型（EPOLLIN、EPOLLOUT、EPOLLERR 等），data是一个联合体，最常用的是data.fd，用来记录这个事件属于哪个 fd。这里有个实战细节：data不只是可以存 fd，它是个 64 位的epoll_data_t，你可以存指针，指向你自己定义的连接上下文结构体。在工程实现里这几乎是标配，后面我会在实操章节细讲。

第三个是epoll_wait，负责从就绪链表里取事件。它的签名是：

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

events是用户态的一块数组，内核会把就绪的事件从这里返回。maxevents告诉你这块数组最多能装多少个事件，千万别让内核溢出你给的缓冲区。timeout是等待超时时间，单位是毫秒。0 表示立即返回（轮询模式），-1 表示无限期阻塞直到有事件发生。

从底层视角来看，epoll_wait返回时，就绪链表里的节点会被转移到用户态，但并不会从红黑树中删除对应的 fd 注册关系。也就是说，fd 的事件注册是一次性写入内核的，之后每次等待事件都不需要重复拷贝全量 fd 集合。这就是 epoll 和 select 最本质的区别。

3. 从零实现一个 epoll 高并发 Echo 服务器

3.1 服务器框架设计与事件模型选型

理论讲再多，不手写一遍等于白看。接下来我带你从零实现一个基于 epoll 的 Echo 服务器，所谓 Echo 就是客户端发什么，服务器原样返回什么。这是网络编程里的“Hello World”，但它足以把 epoll 的核心用法完整串起来。

在设计之前，先做一个关键的选型决策：用单线程还是多线程？

单线程 epoll 模型的好处是简单、无锁、不会出现共享资源竞争，而且是 epoll 最典型的应用形态。对于 Echo 这种 CPU 开销极小的场景，单线程完全够用。如果要处理 CPU 密集型任务，一般会在 epoll 的工作线程后面挂一个线程池。这篇文章先讲单线程模型，线程池扩展会在后面讨论。

整个服务器的核心事件循环可以拆成四步：

1. 创建 socket，绑定端口，监听连接，把监听 fd 加入 epoll，关注EPOLLIN事件（表示有新的连接到达）。
2. 进入 while 循环，调用epoll_wait阻塞等待事件。
3. 遍历返回的事件数组，如果是监听 fd 上有事件，说明有新连接，调用accept接受连接，并把新的连接 fd 加入 epoll。
4. 如果是普通连接 fd 上有事件，说明客户端发了数据，调用read读取数据，再调用write原样写回。

如果read返回 0，说明客户端关闭了连接，这时候要调用close关闭 fd 并从 epoll 中移除。

3.2 代码实现与关键细节注释

下面是我整理的完整代码，为了保证可读性，去掉了大部分错误处理，只保留了核心逻辑骨架。实际工程中每个系统调用都要检查返回值。

#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <sys/socket.h> #include <netinet/in.h> #include <arpa/inet.h> #include <sys/epoll.h> #define MAX_EVENTS 1024 #define BUFFER_SIZE 4096 int main(int argc, char *argv[]) { int listen_fd, epfd, conn_fd; struct sockaddr_in server_addr; struct epoll_event ev, events[MAX_EVENTS]; char buffer[BUFFER_SIZE]; // 1. 创建监听 socket listen_fd = socket(AF_INET, SOCK_STREAM, 0); if (listen_fd < 0) { perror("socket"); exit(EXIT_FAILURE); } // 设置端口复用，否则 TIME_WAIT 状态会导致重启失败 int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); // 2. 绑定地址与端口 memset(&server_addr, 0, sizeof(server_addr)); server_addr.sin_family = AF_INET; server_addr.sin_addr.s_addr = htonl(INADDR_ANY); server_addr.sin_port = htons(8080); if (bind(listen_fd, (struct sockaddr *)&server_addr, sizeof(server_addr)) < 0) { perror("bind"); exit(EXIT_FAILURE); } // 3. 开始监听 if (listen(listen_fd, 128) < 0) { perror("listen"); exit(EXIT_FAILURE); } // 4. 创建 epoll 实例，并注册监听 fd epfd = epoll_create(1); ev.events = EPOLLIN; ev.data.fd = listen_fd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, &ev) < 0) { perror("epoll_ctl"); exit(EXIT_FAILURE); } printf("Echo server listening on port 8080\n"); // 5. 事件循环 while (1) { int nfds = epoll_wait(epfd, events, MAX_EVENTS, -1); if (nfds < 0) { perror("epoll_wait"); break; } for (int i = 0; i < nfds; i++) { // 5.1 监听 fd 可读 -> 有新连接 if (events[i].data.fd == listen_fd) { struct sockaddr_in client_addr; socklen_t client_len = sizeof(client_addr); conn_fd = accept(listen_fd, (struct sockaddr *)&client_addr, &client_len); if (conn_fd < 0) { perror("accept"); continue; } printf("New connection from %s:%d, fd = %d\n", inet_ntoa(client_addr.sin_addr), ntohs(client_addr.sin_port), conn_fd); // 新连接 fd 设置非阻塞，配合 epoll 边缘触发时是必须的 // 这里先用水平触发，注释掉非阻塞设置也能跑 ev.events = EPOLLIN; ev.data.fd = conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev); } // 5.2 普通连接可读 -> 读取数据并回显 else if (events[i].events & EPOLLIN) { int fd = events[i].data.fd; ssize_t n = read(fd, buffer, sizeof(buffer) - 1); if (n <= 0) { // n == 0 表示对方关闭 // n < 0 表示出错，这里简化处理：统一关闭 close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); printf("Connection closed, fd = %d\n", fd); } else { buffer[n] = '\0'; printf("Received %zd bytes from fd %d: %s", n, fd, buffer); write(fd, buffer, n); } } } } close(epfd); close(listen_fd); return 0; }

这段代码里有一个非常重要的工程细节：为什么EPOLLIN的时候直接read就行，而accept的时候不需要循环处理？

在水平触发（LT）模式下，只要 socket 缓冲区里还有数据，epoll_wait就会反复上报这个 fd 的EPOLLIN事件。所以如果你只read一次就跑回epoll_wait，万一一次read没有把数据读完，下一次epoll_wait还是会返回这个 fd，你可以继续读。这是 LT 的“保险”特性。后面我讲 ET 模式的时候，你会看到这个逻辑必须反过来，必须用 while 循环把数据一次性读完，否则会漏数据。

3.3 编译运行与性能压测验证

用下面的命令编译并启动服务器：

gcc -o echo_server echo_server.c ./echo_server

然后用 Linux 自带的工具验证功能。最简单的方式是开两个终端：

# 终端1：连接 echo 服务器 nc localhost 8080 # 终端2：用 strace 观察系统调用，确认 epoll 在正常工作 strace -p $(pgrep echo_server) -e trace=epoll_wait,accept,read,write

如果一切正常，在nc终端里输入任意字符串，服务器会原样回显。strace里能看到epoll_wait返回后立刻有accept或read、write调用。

功能跑通之后可以简单压测一下。安装wrk或ab工具：

# 用 ab 模拟 10000 个请求，100 并发 ab -n 10000 -c 100 -k http://127.0.0.1:8080/

注意 Echo 服务器不是 HTTP 服务器，ab测试时需要把请求数据设计成符合 Echo 逻辑的文本。更纯粹的做法是写一个简单的多线程客户端脚本发数据，统计延迟和吞吐。我这里就不贴全部代码了，想重点说明的是：当你把并发从 100 调到 5000 时，单线程 epoll 模型的 CPU 占用依然很低，而用早期 select 模型的服务器在同样条件下 CPU 已经飙到接近 100%。这组对比数据最能直观地说明 epoll 的价值。

4. LT 与 ET 触发模式：知其然更知其所以然

4.1 水平触发（LT）：默认的“安全模式”

epoll 默认的工作模式是 LT（Level Triggered，水平触发）。它的语义是：只要 fd 上有未处理完的事件，epoll_wait就会一直上报。比如你注册了EPOLLIN，缓冲区里有 100 字节数据，你只read了 40 字节，那么下次调用epoll_wait时这个 fd 依然会出现。

LT 的好处是编程简单，容错率高。即使你处理事件时偷懒少读了几字节，内核兜底会再通知你。这个问题本质上是“通知丢失”的兜底机制。

它的缺陷也很明显：如果某个 fd 一直有数据没读完，epoll_wait每次都会返回这个 fd，程序会反复被唤醒，CPU 空转浪费。这在某些场景下可能让“活跃 fd”影响“不活跃 fd”的处理。比如 1000 个连接里，有一个连接以极快的速度持续发数据以至于你永远读不完，那其他 999 个连接的事件可能会被“饿死”。这是 LT 在高负载下需要小心的问题。

4.2 边缘触发（ET）：高性能但也更“难搞”

ET（Edge Triggered，边缘触发）的语义不一样：只有在状态发生变化的那一刻，内核才通知你一次。比如缓冲区从“没有数据”变成“有数据”时，epoll_wait会返回一次；但如果你没有一次读完，缓冲区里还剩着数据，内核不会再次通知你，直到有新的数据到达，产生一个新的“边沿跳变”。

ET 模式带来的收益是：内核上报事件的次数大幅减少，不会出现 LT 模式下那种反复上报同一个 fd 的“唠叨”行为。在高并发场景下，这能显著减少系统调用次数和 CPU 唤醒次数，这也是很多高性能网络框架（比如 Redis、Nginx 的某些模块）选择 ET 模式的原因。

但 ET 模式对代码有硬性要求：

第一，fd 必须是非阻塞的。因为 ET 要求“数据一次读完”，如果用阻塞 socket，读到缓冲区暂时为空时，read会一直卡住线程，整个事件循环就死了。所以必须用非阻塞 fd，配合while循环读，直到读到EAGAIN错误码才停止。

第二，读数据必须用while循环，一次把缓冲区数据全部读走。标准姿势如下：

while (1) { ssize_t n = read(fd, buffer, sizeof(buffer)); if (n > 0) { // 处理数据 } else if (n == 0) { // 对端关闭 close(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { // 数据已经读完了，跳出循环 break; } else { // 真正的错误 perror("read"); close(fd); break; } } }

我把这个处理逻辑整理成一个对比表：

4.3 如何正确选择 LT 还是 ET

我的建议是：对于绝大多数业务场景，LT 模式足够了。操作简单，不容易出 bug，而且 epoll 本身的性能优势在 LT 模式下已经完全够用。ET 模式带来的性能提升是“锦上添花”级别的，没有到“非用不可”的地步。

但如果你在写一个极致的网络中间件，比如消息网关、API 网关、代理服务器，这些场景下每个连接要处理的包非常多，系统调用次数会成为一个不可忽视的开销，这时候 ET 模式就是值得的。业界一个常见的做法是：监听 fd 用 LT（方便 accept），连接的 fd 用 ET（减少读写事件的重复上报）。两套模式混用是完全可以的。

我早期在 ET 模式下踩过一个很典型的坑：注册EPOLLIN | EPOLLET之后，由于read用的是固定大小的栈上缓冲区，一次没能读完一个大包，结果剩下的数据被内核“扣住”不再上报。客户端那边一直在等响应，服务器这边干等新的边沿触发，两边一起死锁。后来排查了很久才发现是 ET 模式下没循环读取的问题。所以如果项目里选择了 ET，代码 review 时要特别关注读写循环逻辑。

5. epoll 进阶工程实践与性能调优

5.1 用 data.fd 还是 data.ptr：大型连接管理的分水岭

早学 epoll 的时候，习惯性地用data.fd来标记事件属于哪个文件描述符。但当项目规模变大，每个连接不止是一个 fd，还关联着一堆状态时，你会发现只存一个 fd 远远不够。

举个实际场景：一个聊天服务器，每个连接代表一个用户，用户有昵称、有房间号、有未发送的消息队列。你总不能每次事件来了之后再通过 fd 去哈希表里查对应的用户对象吧？这样不仅麻烦，而且哈希查找本身也是性能开销。

struct epoll_event里的data字段实际上给你留了一个 64 位的空间，完全可以直接存指针。标准做法是给每个连接定义一个上下文结构体：

typedef struct conn_context { int fd; char *user_name; int room_id; char recv_buffer[4096]; int recv_len; } conn_context;

注册事件时：

conn_context *ctx = malloc(sizeof(conn_context)); ctx->fd = conn_fd; // 初始化 ctx 的其他字段 ev.events = EPOLLIN; ev.data.ptr = ctx; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, &ev);

事件到达时，直接从events[i].data.ptr拿到完整上下文，完全不需要再查表：

conn_context *ctx = (conn_context *)events[i].data.ptr; if (events[i].events & EPOLLIN) { // 直接使用 ctx 里的缓冲区，处理业务逻辑 }

关闭连接时再free(ctx)，注意别内存泄漏。这是工程上管理海量连接的基石，几乎所有生产级网络库都是这么干的。

5.2 阻塞与非阻塞：被忽略的“致命细节”

Linux socket 默认是阻塞的。如果你在 epoll 模型中直接使用阻塞 socket，一旦某个事件的处理函数里发生阻塞（比如send缓冲区满了），整个事件循环就卡住了，其他所有连接都会断掉服务。这是新手最容易犯的错误。

正确的做法是：所有加入 epoll 的 fd，尤其是连接 socket，都必须设置为非阻塞模式。设置方法有两种：

一种是在socket()创建时用SOCK_NONBLOCK标志：

int fd = socket(AF_INET, SOCK_STREAM | SOCK_NONBLOCK, 0);

另一种是用fcntl设置：

int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK);

设置成非阻塞后，read、write、accept都可能返回EAGAIN（表示“现在没数据/现在不能写”），这不是错误，而是正常的“信号”，表示本次处理可以停手了。

特别提醒一个坑：accept返回的 fd 不会继承监听 fd 的非阻塞属性。即使监听 fd 设置了O_NONBLOCK，每次accept出来的新连接仍然可能是阻塞模式的。所以accept之后必须对新 fd 单独设置非阻塞，这个步骤漏掉就会出现“个别连接把整个服务拖死”的诡异问题。

5.3 常见性能瓶颈与调优手段盘点

epoll 本身性能很好，但用不好照样有瓶颈。我梳理几个高频问题：

关于惊群问题。多个线程都调用epoll_wait等待同一个 epoll 实例时，一个事件到达会唤醒所有等待的线程，但最终只有一个线程能处理成功，其他线程空跑一趟，这就是“惊群”（thundering herd）。Linux 4.5 之后引入了EPOLLEXCLUSIVE事件标志，可以给 epoll 加上互斥唤醒特性，避免惊群。如果你的内核版本够新（4.5+），多线程 epoll 模型可以加上这个标志。

关于EPOLLOUT与 busy loop。注册EPOLLOUT事件要非常小心。socket 缓冲区在绝大多数情况下都是“可写”的，一旦你注册了EPOLLOUT，epoll_wait可能会一直返回这个 fd，导致 CPU 空转。正确的姿势是“按需注册”：当你需要往某个 fd 写数据、但一次write没写完时，才临时注册EPOLLOUT；写完立刻移除EPOLLOUT。

关于超时参数。epoll_wait的timeout参数不要随便传 0。0 表示非阻塞地立即返回，如果事件不多，程序会陷入一个高速空转的循环，CPU 占用会莫名其妙飙高。没有特殊需求，建议传-1阻塞等待，或者传一个合理的超时值（如 100ms），确保线程不会被无限期挂死。

关于单线程 vs 多线程。单线程 epoll 适合 I/O 密集型、业务逻辑很轻的场景。如果业务逻辑里有加密解密、数据压缩、编解码等 CPU 密集型操作，单线程模型会导致这些计算阻塞事件循环。工程上的姿势是：epoll 的 I/O 线程只负责收发数据，把耗时计算任务丢给线程池。Nginx 用的就是类似的多进程架构，每个 worker 进程各跑一个 epoll 循环。

5.4 调试 epoll 程序的实用工具

程序跑起来之后，想确认内核里的 epoll 状态光靠“感觉”是不行的。Linux 提供了一批很实用的调试手段。

/proc文件系统里挂着所有进程的 fd 信息。用ls -l /proc/<pid>/fd可以列出进程打开的所有 fd，能看到哪些连接还活着。用cat /proc/<pid>/fdinfo/<epoll_fd>能查看某个 epoll 实例的底层状态，里面有这么几项：

pos: 0 flags: 02 mnt_id: 20 tfd: 8 events: 19 data: 7f8c0a4008c0 pos:0 ino:9fb84 tfd: 12 events: 19 data: 7f8c0a401088 pos:0 ino:786f2

tfd表示注册在该 epoll 实例上的 fd 编号，events是注册的事件掩码（19 是十进制，转十六进制是 0x13，即 EPOLLIN 0x1 与 EPOLLRDHUP 0x2 与 EPOLLONESHOT 0x1000 的组合），data显示的是注册的 data 值。这些信息在排查“为什么这个连接没有事件上报”时非常有用。

strace是另一个必备工具。strace -p <pid> -e trace=epoll_wait,epoll_ctl,read,write可以看到系统调用级别的每一次事件循环行为。我曾经用它抓到过一个诡异 bug：一个 fd 被epoll_ctl删掉之后，又因为代码逻辑错误被加入到了另一个 epoll 实例，两个事件循环同时等待它。这种多重注册的问题在代码里很难通过肉眼发现，但 strace 一看就明白。

6. epoll 使用中的高频问题与避坑实录

6.1 问题速查表

我把过去在 epoll 编程中遇到过的典型问题整理成了一个速查表，方便你直接对照排查。

6.2 经验一：ET 模式 + 非阻塞 socket 的“读不完”教训

我在做推送网关时，第一次用 ET 模式就踩了坑。当时的设计是收到客户端请求后，从后端拉数据再推给客户端，数据包最大的时候有几十 KB。我的读取缓冲区是 4KB，read一次只读一小段就返回epoll_wait了，剩下的大段数据因为已经触发过边沿，内核不再通知。

客户端那边收不到完整响应，就一直干等；服务器这边epoll_wait也一直没有这个 fd 的事件，整个连接就这么挂在半空中。

解决方式就是前面提到的 while 循环读完，但这里还有一个细节：当你用recv或read读完缓冲区所有数据时，最后一次调用会返回EAGAIN。判断逻辑一定要这样写：

} else if (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK)) { break; }

不要把EAGAIN当成异常去打印错误日志，否则你的日志会被刷爆。这个细节我见过不少人栽跟头。

6.3 经验二：监听 fd 的事件处理不能阻塞

很多人在处理监听 fd 时漫不经心，直接在事件回调里做accept甚至做 DNS 反查之类的耗时操作。这是大忌。

accept本身是个快速的操作，但如果监听 fd 上同时有多条连接请求（网络上突发流量瞬间会堆积一大把），一次accept可能只取走了一个连接，剩下的请求还在内核的 accept 队列里排队。在 LT 模式下问题不大，因为下次epoll_wait还会通知你；但在 ET 模式下，如果只accept一次就完事，剩余排队连接可能一直得不到处理，表现为“客户端连上了但服务器迟迟不响应”。

所以稳妥的做法是在accept事件里用while循环持续accept，直到返回EAGAIN。这跟你处理读取事件的逻辑是同一个道理。用非阻塞监听 fd 的好处在这里就体现出来了。

6.4 经验三：EPOLLRDHUP：一个能帮你提前感知断开的事件

EPOLLRDHUP是较新内核提供的一种事件，用于检测对端关闭连接。它与EPOLLIN的区别在于：当对端正常关闭（FIN 包到达）时，epoll 会触发EPOLLRDHUP，但如果只关心EPOLLIN，你只会收到 read 返回 0 的结果。

为什么要单独关心这个事件？因为有些场景下，对端关闭连接但发送缓冲区里已经没有数据了，你不需要read就知道连接断了。提前感知断开，可以立即清理资源，减少无效的read调用。不少高性能框架都会注册EPOLLIN | EPOLLRDHUP，并在事件处理里优先判断EPOLLRDHUP。

另外还有一个冷门但好用的标志：EPOLLONESHOT。它表示该 fd 上的事件触发一次后，会自动从 epoll 中注销，需要再次调用EPOLL_CTL_MOD重新注册才能继续收到事件。这个标志在“多线程分发处理”模型里非常实用：一个 fd 的事件被线程 A 拿走处理后，通过EPOLLONESHOT自动屏蔽掉后续事件，等线程 A 处理完再重新注册，可以天然避免多线程同时处理同一个 fd 的竞态问题。CPU 密集的场景下，这个模式能大幅降低锁竞争开销，不过代价是代码复杂度会上升。

7. 写在最后：epoll 之外，你还需要知道什么

关于 epoll 本身的内容到这里就讲得差不多了。最后说一点我这些年在实战中的体会。

很多人面试的时候能把“epoll 是红黑树 + 就绪链表”“LT 和 ET 的区别”背得很熟，但真到了线上问题排查时还是会手足无措。我觉得根本原因在于：epoll 不是一个孤立的 API，它背后牵扯着非阻塞 I/O、用户态与内核态的数据拷贝、事件驱动编程思想、多线程协作模型这一整套知识网络。你只有把每一个细节都揉碎了、亲手写过几版代码、踩过几次坑，才能真正理解“为什么设计成这样”。

我记得第一次把 epoll 服务器压测跑到 5 万并发连接时的兴奋感——单线程，CPU 占用不到 30%，还能流畅地处理请求。那是一种“原来如此”的通透感。希望你也能写出自己满意的 epoll 程序。

如果你已经把这篇文章里的代码跑通了，下一步建议去读一读 Redis 的事件驱动源码（ae.c）或者 Nginx 的ngx_epoll_module.c，看看工业级的实现里是怎么组织事件循环和内存管理的。沿着这条路走下去，你对 epoll 的理解会再上一个台阶。