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 的工作线程后面挂一个线程池。这篇文章先讲单线程模型线程池扩展会在后面讨论。整个服务器的核心事件循环可以拆成四步创建 socket绑定端口监听连接把监听 fd 加入 epoll关注EPOLLIN事件表示有新的连接到达。进入 while 循环调用epoll_wait阻塞等待事件。遍历返回的事件数组如果是监听 fd 上有事件说明有新连接调用accept接受连接并把新的连接 fd 加入 epoll。如果是普通连接 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 traceepoll_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 默认的工作模式是 LTLevel 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高性能但也更“难搞”ETEdge 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; } } }我把这个处理逻辑整理成一个对比表对比维度LT 水平触发ET 边缘触发通知次数有数据未读完就一直通知只在数据到达/状态变化时通知一次是否要求非阻塞 fd非必须必须是否要求 while 读取不强制但建议必须否则丢数据系统调用次数多少编码难度低容错好高对细节要求苛刻适用场景一般业务服务器高并发、高性能网关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 缓冲区在绝大多数情况下都是“可写”的一旦你注册了EPOLLOUTepoll_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:786f2tfd表示注册在该 epoll 实例上的 fd 编号events是注册的事件掩码19 是十进制转十六进制是 0x13即 EPOLLIN 0x1 与 EPOLLRDHUP 0x2 与 EPOLLONESHOT 0x1000 的组合data显示的是注册的 data 值。这些信息在排查“为什么这个连接没有事件上报”时非常有用。strace是另一个必备工具。strace -p pid -e traceepoll_wait,epoll_ctl,read,write可以看到系统调用级别的每一次事件循环行为。我曾经用它抓到过一个诡异 bug一个 fd 被epoll_ctl删掉之后又因为代码逻辑错误被加入到了另一个 epoll 实例两个事件循环同时等待它。这种多重注册的问题在代码里很难通过肉眼发现但 strace 一看就明白。6. epoll 使用中的高频问题与避坑实录6.1 问题速查表我把过去在 epoll 编程中遇到过的典型问题整理成了一个速查表方便你直接对照排查。现象可能原因解决方案新连接无法 accept监听 fd 没注册或不关心 EPOLLIN检查 epoll_ctl 注册逻辑用 fdinfo 确认程序 CPU 100%但连接数不多EPOLLOUT 注册后未移除按需注册 EPOLLOUT写完立即删除ET 模式下丢数据没有用 while 循环读完改为循环读遇 EAGAIN 退出read 返回 -1 但程序崩了把 EAGAIN 当成了真正的错误判断 errno EAGAIN 再决定重试还是报错accept 返回的 fd 是阻塞的新 socket 不继承监听 fd 的非阻塞属性accept 后单独设置 O_NONBLOCK连接关闭后 epoll 还反复上报fd 在 TIME_WAIT 状态或有数据残留close 前移除 EPOLL_CTL_DEL确认 read 返回 0 再 close多线程下事件重复消费多个线程同时 epoll_wait 同一个实例使用 EPOLLEXCLUSIVE 或每线程独立 epoll内存不断增长data.ptr 指向的上下文对象没有 free在 close 和 EPOLL_CTL_DEL 后释放内存6.2 经验一ET 模式 非阻塞 socket 的“读不完”教训我在做推送网关时第一次用 ET 模式就踩了坑。当时的设计是收到客户端请求后从后端拉数据再推给客户端数据包最大的时候有几十 KB。我的读取缓冲区是 4KBread一次只读一小段就返回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 的理解会再上一个台阶。