如果你写过一个基于select或poll的 TCP 服务器大概率遇到过这样的尴尬连接数一旦涨到几千轮询扫描 FD 的开销直接吃掉大部分 CPU而换成“每个连接开一个线程”的思路线程上下文切换又让你不敢继续往上加连接数。我第一次被epoll惊艳是在一台配置很普通的机器上单线程事件循环扛住了上万条长连接当时我就意识到高并发网络服务这条路绕不开“事件驱动”这四个字而把事件驱动做规范、做优雅的经典框架就是Epoll-Reactor模式。这篇文章我会从 Reactor 模式的思想出发讲到epoll为什么适合当事件分发器再到如何用 C 语言徒手写一个最小可运行的Epoll-Reactor服务端最后聊多线程演进和我在实际调优中踩过的坑。适合正在学 Linux 网络编程的初学者也给想重构旧 IO 模型的老开发一点对比参考。整个链路我会尽量说人话但你也能感受到这套模式背后真正的设计功力。1. Reactor模式先搞清楚它解决了什么问题1.1 传统阻塞IO模型为什么撑不住高并发很多人刚学网络编程时写的第一个服务端大概是这样的socket、bind、listen然后在一个while循环里accept拿到客户端连接后read数据、处理、write返回。这个模型有个肉眼可见的问题read会阻塞如果当前客户端不发送数据服务端就卡在那个连接的read调用上其他客户端完全无法连接。于是新手进阶版的解决方案出来了主线程只做accept每来一个连接就创建一个子线程去服务它。这套“一个连接一个线程”的模型在小规模场景下非常好用代码也好写。但连接数一旦上千线程数跟着上千问题就来了每个线程默认栈空间不小8MB 虚拟内存上千线程内存压力很吓人线程切换成本高CPU 大量时间浪费在保存和恢复寄存器、内核栈上真正读到的数据可能只有几十字节大部分线程在阻塞等待资源利用率极低。所以我们需要一种机制让操作系统告诉我们“哪个 socket 现在可读了、哪个 socket 现在可写了”我们只需要在事件发生的时候去处理。这就是 IO 多路复用。1.2 事件驱动与Reactor的核心角色select和poll虽然能实现多路复用但它们本质上还是在每次调用时把所有 fd 集合从用户态拷贝到内核态内核再挨个遍历 fd 判断状态返回后应用还得再遍历一次才能知道哪些 fd 有事件。这个 O(n) 的复杂度在连接数万级时同样会拖垮性能。Reactor 模式在这样的背景下被广泛采用。它不是一个库也不是某个框架的专利而是一种设计思想把“等待事件”和“处理事件”拆开。组件上主要分成三个部分事件源这里就是 socket fd、监听 fd 等事件分发器Dispatcher/Reactor负责注册、监听这些事件源并在事件发生时把回调调度给对应的处理器事件处理器Handler真正执行业务逻辑的地方比如解析 HTTP 请求、回复数据。打个比方阻塞 IO 就像一个小餐馆每个顾客点菜都要一个服务员全程陪着服务员一多后厨反而乱Reactor 模式则是前厅只保留一个领班领班盯着所有桌子的“按铃”哪个桌子按铃了就叫对应的服务员去服务服务员忙完就回到待命状态。epoll就是这个最敏感的“按铃系统”它能精准告诉你哪一桌按了铃。搞清楚了这个背景你就明白为什么会有Epoll-Reactor这个组合Reactor 负责顶层架构epoll负责高效事件通知两者天然契合。2. Epoll三个API如何撑起事件通知机制2.1 为什么是epoll而不是select/pollselect的问题不光是 O(n) 遍历它对 fd 数量还有硬性限制默认上限是 1024虽然能改内核参数和宏重新编译但 fd_set 的位掩码设计本身就不适合大规模 fd。poll摆脱了 1024 上限却仍然要把全部 fd 传给内核每次调用都有全量拷贝的成本。epoll之所以是“事件驱动”的是因为它让内核维护了一棵红黑树来保存你关心的 fd同时维护一个就绪链表来记录真正发生事件的 fd。每次epoll_wait返回时应用拿到的就是已经准备好的事件不需要自己再遍历所有 fd。也就是说复杂度从 O(n) 变成了 O(就绪事件数)连接数越大收益越明显。我第一次跑压测时看到这个数据非常震撼同样的连接数select在 2000 连接时 CPU 已经接近 30%而epoll在一万连接时单核 CPU 仍然保持个位数。这不是微优化是数量级的差别。2.2 三个核心API的细节理解epoll使用起来很简单一共三个函数int epoll_create1(int flags); 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_create1传EPOLL_CLOEXEC是一个好习惯防止exec后 fd 意外泄漏到子进程。epoll_ctl的op基本就是EPOLL_CTL_ADD、EPOLL_CTL_MOD、EPOLL_CTL_DEL三件套。struct epoll_event是这个系统最关键的数据结构struct epoll_event { uint32_t events; /* 感兴趣的事件 */ epoll_data_t data; /* 用户自定义数据 */ }; typedef union epoll_data { void *ptr; int fd; uint32_t u32; uint64_t u64; } epoll_data_t;这里的data是联合体日常使用我会优先选择ptr而不是fd。因为项目里的连接一旦多起来你需要保存客户端地址、接收缓冲区、超时时间等一堆状态只用fd的话每次还得从 map 或数组里查直接用ptr把一个结构体指针挂上去事件回来时一步到位拿到这个连接的上下文效率高且语义清晰。事件类型方面最常用的几个EPOLLIN对应的 fd 有数据可读或对端关闭了连接半关闭EPOLLOUT对应的 fd 可以写入不会阻塞EPOLLET边沿触发模式这是与默认水平触发最大的分水岭EPOLLONESHOT事件只触发一次处理完需要重新注册这是多线程模型下防止事件重复分发的关键手段EPOLLRDHUP对端关闭连接从 2.6.17 内核开始支持可以更早知道关闭事件。事件标志里EPOLLERR和EPOLLHUP通常是自动上报的你不一定需要主动注册但代码里要处理这种事件否则连接出错了你可能完全无感知。3. 把Epoll改装成Reactor架构与组件划分3.1 单线程Reactor的动态流程Epoll-Reactor最简单的形态是单线程事件循环运行逻辑大致这样创建epoll描述符把监听 socket 注册到epoll挂上accept回调循环调用epoll_wait等待事件拿到事件后通过data.ptr找到对应的 handler 结构体调用该 handler 注册的事件处理函数处理完回到第 3 步继续等待下一个事件。整个流程里只有一个线程在跑。这意味着回调函数里绝对不能做耗时的同步操作比如数据库查询、外部 HTTP 调用、复杂计算。你要是做了其实阻塞的不是整个线程吗对所有连接的事件处理都被你拖住了。所以在单线程场景下业务必须足够短平快或者把耗时任务异步化、投递到线程池去执行。3.2 模块划分与事件处理器设计要把epoll用得像 Reactor最好先定义几个基础结构/* 事件处理器抽象 */ struct event_handler { int fd; uint32_t events; int (*callback)(struct event_handler *self); void *args; /* 业务上下文 */ struct reactor *reactor; /* 所属 reactor */ struct event_handler *next; /* 链表指针便于统一管理 */ }; /* reactor 核心 */ struct reactor { int epfd; int stop; struct event_handler *handlers; struct epoll_event *events; int maxevents; };这段设计里最重要的思想是所有 fd 都包装成 event_handler连接关闭后整个结构体统一释放。fd 不外露也就减少了很多裸close带来的问题。处理器不关心它处理的是监听 fd 还是普通连接只要事件发生就执行自己注册的callback。监听 fd 的回调是on_accept普通连接的回调是on_read/on_write/on_close。这种“统一接口 各自实现”的写法就是 Reactor 模式里“可扩展组件”的精髓。3.3 回调函数设计经验回调函数签名我建议统一返回int用返回值表示“这个 handler 是否要继续保留”。比如返回 0 表示正常返回 -1 表示需要关闭连接、释放资源。这样在主循环里可以统一做善后处理而不是每个回调内部各写一套 close 逻辑。还有一点是触发模式的选择。LT水平触发模式下只要缓冲区还有数据epoll_wait会不断上报EPOLLIN代码不容易漏数据但如果你对某个呆滞连接反复读、反复上报CPU 会空转。ET边沿触发模式下每次状态变化只上报一次你必须一次读完或写到EAGAIN对代码逻辑要求更高一旦没循环读完数据就留在缓冲区不会再有事件通知。我自己做高并发服务时读事件偏向 ET 非阻塞 while 循环读因为它能显著减少无谓的系统调用但如果团队里新手多、代码维护压力大LT 反而更稳妥。没有绝对好坏只有合不合适。4. 手写一个最小Epoll-Reactor服务端4.1 基础结构初始化先看主循环和初始化部分#include stdio.h #include stdlib.h #include string.h #include unistd.h #include errno.h #include fcntl.h #include sys/socket.h #include netinet/in.h #include sys/epoll.h #define MAX_EVENTS 1024 static int set_nonblock(int fd) { int flags fcntl(fd, F_GETFL, 0); if (flags 0) return -1; return fcntl(fd, F_SETFL, flags | O_NONBLOCK); } static int epfd; struct conn { int fd; int close_flag; char read_buf[4096]; int read_len; char write_buf[4096]; int write_len; int write_offset; };这里我把conn结构体当成这个连接的“所有状态”。为什么不用两个结构体区分连接和 handler早期我试过发现一个连接既要有 epoll 事件信息又要有业务缓冲区分拆之后每次都要互转指针非常容易越界或重复释放。合并的好处是一份内存管到底关连接时一个free就完事。4.2 事件循环主体核心循环void reactor_run() { struct epoll_event events[MAX_EVENTS]; while (1) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); if (n 0) { if (errno EINTR) continue; /* 被信号中断重来 */ perror(epoll_wait); break; } for (int i 0; i n; i) { struct conn *c events[i].data.ptr; uint32_t evs events[i].events; if (evs (EPOLLERR | EPOLLHUP)) { /* 错误事件优先处理 */ conn_close(c); continue; } if (evs EPOLLIN) { conn_on_read(c); } if (evs EPOLLOUT) { conn_on_write(c); } } } }这里有几个容易忽略的地方。第一epoll_wait的timeout参数我用了-1表示永久阻塞。如果你的程序有周期性任务比如心跳扫描、超时关闭空闲连接就不能这样写建议改成50或100毫秒的超时让 loop 能反复醒来做定时检查。但要注意超时太短会让进程在没事件时频繁空转CPU 飙高。第二events[i].data.ptr必须是刚才 4.1 里我们注册进去的conn指针。如果注册时挂的是fd这里还得自己查。我建议一律挂指针但你要保证这个指针的生命周期在epoll_wait期间是有效的。很多诡异崩溃都来自这里一个连接已经 close 并 free但内核 epoll 里还残留着它的指针事件来了一访问就是野指针。为了避免这种情况关闭连接时一定要先epoll_ctl(..., EPOLL_CTL_DEL, fd, NULL)再close(fd)再free(conn)顺序不能乱。先 close 再 DEL 也不是不行但一旦 fd 被系统回收后复用而 epoll 里还挂着旧信息新连接就把旧事件顶掉了这就会产生各种难以复现的 bug。4.3 监听fd的accept回调监听 socket 的注册方式比较特殊它的事件处理器挂在监听 fd 上而不是普通连接上static void accept_cb() { struct sockaddr_in addr; socklen_t len sizeof(addr); while (1) { int cfd accept(listen_fd, (struct sockaddr *)addr, len); if (cfd 0) { if (errno EAGAIN || errno EINTR) break; perror(accept); break; } set_nonblock(cfd); struct conn *c calloc(1, sizeof(*c)); c-fd cfd; c-events EPOLLIN | EPOLLET; struct epoll_event ev; ev.events c-events; ev.data.ptr c; if (epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, ev) 0) { perror(epoll_ctl add); close(cfd); free(c); continue; } } }accept这里用了while (1)这是 ET 模式的关键。因为accept只能通知你一次“有连接到达”如果只 accept 一个就回主循环同一批剩下的待连接连接就不会再触发EPOLLIN了。千万要在一次事件里把所有积压的连接都 accept 完直到返回EAGAIN。还有一个细节accept拿到的cfd必须立刻设非阻塞。不管是 LT 还是 ETRead 操作如果不设非阻塞一遇到缓冲区没数据就卡死整个线程。这个失误我见过太多次症状就是“服务器一压测就停”实际上线程卡在某次 read 上了。4.4 读写回调与善后逻辑读回调static void conn_on_read(struct conn *c) { char tmp[4096]; while (1) { ssize_t n read(c-fd, tmp, sizeof(tmp)); if (n 0) { /* 追加到 conn 的读缓冲越界要防 */ if (c-read_len n (int)sizeof(c-read_buf)) { /* 缓冲区满按业务规则处理关连接或报错 */ conn_close(c); return; } memcpy(c-read_buf c-read_len, tmp, n); c-read_len n; } else if (n 0) { /* 对端关闭 */ conn_close(c); return; } else { if (errno EAGAIN) return; /* 数据读完正常返回 */ if (errno EINTR) continue; conn_close(c); return; } } }n 0说明对端正常关闭了这时做关闭动作。n 0 errno EAGAIN表示当前没有更多数据对 ET 模式而言正是退出循环的信号。如果你用的是 LT 模式其实不需要 while 循环多读一次也无妨但如果缓冲区有大量数据LT 会反复唤醒这就是 ET 更高效的原因之一。写回调一般发生在什么时机一个常见场景是业务处理完需要给客户端回写数据。如果你直接在on_read里send数据量小还好数据量大时send可能只发了一部分剩余部分要等EPOLLOUT事件。这时就要在on_read里把没发完的数据暂存到c-write_buf然后注册EPOLLOUT。写回调再继续发发完后记得要把EPOLLOUT从关心事件里摘掉不然这个 socket 永远可写epoll_wait会疯狂上报写事件形成忙轮询白白烧 CPU。4.5 连接关闭的统一出口我强烈建议所有连接关闭都走一个函数conn_close不要在业务回调里散落close(fd)、free(c)static void conn_close(struct conn *c) { if (c-close_flag) return; epoll_ctl(epfd, EPOLL_CTL_DEL, c-fd, NULL); close(c-fd); c-close_flag 1; free(c); }这样能避免重复关闭。如果不设close_flag同一个 fd 可能在读回调和写回调里各走一次关闭第二次的epoll_ctl(DEL)就会失败报文件描述符不存在虽然不致命但排查时非常干扰视线。更隐蔽的问题是对端断开后错误包和读事件先后到达两次触达同一连接没有保护就直接 double free程序直接崩。5. 多线程演进单Reactor与主从Reactor怎么选5.1 三种常见方案的对比手写版单线程Epoll-Reactor能解决大部分长连接高并发场景但面对图像处理、复杂业务计算这类 CPU 密集型任务单线程回调再快也只有一个核在跑。这就得考虑多线程。网上的多线程 Reactor 方案五花八门归纳起来大致是三类单 Reactor 业务线程池主线程只有 epoll 做事件监听和 IO 读写把业务计算丢给线程池。这个方案实现简单但主线程如果还在做读缓冲拷贝和大包解析压力依然大单 Reactor 多线程 IO让多个线程各自创建 epoll监听不同的 fd 集合。连接分配时可以按哈希但迁移和负载均衡很麻烦主从 Reactor 多线程一个主 Reactor 只负责 accept把接受的连接均匀分发给多个子 Reactor每个子 Reactor 有自己独立的 epoll 和事件循环线程业务处理再配合线程池。这也是很多高性能网络库采用的结构。我个人的经验连接数一万以内单 Reactor 线程池足够连接数十几万甚至上百万主从 Reactor 的扩展优势才会显现因为单线程 epoll_wait 在大规模条件下也有锁和系统调用开销。5.2 线程池引入后的安全隐患多线程场景下最坑的是“一个连接的事件被两个线程同时处理”。epoll_wait返回后你把这个 fd 的事件交给线程池同时主循环继续等待下一个事件。如果该 fd 又变可读了主循环再次投递两个线程同时操作同一个 connection 的缓冲区数据竞争立刻出现。解决办法有两个思路。一个是用EPOLLONESHOT保证事件触发一次后这个 fd 在重新注册前不会再上报事件这样事件不会同时进来另一个是给每个连接加锁但锁的开销很大而且容易写错。实践中我更推荐EPOLLONESHOT 业务线程池组合线程池处理完业务后调用epoll_ctl(..., EPOLL_CTL_MOD, fd, ...)重新注册事件。注意重新注册时一定要带上你需要的全部事件类型别只把EPOLLIN加回。如果同时关心EPOLLOUT而注册时漏掉写事件就永远不会触发。5.3 线程池队列的背压问题线程池任务队列不是无限长的。如果你的业务处理速度跟不上事件上报速度任务队列会越积越长内存飙升延迟变大。我踩过一次非常惨的坑压测时把事件全部塞进无界队列内存涨到几个 G压测结束后任务还在慢慢跑线上本来就该快速失败拒绝新连接结果我硬生生跑成了排队调用。所以任务队列要有上限满了就断开新连接或丢弃任务。网络服务最怕的不是瞬时压力而是资源耗尽后的连锁雪崩。6. 调优、避坑与问题排查速查6.1 系统参数与 epoll_wait 超时写网络服务之前先看一眼系统的 fd 限制。默认的ulimit -n可能是 1024一个连接占一个 fd你最多只能同时开 1000 个连接再往上是Too many open files。测试前先改ulimit -n 100000系统级的file-max也要注意/proc/sys/fs/file-max表示内核全局可用文件句柄数。高并发调优时经常需要调高但它受到内存限制不能随手改到天文数字。epoll_wait的maxevents参数也有讲究它不能大于你传入的 events 数组长度。常见误用是数组就分配 128maxevents 传 1024内核拷贝越界直接报错。那我数组分配多大合适一般 1024 够用如果你知道高峰可能有上万事件同时就绪就分配对应大小。赋值时最好用sizeof(events) / sizeof(events[0])而不是硬编码避免改数组时忘了改参数。6.2 信号中断与EINTR问题epoll_wait是阻塞调用一旦进程收到信号它可能被直接打断返回 -1errno设为EINTR。新手最容易在这个地方犯浑看到epoll_wait返回 -1 就 panic直接打印错误退出进程或者不加判断继续走循环。正确做法是遇到EINTR就continue不要把它当异常。这一点我在 4.2 的代码里已经写出来了但再强调一次因为线上很多偶发性的“CPU 跳高”或者“服务假死”都和它有关。还有一个延伸问题如果在信号处理函数里做了不安全的操作比如打印、调用非异步信号安全函数可能破坏主循环状态。我的习惯是信号处理函数里只设置一个volatile sig_atomic_t标志主循环里再检查这个标志决定是否平滑退出。6.3 我踩过的几个坑整理下面这张表是我自己在实现 Epoll-Reactor 过程中踩过的典型问题很值得复制下来贴在工位上具体现象根因分析解决方案压测时线程卡死CPU 0%accept 或 read 后没设置非阻塞ET 模式下读到缓冲区空就一直阻塞所有连接 fd 在 accept 后立刻O_NONBLOCKEPOLLOUT疯狂触发CPU 满载写回调处理完数据没取消EPOLLOUT事件写完后epoll_ctl(MOD)把 events 改为只关心EPOLLIN随机段错误压测必现连接关闭后没从 epoll 删除fd 被复用后 data.ptr 悬挂统一conn_close先 DEL 再 close 再 free数据明明发了一部分客户端收不全ET 模式下没循环 send剩余数据没有写回调补充写缓冲未清空时注册EPOLLOUT发完再摘除客户端断开后服务端没感知只注册了EPOLLIN没处理EPOLLRDHUP或读返回 0注册EPOLLIN | EPOLLRDHUPread 返回 0 时关闭连接数一高就Too many open files用户级/进程级 fd 限制未调修改ulimit -n必要时调整/etc/security/limits.conf6.4 日志与调试心得遇到疑难 bug不要凭眼睛瞪着屏幕猜。我调试 epoll 相关的崩溃问题时最有效的工具是带 fd 号的信息日志。每个关键步骤都打印事件注册ADD fd12 eventsEPOLLIN事件分发READY fd12 eventsEPOLLIN|EPOLLOUT连接关闭CLOSE fd12当你发现某个 fd 关闭后还收到 READY大概率是资源生命周期管理出问题了顺着日志就能锁定到哪一行的回调没有正确清理。这比 gdb 打断点更高效因为高并发下的崩溃往往很难原地复现。再补一个小建议在epoll_ctl失败时除了perror最好把当前 fd 号和操作类型也打出来。EBADF、EEXIST、ENOENT这三个错误码在调优阶段出现频率极高看到日志你能秒懂是重复添加、重复删除还是 fd 已失效。最后分享一个我自己的经验刚学 Epoll-Reactor 的时候不要急着上多线程、主从 Reactor先拿单线程版本跑通一个小型消息推送服务故意压几次断开连接场景把所有生命周期问题暴露出来再演进线程池也不迟。这套模式看着只有几段代码真正的复杂度全在连接状态的收放之间把“善后逻辑”梳理清楚了高并发这条路才算真正迈过门槛。