1. 从“阻塞”到“非阻塞”为什么我们需要epoll如果你写过网络服务器程序尤其是高并发的服务端那你一定对“C10K”问题不陌生。简单来说就是一台服务器如何同时维持上万个客户端连接。用最传统的“一个连接一个线程/进程”的阻塞IO模型当连接数暴涨时线程上下文切换的开销会迅速耗尽系统资源服务器响应变得极其缓慢甚至崩溃。这时候IO多路复用技术就成了救星。它允许一个线程同时监控多个文件描述符比如网络套接字的IO状态哪个就绪了就处理哪个。Linux下早期的解决方案是select和poll但它们都有明显的性能瓶颈每次调用都需要把整个监控的文件描述符集合从用户态拷贝到内核态内核遍历整个集合来检查状态再拷贝回用户态。当连接数很大时这个遍历和拷贝的开销是线性的效率很低。epoll就是为了解决这个痛点而生的。它通过三个系统调用epoll_create,epoll_ctl,epoll_wait建立了一个高效的事件通知机制。内核会维护一个“兴趣列表”通过epoll_ctl添加当这个列表中的某个描述符状态发生变化比如有数据可读时内核会将其放入一个“就绪列表”。当用户调用epoll_wait时内核只需检查这个就绪列表并将其中的事件返回给用户。这个过程避免了无谓的遍历和全量数据拷贝性能与活跃的连接数成正比而非总连接数这在高并发、低活跃的场景下优势巨大。而“非阻塞IO”是使用epoll的前提。想象一下如果你用epoll监控了一个套接字epoll_wait告诉你这个套接字可读了你兴冲冲地去调用read结果这个read操作本身是阻塞的比如数据还没完全到达那么你的整个线程就会被挂起epoll带来的多路复用优势瞬间荡然无存。所以我们必须将套接字设置为非阻塞模式O_NONBLOCK这样read/write等操作在无法立即完成时会立刻返回一个错误如EAGAIN或EWOULDBLOCK而不是阻塞等待从而把控制权交还给事件循环去处理其他就绪的事件。2. 水平触发与边沿触发两种截然不同的事件通知哲学这是理解epoll编程模型的核心也是新手最容易混淆和踩坑的地方。我们可以用一个生活中的按钮来类比水平触发Level-Triggered, LT这是epoll的默认模式。它就像一个带状态指示灯的按钮。只要按钮处于“按下”状态对应内核缓冲区有数据可读指示灯就一直亮着epoll_wait就会一直报告这个事件。你读一次数据可能只读了一部分只要缓冲区里还有数据下次调用epoll_wait时它依然会通知你这个套接字可读。边沿触发Edge-Triggered, ET这种模式更像是一个不带状态指示灯的瞬时按钮。它只在按钮状态发生变化的那一刻发出一个信号。具体来说只有当监控的文件描述符状态从不可读变为可读或者从不可写变为可写时epoll_wait才会返回一次。之后无论缓冲区里是否还有数据只要状态没有再次发生变化比如从空变为有数据epoll_wait就不会再通知你。2.1 两种模式的对比与选择特性水平触发LT边沿触发ET通知时机只要条件满足缓冲区有数据/可写持续通知。仅在状态变化时空-有数据不可写-可写通知一次。编程复杂度较低。可以多次、分批读取数据不容易遗漏事件。较高。必须在一次通知中循环读取或写入直到出错EAGAIN否则会永久丢失事件。性能潜力可能略低。因为只要数据没读完内核每次都要检查并通知产生一定开销。理论上更高。减少了内核向应用空间传递事件的次数尤其适合数据量大的突发IO。常见应用默认模式对编程友好适用于大多数场景。需要极致性能的高并发服务器如Nginx默认使用ET要求开发者对IO有更精确的控制。选择ET模式通常意味着你追求极致的性能并且愿意承担更复杂的编程逻辑来确保数据的完整性。它强迫你采用“非阻塞IO循环读写直到EAGAIN”的模式这恰恰是最高效利用CPU的方式。3. 边沿触发模式下的“生死状”必须一次性读完或写完这是ET模式最核心、也是最容易出错的原则。因为内核只在你监听的描述符状态发生变化时通知你一次。我们以可读事件为例假设客户端发送了100KB数据。内核接收缓冲区从空变为有数据触发一次ET可读事件。你的epoll_wait返回你开始处理这个套接字。如果你在read循环中只读取了50KB就因为某种原因比如业务逻辑处理退出了那么剩下的50KB数据会留在内核缓冲区里。关键点来了只要这个套接字上没有新的数据从对端到达即状态没有再次从“可读”变为“不可读”再变回“可读”epoll_wait就永远不会再为这个套接字报告可读事件。剩下的50KB数据就会永远“沉睡”在内核缓冲区直到连接关闭。因此在ET模式下处理可读事件的标准范式必须是// 假设 events[n].data.fd 是触发事件的套接字fd while (1) { ssize_t count read(events[n].data.fd, buf, sizeof(buf)); if (count -1) { // 如果 errno 是 EAGAIN 或 EWOULDBLOCK说明本次通知的数据已经全部读完 if (errno EAGAIN || errno EWOULDBLOCK) { break; // 跳出循环处理完毕 } // 其他错误如连接断开 (ECONNRESET) close(events[n].data.fd); break; } else if (count 0) { // 对端关闭连接 close(events[n].data.fd); break; } else { // 成功读取到 count 字节数据进行业务处理 process_data(buf, count); // 注意继续循环尝试读取更多直到触发 EAGAIN } }对于可写事件ET模式下通常不会默认监听可写只在需要时添加逻辑类似当你需要发送大量数据一次write无法写完时你会监听可写事件。当可写事件触发缓冲区从不可写变为可写你必须循环write直到数据发完或遇到EAGAIN。发送完毕后应立即从epoll监听列表中移除对可写事件的监听否则只要缓冲区一直可写在LT模式下会持续触发在ET模式下虽然不会持续触发但保留无用的监听也是浪费。注意这个“循环直到EAGAIN”的模式是ET模式的铁律。忘记它就等于埋下了数据丢失或连接僵死的定时炸弹。4. 实战构建一个ET模式的echo服务器让我们通过一个简单的TCP echo服务器客户端发什么服务器回什么来串联所有概念。这里只展示核心代码逻辑省略错误处理的细节以突出重点。4.1 基础设置创建epoll实例与监听套接字#include sys/epoll.h #include fcntl.h #include unistd.h // ... 其他头文件 #define MAX_EVENTS 64 #define PORT 8080 int main() { int listen_fd, epoll_fd; struct epoll_event ev, events[MAX_EVENTS]; // 1. 创建监听套接字 (socket, bind, listen) - 略 listen_fd create_and_bind(PORT); make_nonblocking(listen_fd); // 将监听套接字也设为非阻塞 listen(listen_fd, SOMAXCONN); // 2. 创建epoll实例 epoll_fd epoll_create1(0); if (epoll_fd -1) { perror(epoll_create1); exit(EXIT_FAILURE); } // 3. 将监听套接字添加到epoll监听可读事件并设置为边沿触发(EPOLLET) ev.events EPOLLIN | EPOLLET; // EPOLLIN 可读 EPOLLET 边沿触发 ev.data.fd listen_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, ev) -1) { perror(epoll_ctl: listen_fd); exit(EXIT_FAILURE); }这里的关键是ev.events EPOLLIN | EPOLLET;。我们将监听套接字也设置为ET模式。为什么监听套接字也需要ET因为对于accept来说ET模式意味着只有在新的连接到来即监听队列从空变为非空时我们才会收到通知。如果我们在一次通知中没有accept完所有等待的连接并且没有新的连接再到来那么剩下的连接请求就不会被处理。因此对于监听套接字在ET模式下也必须循环accept直到返回EAGAIN。4.2 设置文件描述符为非阻塞模式的辅助函数int make_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) { perror(fcntl F_GETFL); return -1; } flags | O_NONBLOCK; if (fcntl(fd, F_SETFL, flags) -1) { perror(fcntl F_SETFL); return -1; } return 0; }这个函数通过fcntl系统调用为文件描述符添加O_NONBLOCK标志这是配合ET模式工作的基石。4.3 事件循环处理连接与数据while (1) { int nfds epoll_wait(epoll_fd, events, MAX_EVENTS, -1); // -1 表示无限等待 if (nfds -1) { perror(epoll_wait); break; } for (int i 0; i nfds; i) { // 4.3.1 处理新的连接请求 (监听套接字可读) if (events[i].data.fd listen_fd) { // ET模式必须循环accept直到没有新连接 while (1) { struct sockaddr_in client_addr; socklen_t addrlen sizeof(client_addr); int conn_fd accept(listen_fd, (struct sockaddr*)client_addr, addrlen); if (conn_fd -1) { // 如果没有更多pending的连接了accept会返回-1errno为EAGAIN if (errno EAGAIN || errno EWOULDBLOCK) { break; // 本次通知的所有连接已处理完 } else { perror(accept); break; } } // 将新连接套接字设为非阻塞 make_nonblocking(conn_fd); // 将新连接添加到epoll监听可读事件使用边沿触发 ev.events EPOLLIN | EPOLLET; ev.data.fd conn_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, ev) -1) { perror(epoll_ctl: conn_fd); close(conn_fd); } printf(Accepted new connection on fd %d\n, conn_fd); } } // 4.3.2 处理客户端发来的数据 (连接套接字可读) else if (events[i].events EPOLLIN) { int conn_fd events[i].data.fd; char buffer[4096]; ssize_t total_read 0; // ET模式铁律循环读直到读完本次通知的所有数据 while (1) { ssize_t count read(conn_fd, buffer total_read, sizeof(buffer) - total_read - 1); if (count -1) { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据已全部读完 break; } // 真正的错误关闭连接 perror(read); close(conn_fd); break; } else if (count 0) { // 对端关闭了连接 printf(Connection closed on fd %d\n, conn_fd); close(conn_fd); // 注意这里应该从epoll中删除该fd (EPOLL_CTL_DEL)简单示例中略过 break; } else { total_read count; // 简单起见假设我们一次收完所有数据再回显。实际可能需处理粘包。 } } // 如果有读到数据准备回写 if (total_read 0) { buffer[total_read] \0; printf(Received on fd %d: %s\n, conn_fd, buffer); // 这里简化处理直接写回。如果一次写不完需要监听可写事件(EPOLLOUT | EPOLLET)并循环写。 // 为了演示ET写我们假设数据很小一次能写完。 // 更严谨的做法是将待发送数据放入conn_fd对应的缓冲区然后监听EPOLLOUT事件。 // 当EPOLLOUT触发时循环write直到数据发完或EAGAIN发完后取消对EPOLLOUT的监听。 write(conn_fd, buffer, total_read); } } // 4.3.3 处理可写事件 (本例未展示完整实现) else if (events[i].events EPOLLOUT) { // 获取对应conn_fd的发送缓冲区 // while (send_buffer_not_empty) { // ssize_t n write(fd, buffer, len); // if (n -1 errno EAGAIN) break; // // ... 更新缓冲区 // } // if (send_buffer_empty) { // // 取消监听EPOLLOUT事件 // ev.events EPOLLIN | EPOLLET; // epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd, ev); // } } } } close(listen_fd); close(epoll_fd); return 0; }这个循环是服务器的核心。它清晰地展示了ET模式下无论是处理新连接accept循环还是读取数据read循环都必须遵循“一次性处理完”的原则。对于可写事件的处理注释中也给出了典型的模式。5. 避坑指南ET模式下的典型陷阱与最佳实践在实际项目中仅仅理解原理和写出示例代码是远远不够的。下面这些坑我几乎每一个都踩过。5.1 惊群效应Thundering Herd问题在多进程/多线程服务器模型中多个工作进程/线程都epoll_wait在同一个epoll实例或同一个监听套接字上。当一个新连接到来时所有进程/线程都被唤醒但最终只有一个能成功accept其他都失败EAGAIN造成了不必要的上下文切换和资源竞争。解决方案Linux 3.9 内核支持EPOLLEXCLUSIVE在将监听套接字加入epoll时使用EPOLLIN | EPOLLET | EPOLLEXCLUSIVE。这可以保证一个事件只会唤醒一个正在epoll_wait的进程这是最优雅的解决方案。使用SO_REUSEPORT让每个工作进程创建自己的监听套接字并绑定到相同的IP和端口。内核会负责将新连接相对均匀地分发给这些套接字。每个进程有自己的epoll实例互不干扰。传统方案主进程accept后分发由一个主进程负责accept所有新连接然后通过进程间通信如管道、socketpair将连接描述符分发给各个工作进程。这是Nginx早期版本采用的方式。5.2 文件描述符耗尽与EMFILE问题当服务器压力极大瞬间建立大量连接时可能会达到进程或系统的文件描述符上限。此时accept会失败返回EMFILE错误。更糟糕的是在ET模式下这个错误可能发生在你的accept循环中。如果你直接break跳出循环但监听套接字的可读事件并未被处理完因为错误不是EAGAIN而你又没有关闭任何连接来释放描述符那么这个监听套接字的可读事件会永远丢失ET模式只通知一次导致后续即使有描述符可用也无法再接受新连接。解决方案预留一个“空投”描述符在程序启动时先打开一个无关的文件比如/dev/null或创建一个socketpair得到一个备用的文件描述符。当accept失败且errno EMFILE时先用close关闭那个预留的“空投”描述符为accept腾出一个位置。立刻再次调用accept接受这个新连接。立刻close掉这个刚接受的连接或者发送一个错误回复后关闭。重新打开“空投”描述符以备下次使用。这样做的好处是你及时处理了这次ET通知内核的“连接已接受”状态被清除监听套接字的状态得以更新。当下一次有新连接到来状态再次变化时你还能收到新的ET通知。5.3 数据读不完与“饥饿”问题问题在ET模式下你必须在一次通知中读完所有数据。但如果某个客户端发送数据的速率极快或者你单个read的缓冲区很小可能导致你长时间困在read循环里无法去处理epoll_wait返回的其他就绪事件造成其他连接的“饥饿”。解决方案设置合理的读取上限。在read循环中除了检查EAGAIN还应设置一个最大读取次数或最大读取字节数阈值。int read_loop_limit 0; const int MAX_READ_LOOP 1024; // 防止单个连接饿死其他连接 while (read_loop_limit MAX_READ_LOOP) { ssize_t count read(fd, buf, sizeof(buf)); if (count -1 errno EAGAIN) break; // ... 处理数据 } if (read_loop_limit MAX_READ_LOOP) { // 记录日志可能遇到了快速发送的客户端或者发生了DoS攻击迹象 }当达到上限后即使没有触发EAGAIN也主动跳出循环。这样保证了事件循环的公平性。剩下的数据会在下次该套接字再次有数据到达状态变化时通过新的ET通知来处理。5.4 连接关闭与错误处理在ET模式下对端关闭连接read返回0或发生错误read返回-1且不是EAGAIN时处理逻辑与LT模式一致关闭本地描述符并将其从epoll监控列表中移除EPOLL_CTL_DEL。关键点在于一定要在关闭描述符之前将其从epoll中删除。否则如果先close(fd)这个文件描述符可能会被系统快速复用比如分配给一个新打开的日志文件而epoll实例还在监控旧的fd值这会导致不可预知的混乱。正确顺序epoll_ctl(epoll_fd, EPOLL_CTL_DEL, conn_fd, NULL); // 1. 先从epoll移除 close(conn_fd); // 2. 再关闭文件描述符6. 性能调优与进阶思考当你掌握了ET模式的基本用法并成功避坑后可以考虑以下进阶优化6.1epoll_wait的超时时间epoll_wait的最后一个参数是超时时间毫秒。-1表示阻塞等待0表示立即返回非阻塞轮询。在高性能服务器中通常设置一个较小的超时值如1ms或0ms特别是在配合其他任务如定时器、信号处理时可以避免事件循环被完全阻塞实现更精细的调度。6.2 使用EPOLLONESHOT标志这个标志与EPOLLET结合使用效果最佳。EPOLLONESHOT告诉内核对于注册的这个文件描述符在epoll_wait返回一个事件后就禁用对该描述符的监控。直到你手动重新修改EPOLL_CTL_MOD这个描述符的事件掩码。为什么用它在多线程服务器中当epoll_wait返回一个事件后你可能会将这个连接丢给一个工作线程去处理。如果不使用EPOLLONESHOT在这个工作线程处理数据的过程中该连接可能又收到了新的数据触发了新的可读事件epoll_wait可能再次返回导致另一个线程也来操作同一个连接产生数据竞争。使用EPOLLONESHOT可以确保一个socket fd在任一时刻只被一个线程处理简化了并发编程模型。工作线程处理完数据后需要重新EPOLL_CTL_MOD这个fd来重新激活监控。6.3 与多线程/多进程模型的结合epoll本身是线程安全的一个epoll实例可以被多个线程同时调用epoll_wait惊群问题需用EPOLLEXCLUSIVE解决。更常见的多线程模型是主线程 多个工作线程主线程负责accept新连接然后通过轮询或锁竞争的方式将新连接的fd分配给一个工作线程。每个工作线程有自己的epoll实例负责监控分配给它的所有连接。这种模型需要处理负载均衡和线程间通信。多个对等的工作线程所有工作线程共享同一个监听套接字每个线程都有自己的epoll实例并都将监听套接字加入自己的epoll使用EPOLLEXCLUSIVE避免惊群。每个线程独立运行完整的事件循环。SO_REUSEPORT特性让这种模型变得简单高效。选择哪种模型取决于你的应用场景、编程复杂度和对性能极致的追求。ET模式为所有这些模型提供了高效的事件驱动基础。 深入理解epoll边沿触发模式：原理、陷阱与高并发服务器实践
1. 从“阻塞”到“非阻塞”为什么我们需要epoll如果你写过网络服务器程序尤其是高并发的服务端那你一定对“C10K”问题不陌生。简单来说就是一台服务器如何同时维持上万个客户端连接。用最传统的“一个连接一个线程/进程”的阻塞IO模型当连接数暴涨时线程上下文切换的开销会迅速耗尽系统资源服务器响应变得极其缓慢甚至崩溃。这时候IO多路复用技术就成了救星。它允许一个线程同时监控多个文件描述符比如网络套接字的IO状态哪个就绪了就处理哪个。Linux下早期的解决方案是select和poll但它们都有明显的性能瓶颈每次调用都需要把整个监控的文件描述符集合从用户态拷贝到内核态内核遍历整个集合来检查状态再拷贝回用户态。当连接数很大时这个遍历和拷贝的开销是线性的效率很低。epoll就是为了解决这个痛点而生的。它通过三个系统调用epoll_create,epoll_ctl,epoll_wait建立了一个高效的事件通知机制。内核会维护一个“兴趣列表”通过epoll_ctl添加当这个列表中的某个描述符状态发生变化比如有数据可读时内核会将其放入一个“就绪列表”。当用户调用epoll_wait时内核只需检查这个就绪列表并将其中的事件返回给用户。这个过程避免了无谓的遍历和全量数据拷贝性能与活跃的连接数成正比而非总连接数这在高并发、低活跃的场景下优势巨大。而“非阻塞IO”是使用epoll的前提。想象一下如果你用epoll监控了一个套接字epoll_wait告诉你这个套接字可读了你兴冲冲地去调用read结果这个read操作本身是阻塞的比如数据还没完全到达那么你的整个线程就会被挂起epoll带来的多路复用优势瞬间荡然无存。所以我们必须将套接字设置为非阻塞模式O_NONBLOCK这样read/write等操作在无法立即完成时会立刻返回一个错误如EAGAIN或EWOULDBLOCK而不是阻塞等待从而把控制权交还给事件循环去处理其他就绪的事件。2. 水平触发与边沿触发两种截然不同的事件通知哲学这是理解epoll编程模型的核心也是新手最容易混淆和踩坑的地方。我们可以用一个生活中的按钮来类比水平触发Level-Triggered, LT这是epoll的默认模式。它就像一个带状态指示灯的按钮。只要按钮处于“按下”状态对应内核缓冲区有数据可读指示灯就一直亮着epoll_wait就会一直报告这个事件。你读一次数据可能只读了一部分只要缓冲区里还有数据下次调用epoll_wait时它依然会通知你这个套接字可读。边沿触发Edge-Triggered, ET这种模式更像是一个不带状态指示灯的瞬时按钮。它只在按钮状态发生变化的那一刻发出一个信号。具体来说只有当监控的文件描述符状态从不可读变为可读或者从不可写变为可写时epoll_wait才会返回一次。之后无论缓冲区里是否还有数据只要状态没有再次发生变化比如从空变为有数据epoll_wait就不会再通知你。2.1 两种模式的对比与选择特性水平触发LT边沿触发ET通知时机只要条件满足缓冲区有数据/可写持续通知。仅在状态变化时空-有数据不可写-可写通知一次。编程复杂度较低。可以多次、分批读取数据不容易遗漏事件。较高。必须在一次通知中循环读取或写入直到出错EAGAIN否则会永久丢失事件。性能潜力可能略低。因为只要数据没读完内核每次都要检查并通知产生一定开销。理论上更高。减少了内核向应用空间传递事件的次数尤其适合数据量大的突发IO。常见应用默认模式对编程友好适用于大多数场景。需要极致性能的高并发服务器如Nginx默认使用ET要求开发者对IO有更精确的控制。选择ET模式通常意味着你追求极致的性能并且愿意承担更复杂的编程逻辑来确保数据的完整性。它强迫你采用“非阻塞IO循环读写直到EAGAIN”的模式这恰恰是最高效利用CPU的方式。3. 边沿触发模式下的“生死状”必须一次性读完或写完这是ET模式最核心、也是最容易出错的原则。因为内核只在你监听的描述符状态发生变化时通知你一次。我们以可读事件为例假设客户端发送了100KB数据。内核接收缓冲区从空变为有数据触发一次ET可读事件。你的epoll_wait返回你开始处理这个套接字。如果你在read循环中只读取了50KB就因为某种原因比如业务逻辑处理退出了那么剩下的50KB数据会留在内核缓冲区里。关键点来了只要这个套接字上没有新的数据从对端到达即状态没有再次从“可读”变为“不可读”再变回“可读”epoll_wait就永远不会再为这个套接字报告可读事件。剩下的50KB数据就会永远“沉睡”在内核缓冲区直到连接关闭。因此在ET模式下处理可读事件的标准范式必须是// 假设 events[n].data.fd 是触发事件的套接字fd while (1) { ssize_t count read(events[n].data.fd, buf, sizeof(buf)); if (count -1) { // 如果 errno 是 EAGAIN 或 EWOULDBLOCK说明本次通知的数据已经全部读完 if (errno EAGAIN || errno EWOULDBLOCK) { break; // 跳出循环处理完毕 } // 其他错误如连接断开 (ECONNRESET) close(events[n].data.fd); break; } else if (count 0) { // 对端关闭连接 close(events[n].data.fd); break; } else { // 成功读取到 count 字节数据进行业务处理 process_data(buf, count); // 注意继续循环尝试读取更多直到触发 EAGAIN } }对于可写事件ET模式下通常不会默认监听可写只在需要时添加逻辑类似当你需要发送大量数据一次write无法写完时你会监听可写事件。当可写事件触发缓冲区从不可写变为可写你必须循环write直到数据发完或遇到EAGAIN。发送完毕后应立即从epoll监听列表中移除对可写事件的监听否则只要缓冲区一直可写在LT模式下会持续触发在ET模式下虽然不会持续触发但保留无用的监听也是浪费。注意这个“循环直到EAGAIN”的模式是ET模式的铁律。忘记它就等于埋下了数据丢失或连接僵死的定时炸弹。4. 实战构建一个ET模式的echo服务器让我们通过一个简单的TCP echo服务器客户端发什么服务器回什么来串联所有概念。这里只展示核心代码逻辑省略错误处理的细节以突出重点。4.1 基础设置创建epoll实例与监听套接字#include sys/epoll.h #include fcntl.h #include unistd.h // ... 其他头文件 #define MAX_EVENTS 64 #define PORT 8080 int main() { int listen_fd, epoll_fd; struct epoll_event ev, events[MAX_EVENTS]; // 1. 创建监听套接字 (socket, bind, listen) - 略 listen_fd create_and_bind(PORT); make_nonblocking(listen_fd); // 将监听套接字也设为非阻塞 listen(listen_fd, SOMAXCONN); // 2. 创建epoll实例 epoll_fd epoll_create1(0); if (epoll_fd -1) { perror(epoll_create1); exit(EXIT_FAILURE); } // 3. 将监听套接字添加到epoll监听可读事件并设置为边沿触发(EPOLLET) ev.events EPOLLIN | EPOLLET; // EPOLLIN 可读 EPOLLET 边沿触发 ev.data.fd listen_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, ev) -1) { perror(epoll_ctl: listen_fd); exit(EXIT_FAILURE); }这里的关键是ev.events EPOLLIN | EPOLLET;。我们将监听套接字也设置为ET模式。为什么监听套接字也需要ET因为对于accept来说ET模式意味着只有在新的连接到来即监听队列从空变为非空时我们才会收到通知。如果我们在一次通知中没有accept完所有等待的连接并且没有新的连接再到来那么剩下的连接请求就不会被处理。因此对于监听套接字在ET模式下也必须循环accept直到返回EAGAIN。4.2 设置文件描述符为非阻塞模式的辅助函数int make_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) { perror(fcntl F_GETFL); return -1; } flags | O_NONBLOCK; if (fcntl(fd, F_SETFL, flags) -1) { perror(fcntl F_SETFL); return -1; } return 0; }这个函数通过fcntl系统调用为文件描述符添加O_NONBLOCK标志这是配合ET模式工作的基石。4.3 事件循环处理连接与数据while (1) { int nfds epoll_wait(epoll_fd, events, MAX_EVENTS, -1); // -1 表示无限等待 if (nfds -1) { perror(epoll_wait); break; } for (int i 0; i nfds; i) { // 4.3.1 处理新的连接请求 (监听套接字可读) if (events[i].data.fd listen_fd) { // ET模式必须循环accept直到没有新连接 while (1) { struct sockaddr_in client_addr; socklen_t addrlen sizeof(client_addr); int conn_fd accept(listen_fd, (struct sockaddr*)client_addr, addrlen); if (conn_fd -1) { // 如果没有更多pending的连接了accept会返回-1errno为EAGAIN if (errno EAGAIN || errno EWOULDBLOCK) { break; // 本次通知的所有连接已处理完 } else { perror(accept); break; } } // 将新连接套接字设为非阻塞 make_nonblocking(conn_fd); // 将新连接添加到epoll监听可读事件使用边沿触发 ev.events EPOLLIN | EPOLLET; ev.data.fd conn_fd; if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, conn_fd, ev) -1) { perror(epoll_ctl: conn_fd); close(conn_fd); } printf(Accepted new connection on fd %d\n, conn_fd); } } // 4.3.2 处理客户端发来的数据 (连接套接字可读) else if (events[i].events EPOLLIN) { int conn_fd events[i].data.fd; char buffer[4096]; ssize_t total_read 0; // ET模式铁律循环读直到读完本次通知的所有数据 while (1) { ssize_t count read(conn_fd, buffer total_read, sizeof(buffer) - total_read - 1); if (count -1) { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据已全部读完 break; } // 真正的错误关闭连接 perror(read); close(conn_fd); break; } else if (count 0) { // 对端关闭了连接 printf(Connection closed on fd %d\n, conn_fd); close(conn_fd); // 注意这里应该从epoll中删除该fd (EPOLL_CTL_DEL)简单示例中略过 break; } else { total_read count; // 简单起见假设我们一次收完所有数据再回显。实际可能需处理粘包。 } } // 如果有读到数据准备回写 if (total_read 0) { buffer[total_read] \0; printf(Received on fd %d: %s\n, conn_fd, buffer); // 这里简化处理直接写回。如果一次写不完需要监听可写事件(EPOLLOUT | EPOLLET)并循环写。 // 为了演示ET写我们假设数据很小一次能写完。 // 更严谨的做法是将待发送数据放入conn_fd对应的缓冲区然后监听EPOLLOUT事件。 // 当EPOLLOUT触发时循环write直到数据发完或EAGAIN发完后取消对EPOLLOUT的监听。 write(conn_fd, buffer, total_read); } } // 4.3.3 处理可写事件 (本例未展示完整实现) else if (events[i].events EPOLLOUT) { // 获取对应conn_fd的发送缓冲区 // while (send_buffer_not_empty) { // ssize_t n write(fd, buffer, len); // if (n -1 errno EAGAIN) break; // // ... 更新缓冲区 // } // if (send_buffer_empty) { // // 取消监听EPOLLOUT事件 // ev.events EPOLLIN | EPOLLET; // epoll_ctl(epoll_fd, EPOLL_CTL_MOD, fd, ev); // } } } } close(listen_fd); close(epoll_fd); return 0; }这个循环是服务器的核心。它清晰地展示了ET模式下无论是处理新连接accept循环还是读取数据read循环都必须遵循“一次性处理完”的原则。对于可写事件的处理注释中也给出了典型的模式。5. 避坑指南ET模式下的典型陷阱与最佳实践在实际项目中仅仅理解原理和写出示例代码是远远不够的。下面这些坑我几乎每一个都踩过。5.1 惊群效应Thundering Herd问题在多进程/多线程服务器模型中多个工作进程/线程都epoll_wait在同一个epoll实例或同一个监听套接字上。当一个新连接到来时所有进程/线程都被唤醒但最终只有一个能成功accept其他都失败EAGAIN造成了不必要的上下文切换和资源竞争。解决方案Linux 3.9 内核支持EPOLLEXCLUSIVE在将监听套接字加入epoll时使用EPOLLIN | EPOLLET | EPOLLEXCLUSIVE。这可以保证一个事件只会唤醒一个正在epoll_wait的进程这是最优雅的解决方案。使用SO_REUSEPORT让每个工作进程创建自己的监听套接字并绑定到相同的IP和端口。内核会负责将新连接相对均匀地分发给这些套接字。每个进程有自己的epoll实例互不干扰。传统方案主进程accept后分发由一个主进程负责accept所有新连接然后通过进程间通信如管道、socketpair将连接描述符分发给各个工作进程。这是Nginx早期版本采用的方式。5.2 文件描述符耗尽与EMFILE问题当服务器压力极大瞬间建立大量连接时可能会达到进程或系统的文件描述符上限。此时accept会失败返回EMFILE错误。更糟糕的是在ET模式下这个错误可能发生在你的accept循环中。如果你直接break跳出循环但监听套接字的可读事件并未被处理完因为错误不是EAGAIN而你又没有关闭任何连接来释放描述符那么这个监听套接字的可读事件会永远丢失ET模式只通知一次导致后续即使有描述符可用也无法再接受新连接。解决方案预留一个“空投”描述符在程序启动时先打开一个无关的文件比如/dev/null或创建一个socketpair得到一个备用的文件描述符。当accept失败且errno EMFILE时先用close关闭那个预留的“空投”描述符为accept腾出一个位置。立刻再次调用accept接受这个新连接。立刻close掉这个刚接受的连接或者发送一个错误回复后关闭。重新打开“空投”描述符以备下次使用。这样做的好处是你及时处理了这次ET通知内核的“连接已接受”状态被清除监听套接字的状态得以更新。当下一次有新连接到来状态再次变化时你还能收到新的ET通知。5.3 数据读不完与“饥饿”问题问题在ET模式下你必须在一次通知中读完所有数据。但如果某个客户端发送数据的速率极快或者你单个read的缓冲区很小可能导致你长时间困在read循环里无法去处理epoll_wait返回的其他就绪事件造成其他连接的“饥饿”。解决方案设置合理的读取上限。在read循环中除了检查EAGAIN还应设置一个最大读取次数或最大读取字节数阈值。int read_loop_limit 0; const int MAX_READ_LOOP 1024; // 防止单个连接饿死其他连接 while (read_loop_limit MAX_READ_LOOP) { ssize_t count read(fd, buf, sizeof(buf)); if (count -1 errno EAGAIN) break; // ... 处理数据 } if (read_loop_limit MAX_READ_LOOP) { // 记录日志可能遇到了快速发送的客户端或者发生了DoS攻击迹象 }当达到上限后即使没有触发EAGAIN也主动跳出循环。这样保证了事件循环的公平性。剩下的数据会在下次该套接字再次有数据到达状态变化时通过新的ET通知来处理。5.4 连接关闭与错误处理在ET模式下对端关闭连接read返回0或发生错误read返回-1且不是EAGAIN时处理逻辑与LT模式一致关闭本地描述符并将其从epoll监控列表中移除EPOLL_CTL_DEL。关键点在于一定要在关闭描述符之前将其从epoll中删除。否则如果先close(fd)这个文件描述符可能会被系统快速复用比如分配给一个新打开的日志文件而epoll实例还在监控旧的fd值这会导致不可预知的混乱。正确顺序epoll_ctl(epoll_fd, EPOLL_CTL_DEL, conn_fd, NULL); // 1. 先从epoll移除 close(conn_fd); // 2. 再关闭文件描述符6. 性能调优与进阶思考当你掌握了ET模式的基本用法并成功避坑后可以考虑以下进阶优化6.1epoll_wait的超时时间epoll_wait的最后一个参数是超时时间毫秒。-1表示阻塞等待0表示立即返回非阻塞轮询。在高性能服务器中通常设置一个较小的超时值如1ms或0ms特别是在配合其他任务如定时器、信号处理时可以避免事件循环被完全阻塞实现更精细的调度。6.2 使用EPOLLONESHOT标志这个标志与EPOLLET结合使用效果最佳。EPOLLONESHOT告诉内核对于注册的这个文件描述符在epoll_wait返回一个事件后就禁用对该描述符的监控。直到你手动重新修改EPOLL_CTL_MOD这个描述符的事件掩码。为什么用它在多线程服务器中当epoll_wait返回一个事件后你可能会将这个连接丢给一个工作线程去处理。如果不使用EPOLLONESHOT在这个工作线程处理数据的过程中该连接可能又收到了新的数据触发了新的可读事件epoll_wait可能再次返回导致另一个线程也来操作同一个连接产生数据竞争。使用EPOLLONESHOT可以确保一个socket fd在任一时刻只被一个线程处理简化了并发编程模型。工作线程处理完数据后需要重新EPOLL_CTL_MOD这个fd来重新激活监控。6.3 与多线程/多进程模型的结合epoll本身是线程安全的一个epoll实例可以被多个线程同时调用epoll_wait惊群问题需用EPOLLEXCLUSIVE解决。更常见的多线程模型是主线程 多个工作线程主线程负责accept新连接然后通过轮询或锁竞争的方式将新连接的fd分配给一个工作线程。每个工作线程有自己的epoll实例负责监控分配给它的所有连接。这种模型需要处理负载均衡和线程间通信。多个对等的工作线程所有工作线程共享同一个监听套接字每个线程都有自己的epoll实例并都将监听套接字加入自己的epoll使用EPOLLEXCLUSIVE避免惊群。每个线程独立运行完整的事件循环。SO_REUSEPORT特性让这种模型变得简单高效。选择哪种模型取决于你的应用场景、编程复杂度和对性能极致的追求。ET模式为所有这些模型提供了高效的事件驱动基础。