1. 为什么I/O复用是高性能服务器的分水岭很多人学网络编程学到socket、bind、listen、accept这一套流程之后写出来的服务器就是一个简单的循环来一个连接就开一个线程或者干脆在主线程里一个接一个地处理。这种模型在连接数少、请求简单的时候跑得挺欢但只要并发量一上来立刻就会暴露出致命问题——线程爆炸、上下文切换开销飙升、CPU大量时间浪费在等待上。我在早期做一个小型内部服务的时候就踩过这个坑。当时用的是最朴素的一请求一线程模型测试环境几十个连接完全没问题结果上线之后连接数一过两百响应时间就从几毫秒直接飙到几百毫秒机器负载高得离谱。后来排查发现大部分线程都阻塞在read上什么都没干但每个线程都占着栈空间切换来切换去真正干活的时间少得可怜。这就是I/O复用要解决的核心问题用少量的线程/进程同时管理大量的连接。它的本质思路是——不要让程序傻等着某个文件描述符就绪而是把一批描述符交给内核让内核告诉你哪些已经准备好了你再去处理那些真正有数据的连接。《Linux高性能服务器编程》第九章讲的就是这个主题。这一章覆盖了select、poll、epoll三种I/O复用机制以及它们各自的适用场景和底层原理。但书上的内容偏理论很多细节需要自己动手跑一遍才能真正理解。这篇文章我会结合自己的实操经验把这一章的核心知识点拆开揉碎补充书上没展开的细节以及实际写代码时容易踩的坑。不管你是刚接触网络编程的新手还是已经用过epoll但没深究过原理的老手相信都能从下面这些内容里找到对自己有用的东西。2. select的机制与它为什么逐渐被淘汰2.1 select的核心工作流程select是最早的I/O复用系统调用之一几乎所有的操作系统都支持它。它的函数签名长这样int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);几个关键参数的含义nfds需要监听的最大文件描述符值加一。注意是最大值加一不是数量。比如你监听了fd 3、5、9那nfds要传10。readfds、writefds、exceptfds分别是你关心的可读、可写、异常事件集合都是fd_set类型。timeout超时时间。传NULL表示永久阻塞传{0,0}表示立即返回非阻塞轮询。fd_set本质上是一个位图每一位对应一个文件描述符。在Linux上fd_set的大小固定为1024位也就是说select最多只能同时监听1024个描述符。这个限制由FD_SETSIZE宏定义虽然理论上可以修改内核头文件重新编译但实际项目中几乎没人这么干。使用select的典型流程是这样的fd_set readfds; FD_ZERO(readfds); FD_SET(listen_fd, readfds); int maxfd listen_fd; // 把已连接的客户端fd也加进去 for (int i 0; i client_count; i) { FD_SET(client_fds[i], readfds); if (client_fds[i] maxfd) maxfd client_fds[i]; } int ret select(maxfd 1, readfds, NULL, NULL, NULL); if (ret 0) { if (FD_ISSET(listen_fd, readfds)) { // 有新连接 } for (int i 0; i client_count; i) { if (FD_ISSET(client_fds[i], readfds)) { // 这个客户端有数据可读 } } }2.2 select的三个致命缺陷第一个缺陷是描述符数量限制。1024个描述符在今天的服务器场景下完全不够用。一个稍微有点规模的聊天服务或者推送服务同时在线几万个连接是常态select根本扛不住。第二个缺陷是每次调用都要重新设置fd_set。select返回后fd_set会被内核修改只保留就绪的描述符。这意味着你每次调用select之前都必须重新把所有的描述符重新加一遍。当描述符数量很多的时候这个拷贝操作本身就是一笔不小的开销。第三个缺陷是内核需要线性扫描所有描述符。select在内核里的实现是遍历你传入的所有描述符逐个检查是否有事件就绪。描述符越多扫描越慢。而且返回之后应用程序也需要遍历所有描述符来找出哪些就绪了又是一次O(n)的操作。我实测过一个简单的echo服务器用select管理500个连接每次事件循环大概要花0.5毫秒左右在select调用和后续的遍历上。连接数增加到1000的时候这个时间翻倍。虽然看起来不多但要知道这还只是空转的开销真正处理数据的逻辑还没算进去。2.3 select在实际项目中还有用武之地吗说实话在Linux平台上做高性能服务器select基本可以不用考虑了。但有两种场景它还有价值一是跨平台兼容。Windows上也有select而且行为基本一致。如果你的代码需要同时跑在Linux和Windows上又不想引入复杂的跨平台抽象层select是一个能用的选择。不过Windows的select没有1024的限制它只受限于系统资源。二是超时精度要求高的小规模场景。select的超时参数是timeval精度到微秒。epoll的epoll_wait超时精度是毫秒。如果你需要微秒级的定时控制而且描述符数量很少select反而更合适。注意select在描述符就绪后如果应用程序没有及时处理下一次调用select时它仍然会被报告为就绪。这跟epoll的边沿触发模式不同select天生就是水平触发的。3. poll对select的改良与遗留问题3.1 poll的数据结构变化poll的出现主要是为了解决select的描述符数量限制问题。它不再使用位图而是用一个pollfd数组来表示关注的事件struct pollfd { int fd; // 文件描述符 short events; // 关注的事件 short revents; // 实际发生的事件由内核填充 }; int poll(struct pollfd *fds, nfds_t nfds, int timeout);events和revents分离的设计比select的位图方式清晰很多。你不需要每次调用前重新设置因为内核只修改revents不会动events。这一点比select友好太多了。poll支持的事件类型也比select丰富除了POLLIN、POLLOUT、POLLERR之外还有POLLRDHUP对端关闭连接、POLLPRI紧急数据等。POLLRDHUP在处理TCP连接关闭的时候特别有用可以避免一些边界情况下的误判。3.2 poll仍然没有解决的根本问题poll解决了描述符数量的限制但没有解决性能问题。内核仍然需要线性扫描整个pollfd数组来检查哪些描述符就绪。当数组很大的时候每次调用poll的开销是O(n)返回后应用程序遍历查找就绪描述符也是O(n)。我做过一个对比测试用poll管理5000个连接其中只有10个活跃。每次poll调用大概需要0.3毫秒左右其中绝大部分时间花在内核扫描那4990个不活跃的描述符上。连接数增加到10000的时候单次poll调用超过0.6毫秒。这意味着即使没有任何数据要处理服务器每秒也只能空转一千多次。另一个问题是pollfd数组需要在用户态和内核态之间拷贝。每次调用poll整个数组都要从用户空间复制到内核空间返回时再复制回来。对于大数组来说这个拷贝开销相当可观。3.3 poll的适用场景判断poll比select更适合描述符数量可能超过1024的场景而且API设计更合理。但如果你的连接数经常在几千以上poll的性能瓶颈会非常明显。我的经验是连接数在1000以内且对性能要求不是极致的时候poll是一个简单可靠的选择。它的API比epoll简单不需要处理文件描述符的增删改代码写起来更直观。在一些内部工具、测试程序、原型验证的场景下用poll完全够用。但如果是面向生产环境的高并发服务poll和select都应该被epoll替代。这不是说poll不好而是epoll在这个场景下确实有数量级的优势。4. epoll的设计哲学与三个核心接口4.1 epoll解决了什么问题epoll是Linux特有的I/O复用机制它的设计目标非常明确在大量描述符中高效地找出少数就绪的描述符。它跟select、poll的本质区别在于select和poll是每次调用都告诉内核我关心哪些描述符而epoll是一次性告诉内核我关心哪些描述符之后内核自己维护这个列表有事件了就通知我。这个区别带来的性能差异是巨大的。epoll在内核里用红黑树来管理所有被监听的描述符用就绪链表来存放已经就绪的描述符。当某个描述符就绪时内核通过回调机制把它加入就绪链表。epoll_wait调用只需要检查就绪链表是否为空而不需要扫描所有描述符。这意味着epoll的时间复杂度是O(1)——不管监听1个描述符还是10000个描述符找出就绪描述符的开销基本恒定。4.2 epoll_create、epoll_ctl、epoll_waitepoll的三个核心接口分工明确int epoll_create(int size); // 创建epoll实例 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 增删改监听 int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout); // 等待事件epoll_create的参数size在现代Linux内核里已经被忽略但为了兼容性传一个大于0的值就行。它返回一个文件描述符代表这个epoll实例。用完记得close。epoll_ctl的op参数有三个取值EPOLL_CTL_ADD添加一个新的描述符到监听列表。EPOLL_CTL_MOD修改已经监听的描述符的关注事件。EPOLL_CTL_DEL从监听列表中移除一个描述符。epoll_event结构体长这样struct epoll_event { uint32_t events; // 关注的事件如EPOLLIN、EPOLLOUT epoll_data_t data; // 用户数据通常存fd或者指针 };data是一个联合体可以存fd、ptr、u32、u64。实际项目中我习惯把fd存在data.fd里同时在应用层维护一个fd到连接对象的映射。也有做法是直接把连接对象的指针存进data.ptr这样epoll_wait返回后直接就能拿到对应的连接对象省去一次查找。两种方式各有优劣后面会详细说。epoll_wait的events参数是一个数组内核会把就绪的事件填充到这个数组里。maxevents指定数组的大小必须大于0。返回值是就绪的事件数量。4.3 epoll的两种触发模式epoll支持两种触发模式这是它最容易被误解的地方之一。水平触发LTLevel Triggered是默认模式。只要描述符的读缓冲区还有数据每次epoll_wait都会报告这个描述符可读。这跟select、poll的行为一致。边沿触发ETEdge Triggered需要显式设置EPOLLET标志。它只在描述符状态发生变化时报告一次。比如从无数据变成有数据的那一刻报告一次之后即使缓冲区里还有数据没读完也不会再报告直到下一次有新数据到达。这两种模式的选择直接影响代码的写法。LT模式下你可以每次只读一部分数据剩下的下次epoll_wait还会提醒你。ET模式下你必须一次性把数据读完通常要配合非阻塞fd和循环read直到返回EAGAIN。我个人的建议是除非有明确的性能需求否则优先用LT。LT的代码更简单不容易出bug。ET虽然理论上效率更高减少了epoll_wait的返回次数但写错的代价也更大——漏读数据会导致连接卡死而且这种bug往往在高并发下才暴露排查起来很痛苦。注意ET模式下如果read没有读到EAGAIN就退出循环剩余的数据可能永远不会被处理。这是新手最容易犯的错误之一。5. 从零实现一个epoll驱动的echo服务器5.1 整体架构设计光看API说明很难真正理解epoll的用法我带着你从零写一个完整的echo服务器。这个服务器接受客户端连接把收到的数据原样发回去。虽然功能简单但涵盖了epoll服务器的所有核心要素。整体架构是这样的主线程创建一个epoll实例把监听socket加入监听。主循环调用epoll_wait等待事件。如果是监听socket就绪调用accept接受新连接把新连接的fd加入epoll。如果是客户端socket就绪读取数据并回写如果对端关闭则清理连接。这个架构是单线程的但已经能支撑相当高的并发量。如果需要利用多核可以扩展成多线程或多进程模型每个线程/进程有自己的epoll实例通过SO_REUSEPORT或者主进程分发连接来实现负载均衡。5.2 监听socket的创建与配置先看监听socket的创建int listen_fd socket(AF_INET, SOCK_STREAM, 0); if (listen_fd 0) { perror(socket); exit(1); } int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); struct sockaddr_in addr; memset(addr, 0, sizeof(addr)); addr.sin_family AF_INET; addr.sin_addr.s_addr htonl(INADDR_ANY); addr.sin_port htons(8080); if (bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)) 0) { perror(bind); exit(1); } if (listen(listen_fd, SOMAXCONN) 0) { perror(listen); exit(1); }SO_REUSEADDR这个选项很重要。没有它的话服务器重启时如果之前的连接还处于TIME_WAIT状态bind会失败。加上它之后可以立即重用地址。listen的第二个参数是backlog指定内核为这个监听socket维护的连接队列长度。SOMAXCONN是一个系统定义的常量通常是128或更大。在高并发场景下这个值可能需要调大但最终受限于内核参数net.core.somaxconn。5.3 把监听socket加入epollint epfd epoll_create1(0); if (epfd 0) { perror(epoll_create1); exit(1); } struct epoll_event ev; ev.events EPOLLIN; ev.data.fd listen_fd; if (epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev) 0) { perror(epoll_ctl); exit(1); }这里用的是epoll_create1(0)而不是epoll_create(size)。epoll_create1是更新的接口参数可以是EPOLL_CLOEXEC表示创建的fd在exec时自动关闭。这是一个好习惯可以避免fd泄漏到子进程。5.4 主事件循环与连接管理主循环的代码#define MAX_EVENTS 1024 struct epoll_event events[MAX_EVENTS]; while (1) { int nfds epoll_wait(epfd, events, MAX_EVENTS, -1); if (nfds 0) { if (errno EINTR) continue; perror(epoll_wait); break; } for (int i 0; i nfds; i) { int fd events[i].data.fd; if (fd listen_fd) { // 处理新连接 struct sockaddr_in client_addr; socklen_t client_len sizeof(client_addr); int client_fd accept(listen_fd, (struct sockaddr *)client_addr, client_len); if (client_fd 0) { if (errno ! EAGAIN errno ! EWOULDBLOCK) perror(accept); continue; } // 设置非阻塞 set_nonblocking(client_fd); struct epoll_event client_ev; client_ev.events EPOLLIN | EPOLLET; client_ev.data.fd client_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, client_ev); } else { // 处理客户端数据 handle_client(epfd, fd); } } }set_nonblocking函数通过fcntl设置O_NONBLOCK标志void set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); }handle_client函数负责读取和回写void handle_client(int epfd, int fd) { char buf[4096]; while (1) { ssize_t n read(fd, buf, sizeof(buf)); if (n 0) { // 回写数据 ssize_t written 0; while (written n) { ssize_t w write(fd, buf written, n - written); if (w 0) { if (errno EAGAIN) { // 写缓冲区满需要等待可写事件 // 简化处理这里直接关闭连接 close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); return; } perror(write); close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); return; } written w; } } else if (n 0) { // 对端关闭 close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); return; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据读完了 break; } if (errno EINTR) continue; perror(read); close(fd); epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); return; } } }这段代码有几个关键点需要注意第一read循环必须读到EAGAIN才能退出。这是ET模式的要求。如果只读一次就退出缓冲区里剩余的数据可能永远不会被处理。第二write也可能返回EAGAIN。当发送缓冲区满的时候非阻塞write会返回EAGAIN。这时候正确的做法是把剩余数据存起来注册EPOLLOUT事件等可写的时候再继续发。上面的代码为了简化直接关闭了连接实际项目中需要更完善的处理。第三每次关闭fd之前必须先从epoll中删除。虽然close会自动把fd从epoll中移除但显式删除更安全也避免了fd被复用后出现意外事件。5.5 实测性能与优化空间我在一台4核8G的机器上测试这个echo服务器客户端用wrk或者自己写的压测工具。单线程版本大概能跑到每秒3-5万次请求延迟在亚毫秒级别。连接数维持在5000左右的时候CPU占用率大概30%。如果要进一步提升性能有几个方向多线程SO_REUSEPORT启动多个线程每个线程有自己的epoll实例和监听socket通过SO_REUSEPORT让内核在多个监听socket之间做负载均衡。这样能充分利用多核。多线程主从Reactor主线程只负责accept把新连接分发给工作线程每个工作线程有自己的epoll循环。这是更经典的模式控制更精细。批量处理epoll_wait返回多个事件时可以批量处理减少系统调用次数。内存池频繁的malloc/free会成为瓶颈用内存池管理连接对象和缓冲区。这些优化方向每一个都值得单独展开但核心的epoll使用方式是不变的。6. epoll使用中的那些坑与经验之谈6.1 EPOLLONESHOT与多线程安全在多线程环境下一个fd可能被多个线程同时操作这会导致竞态条件。比如一个连接有数据可读线程A和线程B都被唤醒去处理结果两个线程同时read同一个fd数据就乱了。EPOLLONESHOT就是为解决这个问题设计的。设置了这个标志之后一个fd的事件被报告一次后就会自动从epoll的就绪链表中移除。你需要显式调用epoll_ctl用EPOLL_CTL_MOD重新注册才能再次收到事件。ev.events EPOLLIN | EPOLLET | EPOLLONESHOT;这样就能保证同一时刻只有一个线程在处理这个fd。处理完之后再重新注册。虽然多了一次epoll_ctl调用但换来了线程安全是值得的。6.2 EPOLLRDHUP的正确使用EPOLLRDHUP是一个很有用但容易被忽略的事件。它表示对端关闭了连接发送了FIN。在LT模式下对端关闭时EPOLLIN也会被触发read返回0。但在ET模式下如果没有EPOLLRDHUP你可能需要等到下一次数据到达才能发现连接已经关闭。ev.events EPOLLIN | EPOLLET | EPOLLRDHUP;处理的时候if (events[i].events EPOLLRDHUP) { // 对端关闭清理连接 }注意EPOLLRDHUP需要定义_GNU_SOURCE宏才能使用。6.3 epoll_wait返回0不代表出错epoll_wait返回0表示在超时时间内没有任何事件发生。如果你传的超时是-1永久阻塞那返回0的情况基本不会出现。但如果传了具体的超时值返回0是完全正常的不要当成错误处理。我见过有代码把epoll_wait返回0当成连接断开来处理结果导致空闲连接被误杀。这种bug在测试环境很难发现因为测试时总是有数据在跑。6.4 文件描述符泄漏的排查epoll服务器最常见的线上问题就是fd泄漏。每个连接占用一个fd如果连接关闭后没有正确closefd数量会持续增长最终达到进程的fd上限默认1024可以通过ulimit -n调整新的连接就无法建立了。排查fd泄漏的方法# 查看进程的fd数量 ls /proc/pid/fd | wc -l # 查看具体是哪些fd ls -la /proc/pid/fd如果发现大量socket:[xxxxx]的fd说明有连接没关闭。常见原因包括accept之后没有把新fd加入epoll或者加入失败后没有close。连接出错时只从epoll删除了但没有close。多线程环境下一个线程关闭了fd另一个线程还在使用。我的习惯是在每个连接对象里记录fd在析构函数里统一close和epoll_ctl(DEL)确保不会遗漏。6.5 水平触发和边沿触发的选择建议前面提过我倾向于LT。但有些场景ET确实更合适高吞吐量的代理服务器ET可以减少epoll_wait的返回次数降低系统调用开销。需要精确控制读取时机的场景ET让你自己决定什么时候读什么时候不读。但ET的代价是代码复杂度上升。你需要确保每次事件都处理干净不能有任何遗漏。我的建议是先用LT把功能跑通确认没有bug之后如果性能确实有瓶颈再考虑切换到ET。不要一上来就用ET那是在给自己找麻烦。6.6 epoll不是银弹epoll解决了I/O复用的效率问题但它不解决所有问题。如果你的服务器是CPU密集型的epoll帮不了你。如果连接数不多但每个连接的数据量很大epoll的优势也不明显。另外epoll是Linux特有的不具备跨平台能力。如果你的项目需要跑在Windows或者macOS上要么用select/poll要么用跨平台的网络库如libevent、libuv它们会在不同平台上选择最合适的I/O复用机制。我个人的经验是在Linux上做高并发网络服务epoll是首选但不要为了用而用。先想清楚你的场景是不是真的需要管理大量连接如果只是几十个连接用poll甚至阻塞I/O加线程池可能更简单、更不容易出错。7. 从I/O复用延伸出去的知识脉络学完epoll之后你会发现它只是高性能服务器的冰山一角。往上走你需要了解Reactor模式和Proactor模式理解事件驱动架构的设计思想。往下走你需要了解TCP协议的状态机知道什么时候连接会关闭、什么时候会出错。往旁边走你需要了解多线程、多进程、协程等并发模型知道怎么把epoll和它们结合起来。《Linux高性能服务器编程》这本书的第九章是一个起点它把I/O复用的基本概念和API讲清楚了。但真正要写出能扛住生产环境流量的服务器还需要大量的实践和踩坑。我自己的经验是光看书是不够的一定要动手写代码写完之后用压测工具跑观察CPU、内存、fd数量的变化遇到问题再回去翻书这样理解才会深刻。如果你已经跟着上面的代码把echo服务器跑起来了下一步可以尝试给它加上协议解析、连接超时管理、优雅关闭等功能。每加一个功能你都会对epoll有新的认识。这个过程没有捷径但走完之后你对网络编程的理解会上一个大台阶。