1. 多路IO复用到底解决了什么问题聊到Linux系统编程很多同学一开始接触的是阻塞式IO调用read等数据没数据就挂在那儿直到内核把数据准备好。这种模型写起来简单但一遇到要同时处理几十个、几百个连接的服务端场景立刻就崩了——你没法为每个连接开一个线程去阻塞等待线程开销、上下文切换、内存占用会直接把进程拖垮。多路IO复用就是在这种背景下必须掌握的核心技术它让单个进程或线程同时监视多个文件描述符内核帮你盯着这堆描述符一旦某个或某几个变得“可读”或“可写”内核就通知你你再针对就绪的描述符做实际读写。这样一来一个线程就能扛住成千上万的并发连接典型的应用就是Nginx、Redis单线程Reactor模型还有各种网络代理和即时通讯服务端。先列出整套方案的三兄弟也是本篇文章的主角select最早出现的多路复用接口兼容性极好但内核有FD_SETSIZE上限通常是1024且每次调用都要把整个fd集合从用户态拷到内核态效率不算高。poll本质上是select的改进版取消了1024的上限改用pollfd数组管理fd但依然有“全量拷贝 线性扫描”的问题fd数量多了同样吃力。epollLinux特有的高性能方案红黑树加就绪链表的设计只把活跃的fd反馈给用户连接数到十万级别也不会明显劣化是目前Linux服务端的绝对主力。如果你做的是跨平台项目可能要评估一下select或poll的移植成本但只要你的运行环境确定是Linux生产环境直接选epoll基本不会有争议。后面我会依次拆解它们的工作原理、适用场景和实战编码最后再给出一些坑位提醒。2. 先摸透三兄弟的家底select、poll、epoll细节对比2.1 select老当益壮但不适合大并发select接口长这样#include sys/select.h #include sys/time.h int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);参数看着多其实是三组fd集合加一个超时时间。使用上的常规套路是fd_set read_fds; FD_ZERO(read_fds); FD_SET(sockfd, read_fds); int max_fd sockfd 1; int ret select(max_fd, read_fds, NULL, NULL, NULL); if (ret 0 FD_ISSET(sockfd, read_fds)) { // 这个连接有数据可读 }第一次用select的人很容易栽在两个细节上。第一个nfds并不是fd的数量而是“最大fd值加1”——就像你要给一堆排队的人发号你至少要把号发到最大的那个号所以内核是拿这个数字去遍历0到nfds-1之间的所有fd而不是只看你注册的这几个。第二个select返回后fd_set里的内容会被内核改写只保留就绪的fd所以下一轮循环必须重新FD_SET这个“重置”的操作如果漏掉轻则漏事件重则越界行为排查起来非常阴间。select真正让人头疼的瓶颈有三个单个进程能监视的fd数量受FD_SETSIZE限制默认1024改内核宏重新编译才能扩大但并不是所有系统都乐意支持。每次调用都要把fd_set从用户态拷贝到内核态fd多、调用频繁时拷贝成本不可忽略。内核不知道你关心哪些fd只能线性扫描全量fd扫描完还要把就绪结果拷回来。整个过程复杂度O(n)。所以我对select的定位是适合教学入门或者写一些几十个连接以内的轻量工具。真到了生产级别的高并发它撑不住。2.2 poll取消了数量限制但复杂度没变poll的接口看起来清爽不少#include poll.h struct pollfd { int fd; // 文件描述符 short events; // 关注的事件POLLIN、POLLOUT等 short revents; // 返回时内核填充的就绪事件 }; int poll(struct pollfd *fds, nfds_t nfds, int timeout);用法上没有select那一堆FD_SET宏了直接给一个数组填写每个fd关注啥事件然后就等内核通知。相比selectpoll有两个明显进步突破了1024上限理论上fd数量只受系统最大文件数限制。pollfd结构里把events和revents分开内核填revents不会破坏你下次要用的events字段省掉了select那套“重新填充”的痛苦。但大家最不满的一点没变poll仍然需要把所有fd传给内核内核仍然要逐个扫描所有fd检查有没有事件。换句话说时间复杂度还是O(n)当连接数达到数万级别每次poll都会变成一次小型灾难。如果说select是只能装1000人的大巴那poll就是能把一万人硬塞上车的大巴但上车的时候依然要一个个检票。前者是容量不够后者是检票效率太拉胯。2.3 epollLinux下的大杀器epoll是Linux内核专门针对海量连接场景设计的方案破局思路跟select/poll完全不同。先看核心接口#include sys/epoll.h // 创建epoll实例size参数从Linux 2.6.8之后被忽略但为了兼容还是给个大于0的值 int epoll_create(int size); // 增删改fd及其关注事件 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 等待事件就绪就绪事件写入events数组 int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);常规流程如下int epfd epoll_create(1024); struct epoll_event ev; ev.events EPOLLIN; // 关注可读事件 ev.data.fd listen_fd; // 用data.fd记住这属于哪个fd epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[1024]; while (1) { int n epoll_wait(epfd, events, 1024, -1); for (int i 0; i n; i) { // 处理 events[i].data.fd 上的事件 } }epoll的关键差异化设计在底层数据结构。内核维护一棵红黑树用来存你注册的所有fd和对应的事件。增删改查都是O(log n)不用全量扫描。每个fd有事件就绪时内核把它挂到一个就绪链表上。epoll_wait只需要把就绪链表的数据复制到用户态然后清空链表。换句话说内核通知你的是“已经准备好哪些”而不是“你去看看有哪些”。同时支持水平触发LT和边缘触发ET两种模式后面我专门展开讲这个。所以当连接数很大但活跃连接没那么多时epoll的优势接近降维打击——复杂度从O(n)变成O(就绪连接数)。下表把三兄弟的关键差异集中对比一遍维度selectpollepoll最大fd数受FD_SETSIZE限制默认1024无上限受系统限制无上限受系统限制用户态到内核态拷贝每次调用拷三组fd_set每次调用拷pollfd数组epoll_ctl注册时拷贝epoll_wait只拷就绪事件内核筛选方式线性扫描全部fd线性扫描全部fd红黑树管理注册fd 就绪链表反馈时间复杂度O(n)O(n)O(就绪fd数量)水平触发/边缘触发仅水平触发仅水平触发支持LT和ET跨平台几乎所有平台Windows、Linux都可用仅Linux适合场景连接少、教学、轻量工具连接较多但活跃度不极端高并发、海量连接、高吞吐3. 实战编码从零写一个基于epoll的TCP回显服务器3.1 代码整体结构设计理论知识再多不落地就是空中楼阁。我习惯用一个简洁的epoll回显服务器来演示整套链路客户端发什么服务端原样返回什么。别小看这个Demo它涵盖了服务端初始化、监听socket设置、epoll注册、事件循环、accept新连接、读写业务处理的完整闭环是深入学习的基础骨架。先搭框架#define MAX_EVENTS 1024 #define MAX_BUFFER_SIZE 4096 int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); // 设置端口复用避免TIME_WAIT状态导致重启后bind失败 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(9000); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); int epfd epoll_create(MAX_EVENTS); struct epoll_event ev; ev.events EPOLLIN; // 监听可读 ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); // 事件循环 struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd listen_fd) { // 处理新连接 } else { // 处理既有连接上的数据 } } } }这个结构是所有事件驱动服务端的基本盘。每次epoll_wait返回后你要区分“这是新连接来了”还是“已有连接有数据”这里的if判断就是事件分发器的雏形。3.2 新连接接入的处理细节当listen_fd出现在就绪事件里说明有客户端在握手。这里有一个非常关键的注意事项你得把新连接一次性全收下来而不是只accept一次。原因很简单可能同时有多个客户端连接完成如果只accept一个剩下的连接事件可能会在下一轮才再次通知但在高并发下这会增加延迟和瞬时压力。标准做法是while循环accept直到返回EAGAIN为止if (fd listen_fd) { while (1) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 当前没有更多待处理的连接 } else { perror(accept error); break; } } // 把新连接加入epoll监控 ev.events EPOLLIN | EPOLLET; // 边缘触发模式后面展开 ev.data.fd conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ev); } }同时要给accept出来的conn_fd设置非阻塞属性因为后面配合EPOLLET边缘触发时非阻塞是必要条件。设置方式int flags fcntl(conn_fd, F_GETFL, 0); fcntl(conn_fd, F_SETFL, flags | O_NONBLOCK);我给每个新连接设置的监听事件是EPOLLIN | EPOLLET用边缘触发。这个模式下内核只在fd从“无事件”变成“有事件”的边界通知一次不反复提醒所以读数据时你必须一次性把缓冲区的数据全部读完直到返回EAGAIN否则剩余数据可能要等下一次新事件才能再触达——一旦有新事件覆盖旧数据可能就被卡住了。3.3 连接数据的读写策略收到可读事件后读写逻辑直接决定服务端的吞吐和稳定性。我习惯用read配合固定缓冲区char buffer[MAX_BUFFER_SIZE]; while (1) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 回显给客户端 write(fd, buffer, n); } else if (n 0) { // 读到0说明对端关闭连接 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据已经读完正常退出循环 break; } else { // 真正出错 close(fd); break; } } }这段代码对ET模式来说是标准写法一旦有读事件就循环读到EAGAIN。这里有个容易踩的坑写端write不一定能一次写完。比如客户端接收窗口变小socket的发送缓冲满了write可能返回EAGAIN。这时你可能要先把数据暂存到应用层缓冲区等待EPOLLOUT事件再继续发送。真正生产级的服务端一定是要处理写缓冲区的这里为了讲清楚多路复用的主线先不铺开大复杂但你要有这个意识。3.4 用全套代码串起来把上面几段拼在一起补全头部和细节就是一条非常完整的epoll服务端#include stdio.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include errno.h #include sys/socket.h #include sys/epoll.h #include netinet/in.h #include arpa/inet.h #define MAX_EVENTS 1024 #define BUFFER_SIZE 4096 int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); if (listen_fd -1) { perror(socket); exit(1); } int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); set_nonblocking(listen_fd); 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(9000); if (bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)) -1) { perror(bind); exit(1); } if (listen(listen_fd, 128) -1) { perror(listen); exit(1); } int epfd epoll_create(MAX_EVENTS); if (epfd -1) { perror(epoll_create); exit(1); } struct epoll_event ev; ev.events EPOLLIN; ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd listen_fd) { while (1) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) break; perror(accept); break; } set_nonblocking(conn_fd); ev.events EPOLLIN | EPOLLET; ev.data.fd conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ev); } } else { char buffer[BUFFER_SIZE]; int done 0; while (1) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { write(fd, buffer, n); } else if (n 0) { done 1; break; } else { if (errno EAGAIN || errno EWOULDBLOCK) break; done 1; break; } } if (done) { epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } } } } }这段代码我已经在自己机器上跑过很多次回显功能是稳定的。但它离生产级还差很远——没有记录每个连接的应用层缓冲、没有超时机制、没有心跳检测、没有优雅关闭流程。这些最终都需要在对多路复用充分理解后一层层补上去。4. 水平触发与边缘触发的底层逻辑4.1 两种模式的真实区别水平触发LT是select和poll的内置行为只要某个fd还有数据没读每次调用都会通知你。边缘触发ET则是内核只在状态变化的“边缘”通知一次——比如数据从无到有那一刻提醒你之后即使你只读了一半内核也不会再提醒直到你把它读完或者新数据再次到来。打一个生活化的比方水平触发就像一个自动感应水龙头手没拿开就一直出水边缘触发像老式门铃你按一次响一次手一直按着不松开它也不会连续响。epoll默认是LT模式这是很多资料没强调的。如果你创建fd时只写EPOLLIN那就是LT要启用ET得写成EPOLLIN | EPOLLET。LT的好处是编程简单不用把数据一次性读完不会丢数据坏处是内核可能会多次通知同一个事件影响一点效率。ET的好处是通知次数少、处理及时性高适合高吞吐场景坏处是对编码要求高——必须循环读写直到EAGAIN否则可能漏数据。4.2 怎么选LT还是ET我的建议分成三个档位初学阶段先用LT把epoll_wait、事件分发这些先跑通避免读不干净的坑干扰对主流程的理解。通常业务用LT也完全能支撑大量连接事实上很多主流服务在默认配置下工作得很好不必盲目追求ET。极致性能场景例如网关、高吞吐代理用ET并配合非阻塞IO和循环读写能减少不必要的系统调用次数。还有一个非常实用的经验用ET模式时你的fd必须是非阻塞的。因为ET要求你会循环read到EAGAIN如果fd是阻塞的读完数据后read会卡在那里整个进程就卡死了。这个点面试常问实战也常翻车务必记牢。5. 高并发避坑指南我踩过的那些坑5.1 坑1epoll_wait超时时间理解错位很多人在epoll_wait的timeout传-1意为永久阻塞。这是合理的但要注意如果所有fd都没事件线程会一直睡在epoll_wait里如果服务端还有其他定时任务比如心跳检测就需要epoll_wait定期超时返回一次好让主循环有机会处理定时逻辑。更好的做法是把timeout设为定时任务的最小间隔例如100ms然后用当前时间减上次处理时间来判断哪些连接超时。强烈不建议用一个单独的定时器线程去遍历所有连接——如果连接数到了几十万每次全量遍历本身就是巨大的损耗。5.2 坑2误以为epoll_wait返回的events都是有效的epoll_wait返回的就绪事件里有的fd可能在你还没来得及处理时就被对端关闭了。所以别假设每个事件对应的fd一定可用读写之后要正确处理错误码if (fd -1) continue; if (events[i].events (EPOLLERR | EPOLLHUP)) { // 对端异常断开或挂断做清理 close(fd); continue; }EPOLLERR和EPOLLHUP这两个事件经常被新手忽略但它们恰恰在一些异常场景下会先于EPOLLIN到达忽略的话fd就泄漏了。5.3 坑3fd泄漏每个accept出来的连接最终都要在close时成对出现。我见过写服务端的人只在业务处理结束时close却忘了从epoll里删除fd。其实close(fd)会自动把fd从epoll中移除不用手动epoll_ctl(EPOLL_CTL_DEL)也可以但显式删除的好处是逻辑清晰可以防止某些怪异情况下的误用。还有更隐蔽的泄漏accept失败时没处理、连接的收发缓冲没清干净就close、main循环异常退出但listen_fd没关。建议在开发阶段用lsof或/proc/PID/fd查看fd数量如果发现连接断开后fd数不降赶紧查是不是漏了close。5.4 坑4边缘触发下循环读卡死ET模式下如果对端持续发数据你一直循环读一直有数据read就一直在返回这本来不是问题但如果你没处理好EAGAIN循环会一直在那里空转把CPU打满。解决思路read到EAGAIN就break单个连接连续读的总量加一个上限超过就先缓存把事件压回队列或者放到下次循环处理防止一个连接霸占CPU大批量数据下载场景适当考虑用一个独立的线程池做具体IO。6. 从单线程到多线程Reactor的演进思路6.1 单线程Reactor模型上面演示的epoll事件循环就是典型的单线程Reactor模型一个线程负责epoll_wait、accept、读写。优点简单、无锁、天然线程安全。 缺点一个连接的IO操作卡住整个服务端都阻塞。所以在这种模型下业务逻辑必须是非阻塞、快速返回的。适合场景Redis、部分代理、小型API网关。Redis之所以能单线程扛高吞吐核心就是所有命令内存级响应极快几乎不阻塞。6.2 多线程Reactor模型的部署当业务逻辑出现磁盘IO、数据库交互、耗时计算等场景单线程Reactor扛不住就要演进到多线程Reactor。主流做法是主线程只跑accept把新连接分发给多个子Reactor线程。每个子Reactor线程维护自己的epoll实例处理自己那批连接的读写和业务。这样每个连接只会被一个线程长期占有减少了锁竞争连接间的处理天然并行。如果你的业务里包含CPU密集计算甚至可以考虑再单独拉线程池处理计算任务事件循环只负责收发数据数据到了就往计算线程池里丢算完结果再通过事件循环写回。这是很多高性能服务器的通用架构框架。6.3 事件驱动架构的参考设计在设计高并发服务时我会把整个模块拆成四个角色连接管理器维护所有连接的fd、读写缓冲区、超时时间和状态。事件循环驱动epoll_wait执行事件分发。处理器具体处理读到的数据分发给业务模块或线程池。发送队列管理写缓冲和EPOLLOUT事件避免写阻塞。这套设计把多路复用从一个“能用”的接口变成一套“能扩展”的架构。你的服务能并发多少很大程度上取决于事件循环对每个连接的处理是否足够轻量。7. 实测表现压测数据带来的直观体感实践出真知。我用同一台虚拟机分别写了基于select和基于epoll的回显服务器用本机工具模拟并发连接。连接数在500以下时两者延迟差别不大都在毫秒级。但当连接数到5000select已经明显出现周期性延迟抖动CPU占用也偏高epoll依然平稳p99延迟基本维持在个位数毫秒。一旦把连接数推到2万以上select直接无法工作而epoll依然没有成为瓶颈。这背后的道理其实很简单select每次都要把2万个fd全量扫描一遍而epoll只需要关注真正活跃的几百个fd。也就是说活跃连接占比越低epoll的相对优势越大。极端情况下如果每个连接都在持续收发数据epoll的优势会被压缩但依然不会出现全量扫描的问题。如果你需要做实测可以先写一个客户端循环建立连接并定时发送心跳服务端打印当前连接数和epoll_wait的返回延迟。现象会非常直观。同时注意压测时要监控CPU、内存、句柄数三个维度别只盯着延迟。8. 挑选多路复用方案时的一些个人建议8.1 明确你能接受的内核依赖epoll是Linux专属。如果你的服务要跑在macOS、Windows或者其他Unix变体上要么用跨平台的libevent、libuv这类封装库要么自己包一层抽象接口。很多公司做中间件时选择对上层屏蔽IO模型的细节底层在Linux用epoll在其他平台退回kqueue或poll上层只看到统一的add、del、wait接口。这种设计虽然增加了工作量但跨平台迁移时就舒服很多。8.2 连接模型选型的判断公式以我个人经验连接类型大致能分两类低频连接连接建立后大部分时间闲置偶尔发个心跳或小请求。这类适合用LT模式省心不丢事件。高频流式数据比如视频流、消息推送、日志采集。这类适合ET模式减少重复通知吞吐更高。服务端设计没有银弹但核心思路是一致的少拷贝、少遍历、少阻塞、及时清理无效连接。理解了多路复用背后的原则换任何封装的网络库都能很快上手。8.3 最后分享一个开发阶段的实用技巧我在调试epoll服务时经常会在epoll_wait返回后加一段临时日志打印就绪fd数量和当前总fd数。这个日志在联调阶段帮过大忙——有一次线上疑似连接泄漏我在一次版本里短暂加了这段日志定位到是一条错误路径上accept成功后没有注册到epoll就提前返回后续数据永远没事件客户端干等连接也一直没释放。工具方面平时strace跟踪系统调用、lsof查fd、ss或netstat看连接状态都是调试网络服务的得力帮手。这套技能栈补上之后系统编程的地基才算真正打稳。 select、poll、epoll深度解析：多路IO复用与高并发编程
1. 多路IO复用到底解决了什么问题聊到Linux系统编程很多同学一开始接触的是阻塞式IO调用read等数据没数据就挂在那儿直到内核把数据准备好。这种模型写起来简单但一遇到要同时处理几十个、几百个连接的服务端场景立刻就崩了——你没法为每个连接开一个线程去阻塞等待线程开销、上下文切换、内存占用会直接把进程拖垮。多路IO复用就是在这种背景下必须掌握的核心技术它让单个进程或线程同时监视多个文件描述符内核帮你盯着这堆描述符一旦某个或某几个变得“可读”或“可写”内核就通知你你再针对就绪的描述符做实际读写。这样一来一个线程就能扛住成千上万的并发连接典型的应用就是Nginx、Redis单线程Reactor模型还有各种网络代理和即时通讯服务端。先列出整套方案的三兄弟也是本篇文章的主角select最早出现的多路复用接口兼容性极好但内核有FD_SETSIZE上限通常是1024且每次调用都要把整个fd集合从用户态拷到内核态效率不算高。poll本质上是select的改进版取消了1024的上限改用pollfd数组管理fd但依然有“全量拷贝 线性扫描”的问题fd数量多了同样吃力。epollLinux特有的高性能方案红黑树加就绪链表的设计只把活跃的fd反馈给用户连接数到十万级别也不会明显劣化是目前Linux服务端的绝对主力。如果你做的是跨平台项目可能要评估一下select或poll的移植成本但只要你的运行环境确定是Linux生产环境直接选epoll基本不会有争议。后面我会依次拆解它们的工作原理、适用场景和实战编码最后再给出一些坑位提醒。2. 先摸透三兄弟的家底select、poll、epoll细节对比2.1 select老当益壮但不适合大并发select接口长这样#include sys/select.h #include sys/time.h int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);参数看着多其实是三组fd集合加一个超时时间。使用上的常规套路是fd_set read_fds; FD_ZERO(read_fds); FD_SET(sockfd, read_fds); int max_fd sockfd 1; int ret select(max_fd, read_fds, NULL, NULL, NULL); if (ret 0 FD_ISSET(sockfd, read_fds)) { // 这个连接有数据可读 }第一次用select的人很容易栽在两个细节上。第一个nfds并不是fd的数量而是“最大fd值加1”——就像你要给一堆排队的人发号你至少要把号发到最大的那个号所以内核是拿这个数字去遍历0到nfds-1之间的所有fd而不是只看你注册的这几个。第二个select返回后fd_set里的内容会被内核改写只保留就绪的fd所以下一轮循环必须重新FD_SET这个“重置”的操作如果漏掉轻则漏事件重则越界行为排查起来非常阴间。select真正让人头疼的瓶颈有三个单个进程能监视的fd数量受FD_SETSIZE限制默认1024改内核宏重新编译才能扩大但并不是所有系统都乐意支持。每次调用都要把fd_set从用户态拷贝到内核态fd多、调用频繁时拷贝成本不可忽略。内核不知道你关心哪些fd只能线性扫描全量fd扫描完还要把就绪结果拷回来。整个过程复杂度O(n)。所以我对select的定位是适合教学入门或者写一些几十个连接以内的轻量工具。真到了生产级别的高并发它撑不住。2.2 poll取消了数量限制但复杂度没变poll的接口看起来清爽不少#include poll.h struct pollfd { int fd; // 文件描述符 short events; // 关注的事件POLLIN、POLLOUT等 short revents; // 返回时内核填充的就绪事件 }; int poll(struct pollfd *fds, nfds_t nfds, int timeout);用法上没有select那一堆FD_SET宏了直接给一个数组填写每个fd关注啥事件然后就等内核通知。相比selectpoll有两个明显进步突破了1024上限理论上fd数量只受系统最大文件数限制。pollfd结构里把events和revents分开内核填revents不会破坏你下次要用的events字段省掉了select那套“重新填充”的痛苦。但大家最不满的一点没变poll仍然需要把所有fd传给内核内核仍然要逐个扫描所有fd检查有没有事件。换句话说时间复杂度还是O(n)当连接数达到数万级别每次poll都会变成一次小型灾难。如果说select是只能装1000人的大巴那poll就是能把一万人硬塞上车的大巴但上车的时候依然要一个个检票。前者是容量不够后者是检票效率太拉胯。2.3 epollLinux下的大杀器epoll是Linux内核专门针对海量连接场景设计的方案破局思路跟select/poll完全不同。先看核心接口#include sys/epoll.h // 创建epoll实例size参数从Linux 2.6.8之后被忽略但为了兼容还是给个大于0的值 int epoll_create(int size); // 增删改fd及其关注事件 int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); // 等待事件就绪就绪事件写入events数组 int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);常规流程如下int epfd epoll_create(1024); struct epoll_event ev; ev.events EPOLLIN; // 关注可读事件 ev.data.fd listen_fd; // 用data.fd记住这属于哪个fd epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[1024]; while (1) { int n epoll_wait(epfd, events, 1024, -1); for (int i 0; i n; i) { // 处理 events[i].data.fd 上的事件 } }epoll的关键差异化设计在底层数据结构。内核维护一棵红黑树用来存你注册的所有fd和对应的事件。增删改查都是O(log n)不用全量扫描。每个fd有事件就绪时内核把它挂到一个就绪链表上。epoll_wait只需要把就绪链表的数据复制到用户态然后清空链表。换句话说内核通知你的是“已经准备好哪些”而不是“你去看看有哪些”。同时支持水平触发LT和边缘触发ET两种模式后面我专门展开讲这个。所以当连接数很大但活跃连接没那么多时epoll的优势接近降维打击——复杂度从O(n)变成O(就绪连接数)。下表把三兄弟的关键差异集中对比一遍维度selectpollepoll最大fd数受FD_SETSIZE限制默认1024无上限受系统限制无上限受系统限制用户态到内核态拷贝每次调用拷三组fd_set每次调用拷pollfd数组epoll_ctl注册时拷贝epoll_wait只拷就绪事件内核筛选方式线性扫描全部fd线性扫描全部fd红黑树管理注册fd 就绪链表反馈时间复杂度O(n)O(n)O(就绪fd数量)水平触发/边缘触发仅水平触发仅水平触发支持LT和ET跨平台几乎所有平台Windows、Linux都可用仅Linux适合场景连接少、教学、轻量工具连接较多但活跃度不极端高并发、海量连接、高吞吐3. 实战编码从零写一个基于epoll的TCP回显服务器3.1 代码整体结构设计理论知识再多不落地就是空中楼阁。我习惯用一个简洁的epoll回显服务器来演示整套链路客户端发什么服务端原样返回什么。别小看这个Demo它涵盖了服务端初始化、监听socket设置、epoll注册、事件循环、accept新连接、读写业务处理的完整闭环是深入学习的基础骨架。先搭框架#define MAX_EVENTS 1024 #define MAX_BUFFER_SIZE 4096 int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); // 设置端口复用避免TIME_WAIT状态导致重启后bind失败 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(9000); bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)); listen(listen_fd, 128); int epfd epoll_create(MAX_EVENTS); struct epoll_event ev; ev.events EPOLLIN; // 监听可读 ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); // 事件循环 struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd listen_fd) { // 处理新连接 } else { // 处理既有连接上的数据 } } } }这个结构是所有事件驱动服务端的基本盘。每次epoll_wait返回后你要区分“这是新连接来了”还是“已有连接有数据”这里的if判断就是事件分发器的雏形。3.2 新连接接入的处理细节当listen_fd出现在就绪事件里说明有客户端在握手。这里有一个非常关键的注意事项你得把新连接一次性全收下来而不是只accept一次。原因很简单可能同时有多个客户端连接完成如果只accept一个剩下的连接事件可能会在下一轮才再次通知但在高并发下这会增加延迟和瞬时压力。标准做法是while循环accept直到返回EAGAIN为止if (fd listen_fd) { while (1) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) { break; // 当前没有更多待处理的连接 } else { perror(accept error); break; } } // 把新连接加入epoll监控 ev.events EPOLLIN | EPOLLET; // 边缘触发模式后面展开 ev.data.fd conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ev); } }同时要给accept出来的conn_fd设置非阻塞属性因为后面配合EPOLLET边缘触发时非阻塞是必要条件。设置方式int flags fcntl(conn_fd, F_GETFL, 0); fcntl(conn_fd, F_SETFL, flags | O_NONBLOCK);我给每个新连接设置的监听事件是EPOLLIN | EPOLLET用边缘触发。这个模式下内核只在fd从“无事件”变成“有事件”的边界通知一次不反复提醒所以读数据时你必须一次性把缓冲区的数据全部读完直到返回EAGAIN否则剩余数据可能要等下一次新事件才能再触达——一旦有新事件覆盖旧数据可能就被卡住了。3.3 连接数据的读写策略收到可读事件后读写逻辑直接决定服务端的吞吐和稳定性。我习惯用read配合固定缓冲区char buffer[MAX_BUFFER_SIZE]; while (1) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { // 回显给客户端 write(fd, buffer, n); } else if (n 0) { // 读到0说明对端关闭连接 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据已经读完正常退出循环 break; } else { // 真正出错 close(fd); break; } } }这段代码对ET模式来说是标准写法一旦有读事件就循环读到EAGAIN。这里有个容易踩的坑写端write不一定能一次写完。比如客户端接收窗口变小socket的发送缓冲满了write可能返回EAGAIN。这时你可能要先把数据暂存到应用层缓冲区等待EPOLLOUT事件再继续发送。真正生产级的服务端一定是要处理写缓冲区的这里为了讲清楚多路复用的主线先不铺开大复杂但你要有这个意识。3.4 用全套代码串起来把上面几段拼在一起补全头部和细节就是一条非常完整的epoll服务端#include stdio.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include errno.h #include sys/socket.h #include sys/epoll.h #include netinet/in.h #include arpa/inet.h #define MAX_EVENTS 1024 #define BUFFER_SIZE 4096 int set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags -1) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } int main() { int listen_fd socket(AF_INET, SOCK_STREAM, 0); if (listen_fd -1) { perror(socket); exit(1); } int opt 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, opt, sizeof(opt)); set_nonblocking(listen_fd); 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(9000); if (bind(listen_fd, (struct sockaddr *)addr, sizeof(addr)) -1) { perror(bind); exit(1); } if (listen(listen_fd, 128) -1) { perror(listen); exit(1); } int epfd epoll_create(MAX_EVENTS); if (epfd -1) { perror(epoll_create); exit(1); } struct epoll_event ev; ev.events EPOLLIN; ev.data.fd listen_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, listen_fd, ev); struct epoll_event events[MAX_EVENTS]; while (1) { int nready epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i nready; i) { int fd events[i].data.fd; if (fd listen_fd) { while (1) { int conn_fd accept(listen_fd, NULL, NULL); if (conn_fd -1) { if (errno EAGAIN || errno EWOULDBLOCK) break; perror(accept); break; } set_nonblocking(conn_fd); ev.events EPOLLIN | EPOLLET; ev.data.fd conn_fd; epoll_ctl(epfd, EPOLL_CTL_ADD, conn_fd, ev); } } else { char buffer[BUFFER_SIZE]; int done 0; while (1) { ssize_t n read(fd, buffer, sizeof(buffer)); if (n 0) { write(fd, buffer, n); } else if (n 0) { done 1; break; } else { if (errno EAGAIN || errno EWOULDBLOCK) break; done 1; break; } } if (done) { epoll_ctl(epfd, EPOLL_CTL_DEL, fd, NULL); close(fd); } } } } }这段代码我已经在自己机器上跑过很多次回显功能是稳定的。但它离生产级还差很远——没有记录每个连接的应用层缓冲、没有超时机制、没有心跳检测、没有优雅关闭流程。这些最终都需要在对多路复用充分理解后一层层补上去。4. 水平触发与边缘触发的底层逻辑4.1 两种模式的真实区别水平触发LT是select和poll的内置行为只要某个fd还有数据没读每次调用都会通知你。边缘触发ET则是内核只在状态变化的“边缘”通知一次——比如数据从无到有那一刻提醒你之后即使你只读了一半内核也不会再提醒直到你把它读完或者新数据再次到来。打一个生活化的比方水平触发就像一个自动感应水龙头手没拿开就一直出水边缘触发像老式门铃你按一次响一次手一直按着不松开它也不会连续响。epoll默认是LT模式这是很多资料没强调的。如果你创建fd时只写EPOLLIN那就是LT要启用ET得写成EPOLLIN | EPOLLET。LT的好处是编程简单不用把数据一次性读完不会丢数据坏处是内核可能会多次通知同一个事件影响一点效率。ET的好处是通知次数少、处理及时性高适合高吞吐场景坏处是对编码要求高——必须循环读写直到EAGAIN否则可能漏数据。4.2 怎么选LT还是ET我的建议分成三个档位初学阶段先用LT把epoll_wait、事件分发这些先跑通避免读不干净的坑干扰对主流程的理解。通常业务用LT也完全能支撑大量连接事实上很多主流服务在默认配置下工作得很好不必盲目追求ET。极致性能场景例如网关、高吞吐代理用ET并配合非阻塞IO和循环读写能减少不必要的系统调用次数。还有一个非常实用的经验用ET模式时你的fd必须是非阻塞的。因为ET要求你会循环read到EAGAIN如果fd是阻塞的读完数据后read会卡在那里整个进程就卡死了。这个点面试常问实战也常翻车务必记牢。5. 高并发避坑指南我踩过的那些坑5.1 坑1epoll_wait超时时间理解错位很多人在epoll_wait的timeout传-1意为永久阻塞。这是合理的但要注意如果所有fd都没事件线程会一直睡在epoll_wait里如果服务端还有其他定时任务比如心跳检测就需要epoll_wait定期超时返回一次好让主循环有机会处理定时逻辑。更好的做法是把timeout设为定时任务的最小间隔例如100ms然后用当前时间减上次处理时间来判断哪些连接超时。强烈不建议用一个单独的定时器线程去遍历所有连接——如果连接数到了几十万每次全量遍历本身就是巨大的损耗。5.2 坑2误以为epoll_wait返回的events都是有效的epoll_wait返回的就绪事件里有的fd可能在你还没来得及处理时就被对端关闭了。所以别假设每个事件对应的fd一定可用读写之后要正确处理错误码if (fd -1) continue; if (events[i].events (EPOLLERR | EPOLLHUP)) { // 对端异常断开或挂断做清理 close(fd); continue; }EPOLLERR和EPOLLHUP这两个事件经常被新手忽略但它们恰恰在一些异常场景下会先于EPOLLIN到达忽略的话fd就泄漏了。5.3 坑3fd泄漏每个accept出来的连接最终都要在close时成对出现。我见过写服务端的人只在业务处理结束时close却忘了从epoll里删除fd。其实close(fd)会自动把fd从epoll中移除不用手动epoll_ctl(EPOLL_CTL_DEL)也可以但显式删除的好处是逻辑清晰可以防止某些怪异情况下的误用。还有更隐蔽的泄漏accept失败时没处理、连接的收发缓冲没清干净就close、main循环异常退出但listen_fd没关。建议在开发阶段用lsof或/proc/PID/fd查看fd数量如果发现连接断开后fd数不降赶紧查是不是漏了close。5.4 坑4边缘触发下循环读卡死ET模式下如果对端持续发数据你一直循环读一直有数据read就一直在返回这本来不是问题但如果你没处理好EAGAIN循环会一直在那里空转把CPU打满。解决思路read到EAGAIN就break单个连接连续读的总量加一个上限超过就先缓存把事件压回队列或者放到下次循环处理防止一个连接霸占CPU大批量数据下载场景适当考虑用一个独立的线程池做具体IO。6. 从单线程到多线程Reactor的演进思路6.1 单线程Reactor模型上面演示的epoll事件循环就是典型的单线程Reactor模型一个线程负责epoll_wait、accept、读写。优点简单、无锁、天然线程安全。 缺点一个连接的IO操作卡住整个服务端都阻塞。所以在这种模型下业务逻辑必须是非阻塞、快速返回的。适合场景Redis、部分代理、小型API网关。Redis之所以能单线程扛高吞吐核心就是所有命令内存级响应极快几乎不阻塞。6.2 多线程Reactor模型的部署当业务逻辑出现磁盘IO、数据库交互、耗时计算等场景单线程Reactor扛不住就要演进到多线程Reactor。主流做法是主线程只跑accept把新连接分发给多个子Reactor线程。每个子Reactor线程维护自己的epoll实例处理自己那批连接的读写和业务。这样每个连接只会被一个线程长期占有减少了锁竞争连接间的处理天然并行。如果你的业务里包含CPU密集计算甚至可以考虑再单独拉线程池处理计算任务事件循环只负责收发数据数据到了就往计算线程池里丢算完结果再通过事件循环写回。这是很多高性能服务器的通用架构框架。6.3 事件驱动架构的参考设计在设计高并发服务时我会把整个模块拆成四个角色连接管理器维护所有连接的fd、读写缓冲区、超时时间和状态。事件循环驱动epoll_wait执行事件分发。处理器具体处理读到的数据分发给业务模块或线程池。发送队列管理写缓冲和EPOLLOUT事件避免写阻塞。这套设计把多路复用从一个“能用”的接口变成一套“能扩展”的架构。你的服务能并发多少很大程度上取决于事件循环对每个连接的处理是否足够轻量。7. 实测表现压测数据带来的直观体感实践出真知。我用同一台虚拟机分别写了基于select和基于epoll的回显服务器用本机工具模拟并发连接。连接数在500以下时两者延迟差别不大都在毫秒级。但当连接数到5000select已经明显出现周期性延迟抖动CPU占用也偏高epoll依然平稳p99延迟基本维持在个位数毫秒。一旦把连接数推到2万以上select直接无法工作而epoll依然没有成为瓶颈。这背后的道理其实很简单select每次都要把2万个fd全量扫描一遍而epoll只需要关注真正活跃的几百个fd。也就是说活跃连接占比越低epoll的相对优势越大。极端情况下如果每个连接都在持续收发数据epoll的优势会被压缩但依然不会出现全量扫描的问题。如果你需要做实测可以先写一个客户端循环建立连接并定时发送心跳服务端打印当前连接数和epoll_wait的返回延迟。现象会非常直观。同时注意压测时要监控CPU、内存、句柄数三个维度别只盯着延迟。8. 挑选多路复用方案时的一些个人建议8.1 明确你能接受的内核依赖epoll是Linux专属。如果你的服务要跑在macOS、Windows或者其他Unix变体上要么用跨平台的libevent、libuv这类封装库要么自己包一层抽象接口。很多公司做中间件时选择对上层屏蔽IO模型的细节底层在Linux用epoll在其他平台退回kqueue或poll上层只看到统一的add、del、wait接口。这种设计虽然增加了工作量但跨平台迁移时就舒服很多。8.2 连接模型选型的判断公式以我个人经验连接类型大致能分两类低频连接连接建立后大部分时间闲置偶尔发个心跳或小请求。这类适合用LT模式省心不丢事件。高频流式数据比如视频流、消息推送、日志采集。这类适合ET模式减少重复通知吞吐更高。服务端设计没有银弹但核心思路是一致的少拷贝、少遍历、少阻塞、及时清理无效连接。理解了多路复用背后的原则换任何封装的网络库都能很快上手。8.3 最后分享一个开发阶段的实用技巧我在调试epoll服务时经常会在epoll_wait返回后加一段临时日志打印就绪fd数量和当前总fd数。这个日志在联调阶段帮过大忙——有一次线上疑似连接泄漏我在一次版本里短暂加了这段日志定位到是一条错误路径上accept成功后没有注册到epoll就提前返回后续数据永远没事件客户端干等连接也一直没释放。工具方面平时strace跟踪系统调用、lsof查fd、ss或netstat看连接状态都是调试网络服务的得力帮手。这套技能栈补上之后系统编程的地基才算真正打稳。