前阵子帮一个朋友排查网关服务响应延迟飙升的问题。连接数到几千之后客户端请求偶尔要几百毫秒才返回strace挂上去发现程序大部分时间都卡在epoll_wait上而真正处理事件的线程池却饿得嗷嗷叫。翻代码才发现他一口气把events数组填满512个就返回循环每个连接最多只处理一个事件结果一个忙碌连接疯狂触发可读事件把其他空闲连接全部饿死。问题根源就是对epoll_wait的就绪报告机制理解不透。这类问题在网络上问得特别多但大多数资料只讲epoll_wait会等待事件发生很少把它和水平触发、边缘触发、超时语义、事件数组布局这些细节串起来讲。这篇文章就专门冲着epoll_wait来把它的参数、返回值、内核行为、实用编码套路完整过一遍适合正在看网络库源码、准备面试翻车、或者被线上问题折磨的同学参考。1. 先搞清楚epoll_wait在网络事件模型里的位置1.1 为什么select/poll时代会让人难受老一代网络服务用的select和poll本质上都是用户态把fd集合传给内核内核遍历检查每个fd是否有事件然后返回。这个过程有两个致命伤一是每次调用都要把整个fd集合从用户态拷贝到内核态fd数量上来后拷贝开销巨大二是内核不知道你关心哪些fd、关心什么事件每次都是无差别全量扫描复杂度是O(n)。select还有一点特别坑fd_set是位图默认大小1024虽然可以调整宏重新编译内核但本质上改变不了每次全量扫描拷贝的模型。poll用pollfd数组解决了数量上限却依然要在每个fd上轮询。C10K问题里最难啃的就是这种每次都要过一遍全量连接的心智模型。epoll的出现把O(n)变成了O(1)但很多资料只强调epoll是事件驱动、由内核直接告诉你哪个fd就绪却没说清楚这个能力是靠什么实现的。这里先给结论epoll通过三个系统调用构建了一套内核态事件订阅与通知机制epoll_wait正是获取通知结果的那一步。1.2 epoll_wait与epoll_create、epoll_ctl的分工一次完整的epoll使用分成三步int epfd epoll_create(1); // 创建epoll实例返回文件描述符 struct epoll_event ev; ev.events EPOLLIN; // 注册读事件 ev.data.fd client_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, ev); // 向epoll实例注册某个fd的事件 struct epoll_event events[128]; int n epoll_wait(epfd, events, 128, -1); // 等待事件产生并把就绪事件拷贝出来epoll_create负责创建内核中的红黑树和就绪链表。epoll_ctl负责往红黑树上增删改监听的fd及事件类型。epoll_wait则负责等待当红黑树上注册的fd没有任何一个就绪时当前进程/线程进入睡眠一旦有fd就绪内核把该fd对应的epoll_event挂到就绪链表上并唤醒等待者epoll_wait返回并把这批就绪事件拷贝到用户态events数组。换个生活化的类比epoll_ctl像是在餐厅点菜把想吃的菜fd和事件登记给后厨epoll_wait是坐在座位上等菜菜好了服务员会端到你面前的托盘events数组。如果一道菜都没好你就只能干等如果同时好几道菜好了服务员会一起端出来。这个谁点的菜好了就端谁的机制就是和select/poll那种把整个菜单翻一遍看看那些菜做好了的本质区别。2. 逐个拆解epoll_wait签名里的每个坑2.1 maxevents该传多少不是越多越好epoll_wait的原型是#include sys/epoll.h int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);maxevents表示本次调用最多拷贝多少个就绪事件到events数组。这个值必须大于0。它最大的作用是限制单次返回的事件数量避免把用户态缓冲区撑爆。实际工程里maxevents通常设置为一个适中的常数比如128、256、512。设得太小比如16如果网络很忙一次有几百个连接同时就绪你需要反复调用epoll_wait才能取完虽然事件不会丢LT模式下没处理完的事件会一直报告但CPU循环次数会增加。设得太大比如和连接数一样大也未必是好事因为events数组的内存是调用者分配的数组越大占用内存越多而且一次性拷回大量事件后用户态处理每个事件还要做额外的系统调用比如read、write这会造成不小的瞬时压力。还有一点容易被忽略maxevents只能限制本次返回的事件数量不能限制内核就绪链表上挂了多少事件。就算你传1内核照样会把所有就绪事件都挂到内部链表只是本次只拷1个出来剩下的还在链表里下次再取。这是很多并发量估算失误的来源评估性能峰值时不要把maxevents当成吞吐上限。2.2 timeout的三种语义-1、0、正数timeout参数的单位是毫秒表面上很简单实际用错的人很多。timeout -1永久阻塞直到至少有一个事件就绪才返回。适合纯粹的阻塞式事件循环程序没有其他定时任务需要处理。timeout 0完全不阻塞立即返回。即使没有事件也立刻返回0。这个用法适合轮询一次的场景比如想在不阻塞主线程的情况下快速检查一下有没有网络事件。timeout 0最多阻塞这么多个毫秒超时后即使没有事件也返回0。这是最常用、也最容易出错的模式。很多人以为timeout100就是100ms内返回其实它暗含了如果期间有事件会提前返回这个语义。epoll_wait不是精确的睡眠定时器它保证的是至少等到timeout毫秒或者有事件发生可能提前很久返回。比如timeout传100ms如果第5ms就有事件了它第5ms就返回。想在epoll_wait里做精确计时器必须先处理完就绪事件再看剩余时间。另外要注意timeout返回值返回0表示超时没有事件。返回-1表示出错。发生超时不是错误很多人把返回0当成空转然后加日志结果流量稍微波动日志就刷爆。一个可靠的事件循环应该把返回0当作正常的空闲分支处理比如顺便执行定时任务。2.3 events数组的分配与生命周期events指针指向一块用户态内存由调用者分配epoll_wait只是往里面填充数据。这块内存必须是可写的并且在epoll_wait调用期间不能被其他线程释放。最常见的坑是在栈上分配一个数组没问题但如果作为类成员或动态内存要确保生命周期覆盖epoll_wait返回之后的事件处理过程——处理完这批事件前别急着释放数组。epoll_event结构体在Linux上的定义是struct epoll_event { uint32_t events; /* epoll事件类型如EPOLLIN */ epoll_data_t data; /* 用户数据通常放fd或指针 */ };其中epoll_data_t是一个联合体typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t;这个联合体是刻意设计的可以在注册时存一个指针在事件返回时原样带回来。很多人一直只用data.fd其实如果你用C写网络库通常会存一个对象的this指针比如ev.data.ptr conn_obj; // 注册时 // epoll_wait返回后 conn_obj events[i].data.ptr;这样可以避免根据fd再查一遍映射表直接拿到连接对象。但要注意如果存ptr必须保证ptr指向的对象在删掉fd之前一直是有效的否则会造成悬垂指针这是libevent、libuv这类框架里最容易触发use-after-free的地方。3. 从内核视角看epoll_wait如何拿到事件3.1 就绪链表与回调机制为什么是O(1)epoll能高效拿到就绪事件核心在三个数据结构一棵红黑树、一个就绪链表、一个等待队列。红黑树挂在epoll实例上存储所有通过epoll_ctl注册的fd每个节点保存fd和对应的等待队列项。就绪链表专门存放已经发生了感兴趣事件的fd。等待队列则是当epoll_wait被调用时当前进程挂到epoll实例的等待队列上进入睡眠。关键动作在文件系统层的回调函数。当socket上有数据到达时底层驱动会在协议栈处理流程中唤醒socket的等待队列而epoll在注册fd时会把一个回调函数ep_poll_callback挂到该socket的等待队列里。这个回调函数做的事情很简单把当前fd对应的epitem从红黑树状态切换到就绪链表状态然后唤醒在epoll_wait上等待的进程。于是epoll_wait返回时内核不需要遍历所有注册的fd只需要把就绪链表上挂着的节点一个个拷到用户态就行了。链表取头部是O(1)这就是epoll_wait号称O(1)的真正来源——它只处理已经就绪的那一小撮而不是所有fd。这个机制还带来一个隐藏性质就绪链表的顺序是事件发生的先后顺序。ep_poll_callback把节点挂到链表尾部所以epoll_wait返回的events数组里顺序基本反映事件发生的时间只是批量返回时可能混入同一时刻的多个事件。你要是依赖这个顺序做公平调度还是可以的但不要把它当成严格的时间戳。3.2 等待与唤醒epoll_wait睡眠时谁叫醒它当没有任何fd就绪时epoll_wait调用会走到内核的schedule函数把当前进程置为睡眠状态。睡眠期间如果某个注册的socket收到数据包网络协议栈在处理完包后调用该socket等待队列上的回调也就是ep_poll_callback它会把epitem加入就绪链表然后调用wake_up唤醒正在epoll等待队列上睡眠的进程。进程被唤醒后会进入运行队列重新调度执行。内核会检查就绪链表是否为空如果不为空就收集事件并拷贝到用户态。这里有一个很小的窗口进程被唤醒后可能发现就绪链表上的事件已经被另一个线程取走了多线程同时调用epoll_wait或者刚被唤醒又有新事件加入这些都不会导致事件丢失只是处理次序会稍有变化。有趣的是唤醒粒度。epoll_wait返回前内核会把就绪链表上的所有事件一次性拷完然后清空这个链表。如果事件太多maxevents限制了拷贝个数那么剩余事件会留在链表中等待下次调用。设计上这是合理的宁可多睡几次也不能一次把用户态数组塞爆。3.3 事件合并与边界epoll_wait不会让你看到什么某些人会把epoll_wait事件误解为读事件报告一次后续必须等新数据才报告。这其实是LT和ET的差异问题放到下一章讲。这里先说另一个边界EPOLLOUT事件是可写事件它的就绪条件很特殊。一个socket默认是可写的如果注册了EPOLLOUT那么当你调用epoll_wait时它几乎总是立刻返回可写事件——因为发送缓冲区有空位。所以EPOLLOUT的正确注册时机应该是在你写入数据时发现缓冲区满了才去注册EPOLLOUT等可写通知一旦写完立刻注销否则会变成忙轮询让epoll_wait一直返回写事件CPU空转。还有一类事件不在epoll_event.events里常规讨论但epoll_wait会把它当作就绪事件返回EPOLLERR和EPOLLHUP。socket出错或者对端挂断内核也会把这些状态触发为事件。很多新手只监听EPOLLIN结果对端异常closeepoll_wait什么都没返回连接变成僵尸。正确做法是把EPOLLERR和EPOLLHUP也加入关注或者在事件返回后用getsockopt检查SO_ERROR。4. LT和ET同样的事件截然不同的读法4.1 水平触发下epoll_wait的重复通知水平触发Level-TriggeredLT是epoll的默认工作模式。它的语义是只要fd上有未处理完的事件每次调用epoll_wait都会返回该fd的事件。反复通知直到你将对应的数据全部读走。举个例子socket收到8KB数据你只读了4KB剩余4KB还在内核接收缓冲区里那么第二次调用epoll_wait时会再次返回EPOLLIN提醒你还有数据没读完。就算数据全读完了只要对端又发来1字节epoll_wait会继续返回EPOLLIN。这种模式的优点是即使你一次没处理完也不会丢事件很适合新手和简单的请求-响应式服务处理不过来就下轮再处理。但它也有个隐患如果程序在LT模式下处理EPOLLIN事件时每次都只读一小部分就会导致内核频繁报告同一个fd的事件。极端情况下一个慢吞吞的收包逻辑会反复触发epoll_wait返回同一个连接的事件其他连接被挤压在后面。这其实就是我在开头提到朋友那个网关的另一个诱因。4.2 边缘触发下epoll_wait只通知一次边缘触发Edge-TriggeredET模式下epoll_wait只在状态发生变化的那一次返回事件。具体到读事件只有当fd从未就绪变为就绪时才通知一次。如果本次通知后你没把数据读完内核不会再次通知除非又有新数据到达产生一次新的状态跳变。代码上设置ET需要在注册时给events加上EPOLLETev.events EPOLLIN | EPOLLET;ET模式最大的坑是读到EAGAINWOULD BLOCK才算完。因为只通知一次你必须把当前缓冲区里的数据尽量读光否则剩下的数据要等下一次新数据到来才会再触发。为了读完数据必须把socket设置为非阻塞然后循环read直到返回-1且errno为EAGAIN。// ET模式下处理读事件 while (1) { ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { handle(buf, n); } else if (n -1 errno EAGAIN) { break; // 数据读完了 } else if (n -1 errno EINTR) { continue; // 被信号打断重试 } else { // 真正出错 close(fd); break; } }这个while循环是ET模式的标准姿势。如果是LT模式你即使只read一次也不会有严重问题因为下次epoll_wait还通知你。ET模式下想偷懒用阻塞socket大概率会卡在read上因为某个瞬间没有数据可读时read会阻塞整个事件循环就挂了。4.3 实际项目里怎么选LT适合代码量小、逻辑简单的服务或者事件处理函数本身很轻量的场景。比如常见的echo服务、日志上报服务LT模式加上非阻塞socket就很稳不容易写出低级bug。ET适合追求高吞吐、低延迟的场景。由于减少了内核重复通知的开销ET在高并发、大数据包转发场景下有一定的性能优势还经常伴生一个优化每次事件只唤醒一次而不是反复唤醒能减少上下文切换。代价是代码必须非常小心任何一次漏读都会造成数据滞留而且容易出现明明连接还有数据但epoll_wait不再返回事件的诡异问题。根据我个人在网关项目里的经验如果是刚上手优先用LT把业务逻辑摸透了再换ET。真正的性能瓶颈往往不在epoll通知那一层而在用户态的数据处理和内存拷贝。5. 实战编码写出健壮的epoll_wait调用代码5.1 EINTR被信号打断是常态怎么处理epoll_wait和绝大多数阻塞系统调用一样会被信号打断。当进程收到一个信号并且信号处理函数执行完毕后epoll_wait可能返回-1errno为EINTR。很多人的事件循环一遇到EINTR就直接break退出导致服务莫名其妙挂掉。正确姿势是检测到EINTR后继续调用epoll_waitfor (;;) { int n epoll_wait(epfd, events, maxevents, timeout); if (n 0) { if (errno EINTR) { continue; // 被信号打断继续等待 } // 其他错误需要处理 break; } if (n 0) { // 超时处理 continue; } handle_events(events, n); }如果程序里用了定时器信号比如setitimer或者频繁使用signal函数EINTR出现的频率会非常高。不加EINTR容错的事件循环跑不到几天就会在某个信号到来时崩掉。5.2 批量事件处理一次循环里如何分配工作epoll_wait返回一个数组里面包含n个事件。处理时要小心的事件合并场景是一个fd可能同时返回EPOLLIN和EPOLLOUT这时你要决定先读还是先写。一般来说优先读因为收到数据意味着对端还在等响应读完后可以再考虑写但也要避免死循环如果对端一直发数据你的写操作可能永远排不上。工程上通常是把读写信息都记录下来读优先、写其次并且保证同一个fd的读写不会同时死锁。还有一类细节当n很大时比如epoll_wait一次返回好几百个事件如果处理每个事件都做一次非阻塞的read或write那个循环本身可能阻塞很久期间新事件进不来。一个缓解方案是单次事件循环里设置最大处理事件个数比如只处理128个事件处理完立即回到epoll_wait让等待队列上的进程尽快被唤醒。尤其使用ET模式时本来就要求数据处理尽快完成避免阻塞在用户态太久。5.3 失效fd的清理EPOLLHUP和EPOLLERRepoll_wait返回的事件中EPOLLHUP表示对端挂断连接此时socket实际上已经不可读写直接把fd关闭并从epoll实例中删除即可。EPOLLERR表示socket发生错误可以使用getsockopt(SO_ERROR)获取具体错误码再决定是close还是继续使用。需要特别注意即使你只注册了EPOLLIN如果对端close时epoll也会返回EPOLLHUP或EPOLLERR。很多以EPOLLIN注册为主的代码在事件处理函数里只判断EPOLLIN遇到EPOLLHUP就忽略这会造成连接fd泄漏。每次循环都应该像这样处理for (int i 0; i n; i) { int fd events[i].data.fd; uint32_t ev events[i].events; if (ev (EPOLLHUP | EPOLLERR)) { // 先关闭连接清理上下文 close(fd); continue; } if (ev EPOLLIN) { handle_read(fd); } if (ev EPOLLOUT) { handle_write(fd); } }还有一个容易踩坑的地方EPOLLIN和EPOLLHUP可能同时出现在同一个events[i]里如果你先处理EPOLLIN处理过程中发现对端已关闭写回响应时会得到EPIPE所以写数据时也要捕捉EPIPE信号或设置MSG_NOSIGNAL避免进程被SIGPIPE搞挂。5.4 常见问题排查清单如果你发现epoll_wait相关的程序行为怪异按下面顺序排查大概率能定位现象可能原因排查方法epoll_wait一直返回0timeout传错或事件注册错误检查timeout是否为0检查epoll_ctl是否成功epoll_wait阻塞不返回注册的fd没有任何事件strace看epoll_wait参数确认fd是否有效读事件一直触发LT模式下未读完数据查看read返回值和缓冲区剩余量某连接数据滞留不触发ET模式下未读至EAGAIN检查是否循环read直到EAGAIN返回EPOLLIN但没有数据可能有EPOLLERR/EPOLLHUP打印events[i].events全部位多线程epoll_wait后事件重复处理无锁处理同一fd事件保证同一fd只由一个线程处理6. epoll_wait在主流网络框架中的姿态6.1 单线程事件循环epoll_wait就是大管家最常见、也是最经典的使用方式是用单线程运行一个死循环调用epoll_wait等待事件然后逐个处理。Redis就是一个典型例子它的aeEventLoop里核心就是用了epoll_wait来收集文件事件和时间事件做到单线程处理海量连接。单线程模型的优势是简单不需要考虑加锁所有事件处理都在一个上下文里串行完成不会出现竞态。缺点是单个事件处理不能耗时太长否则整个服务会卡顿。所以在这种架构里epoll_wait的超时值通常不会设置成-1永久阻塞而是设成几十毫秒便于定期处理定时任务。实际操作中我倾向于把timeout设成100ms左右既不会让epoll_wait频繁空转又能保证定时任务的最大时延在100ms内。如果定时精度要求更高可以拆成更小的timeout代价是CPU空转率上升。6.2 多线程同时调用epoll_wait行得通吗epoll_wait可以被多个线程同时调用同一个epoll实例上多个线程一起wait这在Linux上是允许的。但并发调用会带来两个问题一是多个线程可能同时取到同一个fd的事件如果缺乏同步同一事件会被重复处理二是线程间需要协调谁来处理哪个fd。一种常见方案是通过EPOLLEXCLUSIVE让内核在唤醒线程时只唤醒一个等待者避免多个线程同时回来争抢事件。另一种方案是每个线程维护自己的eventfd用eventfd来唤醒指定线程再通过任务队列分发fd。这些方案的共同点是epoll_wait本身只是一个事件分发入口真正的工作分配逻辑必须建在它之上。对于大多数业务场景更实际的多线程设计是一个主线程只负责epoll_wait收集事件把事件交给线程池处理自己绝不处理耗时业务。这样做既能享受多线程并行又能避免多个线程同时操作epoll实例带来的复杂度。6.3 IO线程与业务线程的分离策论业界广泛采用一种IO线程 业务线程池的双层结构。IO线程里跑一个epoll_wait死循环只做轻量级的收发指令和数据搬移。每当epoll_wait返回一批事件IO线程把事件包装成任务投递给业务线程池。业务线程池里的线程执行真正的业务逻辑比如解析协议、查数据库、组装响应。这个设计的核心原因是epoll_wait返回的事件非常密集且有实时性要求一旦处理耗时太长新的事件就会被堵住。真正耗时任务巧妙地从epoll_wait的处理循环中剥离开等业务线程处理完如果要写回数据再把写事件挂到epoll上通过IO线程的epoll_wait来回调完成写操作。在实现上要注意业务线程和IO线程通信时尽量用无锁队列加eventfd唤醒。比如业务线程计算完结果把要发送的数据写入一个队列然后通过eventfd写入一字节IO线程的epoll_wait立刻因为这个eventfd的可读事件而返回进而从队列里取出数据发送。这样epoll_wait就不仅仅是等网络事件还承担了等内部任务唤醒的职责这也是很多网络框架内部eventfd的用法。7. 我实际调优epoll_wait的几点经验写到最后分享几个从线上问题里积累的细节。第一epoll_wait返回的事件数量和耗时并不是线性关系。最大头的时间通常不是内核收集事件而是用户态处理IO操作本身。我在一个代理服务上做过压测把maxevents从64改成256吞吐量几乎没变化但把业务处理中的数据拷贝优化了一下性能翻倍。调优别只在epoll_wait上钻牛角尖。第二如果代码里EPOLLET模式和阻塞socket并存那是一个定时炸弹。ET模式下必须配合非阻塞socket不然很容易在read/write上卡住整个事件循环。检查这个兼容性是所有epoll代码review的第一条。第三epoll_wait返回的事件有瞬时性。你拿到EPOLLIN事件后数据可能已经被其他线程或者在同一轮循环里的前一个read读走了。所以在多线程场景下不要把有事件当成一定有数据可读的绝对依据要用非阻塞read配合EAGAIN兜底。第四做网络服务能用简单模型就不用复杂模型。LT模式加非阻塞socket加单线程事件循环能解决绝大多数中低并发场景。等真的压到几十万连接、每毫秒都有大量事件时再引入ET、多线程、多epoll实例也不迟。项目的复杂度要跟着实际瓶颈走而不是跟着技术潮流走。