1. 从阻塞模型的痛点说起多路复用到底解决了什么写网络服务的人大概都经历过这个阶段最开始做聊天室或者简单网关的时候一个连接就开一个线程连接少时跑得挺欢一旦连接数上了几百线程上下文切换就开始疯狂吃CPU内存也扛不住——每个线程默认栈就8MB光栈空间就能把机器吃垮。我当年第一次被线上事故教育就是一个长连接服务在高峰期撑了300多个连接线程一多卡顿、超时、句柄耗尽接连出现最后服务直接假死。后来才意识到这个问题的本质不是并发模型选错了而是我们根本不了解怎么高效地等IO事件。阻塞IO的问题在于recv()没数据时线程只能干等一个线程盯一个连接代价极其高昂。非阻塞IO配合忙轮询倒是能解决“干等”但CPU空转又让人受不了。于是就有了中间路线——IO多路复用一个线程注册一批连接监听完再统一处理内核帮你看哪个连接有动静。Windows的IOCP、Linux的epoll、macOS的kqueue都属于这个方向而select、poll、epoll则是Linux世界三代同堂的典型代表。这篇文章我打算把这三个API掰开揉碎地讲不是只讲用法而是把每个设计选择背后的原因、实际运行时的开销都摊开来看。搞懂select为什么慢、epoll为什么快比背十个API参数有用得多。无论你是刚学Linux网络编程的学生还是在写高并发服务器的工程师理解这三者的演进逻辑对后续选择合适的IO模型都很有帮助。注意select和poll目前在Linux下依然可用并没有被废弃但新项目的高性能路径基本都走epoll。知道这点你就明白这三者不是“谁替代谁”而是“谁在什么条件下更合适”。2. select的细节拆解一次最多盯1024个描述符的朴素方案select是这三兄弟里最早登场的。它的设计逻辑很朴素把你要监听的fd集合传给内核内核一有事件就返回你再一个个检查谁就绪了。int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);2.1 fd_set小数组的本质为什么有FD_SETSIZE这道天花板select最关键的数据结构是fd_set本质上就是一个位图bitmap。单个数组成员在Linux下通常是1024个bit所以FD_SETSIZE默认就是1024。也就是说一次select调用最多只能监听1024个fd。这个数字在20年前够用现在就非常难受——你的文件描述符可能包括了普通文件、管道、socket哪怕连接数没那么夸张只要fd编号超过了1024select就管不过来了。这个上限不是内核故意设卡而是fd_set这个位图数组的大小在编译时就定死了。FD_SET(fd, set)宏里还带一个__FD_ELT的偏移运算逻辑fd一旦超过FD_SETSIZE范围宏内部就悄悄越界。最坑的是很多新手在超过1024个连接时会遇到既不报错也不触发事件的诡异现象排查半天才发现是fd编号越过了位图区域。2.2 select的三个集合是“读写皆损”的输入输出参数这是select最让人头疼的设计之一readfds、writefds、exceptfds三个集合既是你告诉内核“请关注这些fd”的输入也是内核告诉你“这些fd就绪了”的输出。每次调用select之前你得重新用FD_SET把所有要监听的fd再塞一遍调用返回后你还得遍历整个fd_set来判断哪些位被内核置1了。fd_set read_set; struct timeval tv {5, 0}; FD_ZERO(read_set); FD_SET(listen_fd, read_set); for (int i 0; i client_count; i) { FD_SET(client_fds[i], read_set); } int ready select(max_fd 1, read_set, NULL, NULL, tv); if (ready 0) { for (int i 0; i max_fd 1; i) { if (FD_ISSET(i, read_set)) { // 这个 fd 有数据 } } }注意看select的第一个参数nfds是“所有监听fd的最大编号1”不是监听数量。内核要从fd 0开始逐个检查到nfds为止效率非常线性。也就是说即使你只监听fd 1000和fd 1001这两个内核也要从头扫到1001。这就是select复杂度永远不会低于O(n)的原因之一。2.3 水平触发行为没读完就会再次通知你select是典型的水平触发Level TriggeredLT只要fd处于可读/可写状态每次select调用都会把这个fd标记为就绪。这个特性有好有坏。好处是你不会漏掉事件——哪怕你暂时没心情处理下一次select还会再通知。坏处也很明显如果你没把数据读完select会反复触发容易造成忙轮询式的空转CPU烧得很冤枉。我在最初写一个简易网关时就因为在可读事件里只读了一部分数据导致select每轮循环都把这个socket标成就绪CPU占用直接飙满。原因就是没理解LT模式的“持续就绪”行为。解决方式要么是把数据尽量读完要么是改成边缘触发后面讲epoll再细说。2.4 select的三个瓶颈FD上限、全量扫描、内核拷贝把select的问题归纳起来其实就三条fd数量受限位图大小固定默认1024编译期可调但调整后内核和用户态的FD_SETSIZE必须一致维护成本高。全量扫描无论就绪事件多还是少内核每次都要从0扫到nfds用户态也要再遍历一遍fd_set来找就绪fd双向O(n)。集合反复拷贝每次调用select用户态都要把三个fd_set拷贝给内核检查完再拷回来。fd多时这个拷贝开销不可忽略。当初select能流行是因为它足够简单几百个连接的场景完全吃得开。但一切上了量级这三个问题就非常致命了。3. poll的演进逻辑放开数量限制却没能摆脱扫描噩梦poll几乎是冲着select的痛点去的你说fd数量上限低那我不用位图用一个动态数组存pollfd。你说输入输出集合混在一起麻烦我把“要监听的事件”和“实际发生的事件”拆成两个字段。这些改进确实是实打实的。struct pollfd { int fd; /* 文件描述符 */ short events; /* 关注的事件POLLIN、POLLOUT等 */ short revents; /* 返回的实际事件内核回填 */ }; int poll(struct pollfd *fds, nfds_t nfds, int timeout);3.1 摆脱FD_SETSIZE后的自由度一切以数组长度为准poll不再用fd_set而是用动态数组。你监听多少个fd就传多长的数组没有1024这个天花板。每个pollfd结构体里events是你输入给内核的“我想关心什么”revents是内核返回的“实际发生了什么”二者分离调用时不用像select那样反复重建集合——你只需要在每次循环前检查revents就行。这个结构带来的另一个好处是poll能处理的fd数量只受系统进程级fd限制比如ulimit -n。所以你在select时代担心的“连接数超了怎么办”的问题在poll这里基本消失了。3.2 poll还是没有解决的事逐项检查所有fd的老毛病但poll有一个致命伤内核并不知道哪个fd“即将”有事件它只能把传入的pollfd数组从头到尾扫一遍挨个检查每个fd的等待队列上有没有事件挂上。也就是说poll依然是O(n)的扫描复杂度只是把select的“扫位图”变成了“扫数组”。当连接数冲到几千甚至上万时这个扫描成本会指数级放大——每轮poll调用都在耗CPU去遍历那些大概率没动静的fd。我记得有次压测试过一个用poll写的推送服务连接数到5000左右时CPU已经九成花在poll内部遍历上了真正处理业务逻辑只占了不到10%。当时我很直观地理解了什么叫“调度开销大于业务开销”。3.3 poll相对select的隐藏优势更细的事件分离POLLIN、POLLOUT、POLLERR、POLLHUP这些事件位让poll能区分读事件、写事件和异常代码逻辑比select清晰得多。select那个exceptfds在绝大多数场景下形同虚设而poll对连接关闭和错误POLLHUP、POLLERR有明确的事件位开发者可以更准确地处理对端断开、连接重置等情况。另外poll用的是毫秒级超时select用的微秒级timeval彻底解决了select超时精度和精度单位混淆的问题用法上也更顺手。可以说poll是对select的一次成功“平反”它把select里很多别扭的地方都理顺了。3.4 为什么说poll只是“过渡品”既然poll已经把select的毛病改掉大半为什么后来还会冒出epoll因为poll最大的结构性缺陷——全量扫描——没有消失。100个连接时扫描100个pollfd不是事1万个连接时每轮就绪检查都扫1万个结构体性能就很难看。而且poll同样是水平触发模式处理不当会持续空转没有把它从“轮询”升级到“事件驱动”。简单说poll是一个改良版select但它依然停留在“我主动检查所有fd”的层次而epoll才是真正让内核来主动通知你的“事件驱动”机制。这中间的差别就是压死骆驼的最后一根稻草。4. epoll深度解析红黑树就绪链表把复杂度从O(n)打到O(1)epoll是Linux下真正意义上的事件驱动接口。它不是在内核里扫fd数组而是让每个fd在事件发生时主动“上报”。这种设计让它在大规模连接场景下几乎不受连接总量的影响。int epoll_create(int size); 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);4.1 内核维护的两个结构红黑树管注册就绪链表管通知理解epoll的关键是明白它在内核里建了两个数据结构红黑树epoll item的红黑树你通过epoll_ctl注册的每个fd都会在内核的红黑树里生成一个节点。树结构的好处是增删改查都是O(log n)所以“注册/修改/删除事件”的操作非常高效哪怕fd数量很大也不会劣化。就绪链表ready list当一个fd真的事件就绪时内核把对应的epitem挂到就绪链表上。epoll_wait只需要把这个就绪链表里的节点摘出来拷贝给用户态就行——基本是O(就绪数)而不是O(总fd数)。这里的核心思维转变是select/poll是“每次都要问内核谁有事”epoll是“内核一有事情就主动问你你要处理谁”。一个主动轮询一个被动回调性能差异由此而来。我还记得第一次看到epoll源码实现时的感受红黑树解决的是“大量fd注册/删除时查找快“的问题就绪链表解决的是”事件多时遍历不浪费“的问题。两个结构各司其职这个设计非常漂亮。4.2 核心API的实际用法与返回值陷阱实际使用epoll的时候流程很固定int epfd epoll_create(1024); // size参数在2.6.8以后已被忽略但习惯仍会传一个大于0的整数 struct epoll_event ev, events[128]; ev.events EPOLLIN; // 监听可读事件 ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); while (1) { int n epoll_wait(epfd, events, 128, -1); for (int i 0; i n; i) { if (events[i].events EPOLLIN) { handle_read(events[i].data.fd); } } }有几个细节值得注意。epoll_wait的返回值是“就绪的fd数量”和select/poll不同你不需要遍历全部fd只需要处理返回数组里的那n个。data字段是一个联合体你可以存fd也可以存指针、存回调对象它原样返回给你这是epoll设计得非常贴心的部分——直接把上下文和事件绑定在一起。timeout参数传-1是永久阻塞传0是立即返回所有当前就绪事件这在某些需要“顺便检查一下”的场景很有用。还有一个坑EPOLLIN、EPOLLOUT这些宏的值其实对应的是poll的POLLIN、POLLOUT位但epoll额外增加了一个EPOLLERR位通常在epoll_wait返回的事件里已经隐含了错误。很多初学者以为需要手动EPOLL_CTL_ADD去监听错误事件其实不用——只要fd发生错误epoll会把这个事件加到就绪链表中一并返回你只需要在处理时判断events[i].events EPOLLERR即可。4.3 边缘触发ET与水平触发LT一次通知与反复通知的选择题epoll最引以为傲的除了性能还有一个其他方案没有的选项水平触发LT和边缘触发ET。默认是LT行为类似select/poll——fd可读/可写时每次epoll_wait都会通知。加了EPOLLET标记后变成ET——fd的状态从“无事件”变成“有事件”时只通知一次。ET模式就像个闹钟响一次的闹铃你醒了就得马上去办完事否则再也不会响第二次。这对开发者要求很高——必须把数据一次性读完读到EAGAIN否则没读完的那部分数据就只能永远滞留在内存里这个fd相当于“废”了。int ret; char buf[4096]; while ((ret read(fd, buf, sizeof(buf))) 0) { // 处理 buf } if (ret 0 errno EAGAIN) { // 读干净了可以继续等下一次事件 }这个循环读的逻辑几乎每个ET模式的socket处理代码都会出现。用ET模式能减少事件通知次数让每个就绪事件只触发一次处理降低了用户态和内核态的交互频率但代价是代码必须特别谨慎稍不留神就会丢数据。一般网络框架如libevent、nginx都是默认LT用户按需选ET。我的建议是刚开始写网络服务时用LT逻辑简单不容易犯错等架构稳定了如果确实需要压榨性能再考虑ET。4.4 epoll_wait拷贝的是“就绪列表”不为没有事件就绪的fd买单很多性能对比看不懂epoll为什么能撑10万连接原因就在这里select/poll每次调用都要把所有监听的fd从用户态拷到内核态内核扫一遍再拷回来。epoll则通过epoll_ctl注册后内核就“记住”了你的fd不需要每次wait时把完整的监听列表拷贝一遍。epoll_wait只把就绪的那几个事件拷贝回用户态。所以在连接数大、就绪事件少的场景下epoll的每轮开销几乎就是个位数的拷贝量。而select/poll的每次调用成本都是全量的。这个差距在连接数越多时越夸张。4.5 epoll也不是万能的连接少时的性能不占优说一句公道话epoll的复杂度不是免费的午餐。注册、修改、删除都要经过系统调用内核里还要操作红黑树、维护回调信息这些都有成本。如果你的服务同时只有几十个连接、事件频率很低select或poll的每轮开销根本体现不出来用epoll反而显得重。它真正的主场是成千上万个连接中只有少数活跃的场景——这也是绝大多数互联网后台服务的写照。5. 三类接口的适用边界从复杂度、事件模型到选型落地聊完了原理来一组直观的对比方便你做技术选型时心中有数。对比维度selectpollepoll底层结构位图fd_setpollfd数组红黑树就绪链表最大fd数量FD_SETSIZE默认1024进程级fd上限进程级fd上限时间复杂度O(n)扫描全部O(n)扫描全部O(就绪数)注册/删除约O(log n)输入输出是否分离不分离需重建分离events/revents分离用户自管事件通知方式水平触发LT水平触发LTLT ET可选每轮拷贝量全量拷贝fd_set全量拷贝pollfd数组仅拷贝就绪事件跨平台支持Windows/Linux/Unix等Windows/Linux/Unix等Linux only代码复杂度较繁琐中等中等偏复杂ET更高5.1 不同场景下的选择建议与个人实测感受具体怎么选我的经验是这样的连接量小几十到几百、追求简单可靠select完全够用。早期很多设备端嵌入式系统的网络服务用的就是select因为没有海量并发需求代码简洁就是优势。不过要注意select跨平台性好Windows下也有类似API在写可移植服务时可以留作后备方案。连接量中等几百到几千需要更细的事件类型且不追求极致性能poll比select更顺手数组管理比位图直观events/revents分离让逻辑更清晰。Linux高并发服务连接数以万计不用犹豫直接上epoll。只要你的服务跑在Linux上epoll就是当下最优解。尤其在用事件驱动框架前直接用裸epoll也能轻松打通一条路。我个人做过一个粗略的压测对比同一台机器同一个端口线程模型相同连接数到3000时poll方案的CPU占用开始明显攀升epoll方案依旧平稳到8000时poll的CPU占用超过90%epoll的CPU占用仍在20%以下。这不是说poll不行——而是它在设计时就没想到要扛这么大的连接规模。5.2 注意macOS/BSD上的kqueue是另一个方向如果你做跨平台开发会发现Linux的epoll在macOS/BSD上根本不存在那边用的是kqueue。kqueue的事件驱动思路与epoll相似但API形态不同用kevent结构体、evSet和evGet事件。如果你的项目需要跑在多种操作系统上通常不会直接裸写epoll或kqueue而是用libevent、libuv这类封装好的事件库来抹平差异底层自动选择最合适的实现。提示裸写epoll是学习原理的好方法但生产环境建议优先考虑封装成熟的事件库避免自己处理各种平台细节和边界情况。6. 实战中绕不开的坑事件处理细节、惊群与性能调优原理都懂一写就废常见原因就是没处理好epoll实践中的细节。这里把我踩过的几个坑集中说一下。6.1 LT模式下没读完数据导致的事件风暴LT模式的最典型问题某个客户端发来的数据比较长你每次只read了一部分这个fd会一直处于可读状态epoll_wait就会反复把它返回给你。如果你的业务代码把事件压入队列后再慢慢处理队列里很快就会堆积大量相同fd的事件。解决办法很简单LT模式下尽量一次把数据读完或者至少读完当前缓冲区的全部内容让fd恢复到“不可读”状态避免无谓的通知循环。6.2 ET模式下的EAGAIN与半包问题ET模式的坑更深。如果read()返回-1且errno EAGAIN说明当前数据已经读干净可以继续等下一次事件但如果你写的循环没有边界条件只凭read返回值来判断很容易出现死循环或漏数据。常见的做法是在单次事件处理内循环read直到EAGAIN同时给每次循环的总读取量设一个上限防止恶意客户端狂发数据把CPU拖垮。还有一个经典问题TCP是流式协议一次read拿到的数据可能是多个业务包拼接的也可能只拿到半个业务包。这和LT/ET无关而是TCP粘包/拆包的固有属性。所以事件循环里要有字节流的缓冲区管理逻辑不能假设read一次就是一个完整包。6.3 多线程epoll_wait与惊群问题用多线程同时epoll_wait同一个epoll fd事件到来时可能多个线程同时被唤醒但最终只有一个线程真正处理该fd——其他线程白醒一场这就是惊群效应thundering herd。现代Linux内核对于epoll已经有了一定优化EPOLLEXCLUSIVE标志可以只唤醒一个等待者但它只在某些场景下有效且对事件分发逻辑有要求。更稳妥的方案是不要让多个线程同时等在同一个epoll fd上而是按需把fd分给不同的线程去管理或者用一个线程负责epoll_wait拿到事件后再派发给工作线程。这个设计简单、可控也避免了惊群。6.4 EPOLLONESHOT的事件后自动摘除另一种常用手法是EPOLLONESHOT事件触发并通知一次后这个fd在内核里的注册会自动失效之后不再触发任何事件直到你再次epoll_ctl重新注册。这个机制非常适合多线程分发的场景——一个线程处理某个fd的完整事件期间其他线程不会重复收到该fd的通知处理完成后你只需重新挂上这个fd即可。不过要注意EPOLLONESHOT的重新注册要在处理完数据后主动做如果忘了重新注册这个fd就永远不会再被通知了。这属于典型的“自动化反而害死人”的坑。6.5 高频epoll_ctl调用带来的系统调用开销很多人以为epoll性能好就可以随便EPOLL_CTL_ADD/DEL/MOD。实际上每次epoll_ctl都是一次系统调用且要在红黑树里做增删查频繁操作同样会产生可观的损耗。在短连接很多的场景比如HTTP请求风暴下每个连接都ADD/DEL一次系统调用数量会非常惊人。优化的思路是复用fd而非频繁创建用连接池对于变化不大的事件标志不要每次都去MOD也可以考虑把事件监听和业务处理合并减少无谓的ADD/DEL循环。我在做高并发网关时曾把每连接三次epoll_ctl降到一次整体CPU占用直接下降了十几个百分点。6.6 单线程还是多线程一个设计上的建议很多初学者问epoll这么强是不是单线程就够用答案是epoll本身只是事件通知机制业务处理是CPU密集还是IO密集决定了你需不需要多线程。如果是简单转发、代理类服务单线程epoll 非阻塞IO的高性能事件循环完全够用如果是业务逻辑重、涉及计算密集任务的事件循环收到事件后应该把任务交给工作线程池主线程继续保持监听。这种“事件分发工作线程”的经典模型比多线程抢一个epoll fd要稳得多。7. 写在最后很多人学select、poll、epoll习惯把它们当成三个孤立的函数去背参数我觉得那样效率很低。真正的学习路径应该是顺着“阻塞IO-多路复用-事件驱动”这条线去理解搞清楚每次的瓶颈是什么、设计者用什么方式去解决它。我当年从select切换到poll再切到epoll每一次都在刷新对“等IO”这件事的认知。现在回看这三者的演进本身就是一个小型的操作系统设计最佳实践史。如果让我给一句建议开发高频高并发的Linux网络服务直接上epoll需要跨平台或连接规模不大poll更省心至于select了解它的历史和原理就好除非你在做兼容老系统的嵌入式服务否则不必优先使用。另外真要在生产环境里写复杂网络业务还是那句老话——先用libevent或者libuv这类经过大量实战考验的事件库把业务做好等真的遇到性能瓶颈再回来研究要不要手写epoll。工具是死的算法和模型才是真正决定服务质量的东西。