把上万个客户端连接压到一台普通服务器上，CPU 火焰图一打开，热点往往不在业务逻辑里，而在一个叫select的系统调用上。这不是段子，是我几年前接手某个后台连接服务时的直观感受：连接数从几百涨到几千，网络层最先撑不住，业务代码反而没什么动静。后来把多路转接从select迁到epoll，单机连接数上了一个量级，CPU 占用还降下来了。
epoll是 Linux 下解决“同时盯着大量文件描述符”问题的关键机制，也是现在高性能网络服务的标配底子。这篇文章我会把它拆开聊：为什么需要它、三个核心系统调用各自干什么、水平触发和边缘触发怎么选、内核里的回调机制为什么能撑住高并发，以及我在实战里踩过的几个典型坑。适合正在写网络服务的开发者、准备面试的同行，以及线上问题排查到半夜的人。
1. 从 select/poll 的“全民轮询”说起：多路转接为什么最后落到 epoll
1.1 多路转接的本质：一个人同时等很多扇门
“多路转接”这个名字容易劝退新人，但本质说穿了很简单：一个线程要同时监听几十上百个 socket，不能挨个accept之后就阻塞住等数据，因为那样其他连接就没人管了。传统解法是多线程，连接多了线程也跟着多，上下文切换开销立刻爆炸。所以有了 I/O 多路复用：一个线程把一堆文件描述符交给内核盯着，内核发现有任何一个可读或可写时回来通知你。
select是最原始的工具。它把关注的 fd 放进一个位图fd_set，调用时整个集合从用户态拷贝到内核态，内核线性扫描一遍所有 fd，发现就绪的再拷贝回用户态，最后开发者还得遍历fd_set找出到底是哪个 fd 有事件。poll改进了位图限制，变成动态数组，但本质依然是每次全量拷贝、全量扫描。
1.2 select 和 poll 的瓶颈：不是功能缺失，而是代价与规模脱钩
select有三个硬伤：第一，FD_SETSIZE默认只有 1024，连接数上来就必须改源码重新编译；第二，每次调用都要把全部 fd 集合在用户态和内核态之间来回搬运，连接数越大，这个拷贝越贵；第三，内核靠“遍历所有 fd”来查状态，扫描一遍1024个 fd 不算什么，扫描10000个、100000个就开始头疼了。
poll解决了 fd 数量上限问题，但仍然是每次把pollfd数组全量拷贝进内核，再全量遍历。也就是说，连接总量 N 再大，即使只有 2 个 fd 真正就绪，每次调用也要付出 O(N) 的扫描和拷贝代价。连接规模从几百涨到几万，这套模型的计算成本是同步线性增长的。更麻烦的是，用户态还需要再遍历一遍返回值才能知道哪些 fd 有事件，通知粒度是“集合级别”，不是“fd 级别”。
1.3 生活类比：点名式查询 vs 有事举手
如果把内核比作老师，select/poll就是每节课老师都从头到尾叫一遍全班同学名字，问“你有没有问题？”，哪怕只有两个人有问题，也要问完全班才知道是谁。而epoll是老师说“有问题的人举手”，然后只走到举手的同学旁边处理。区别不在于“老师有没有能力”，而是每次查询的代价跟全班人数脱钩了。
这也是epoll最核心的设计目标：从“每次都要访问所有连接”变成“只有连接状态变化时内核主动通知”。后续章节会看到，它靠的是事件回调、红黑树和就绪队列的配合，而不是某一种魔法。
2. 三个系统调用如何配合：epoll_create / epoll_ctl / epoll_wait 的角色拆解
2.1 从创建到注册：epoll_create 和 epoll_ctl 在内核里做了什么
epoll的整套接口只有三个系统调用，但对初学者来说，信息分散在各种源码里，连起来看才顺。
epoll_create(int size)用来创建一个epoll实例。老版本内核里size是预分配空间提示，2.6.8 之后这个参数基本被忽略，但必须传一个大于 0 的值，否则返回EINVAL。返回值是一个文件描述符，后面把它当作操作句柄用，用完必须close()，否则就是 fd 泄漏。
epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)负责把某个 fd 加入监控、修改监控事件、或删除监控：
- 操作码：
EPOLL_CTL_ADD/EPOLL_CTL_MOD/EPOLL_CTL_DEL - 事件类型：
EPOLLIN（可读）、EPOLLOUT（可写）、EPOLLERR（错误）、EPOLLHUP（挂断）、EPOLLRDHUP（对端关闭写端，2.6.17 之后可用）、EPOLLET（边缘触发）、EPOLLONESHOT（只通知一次）、EPOLLEXCLUSIVE（4.5 之后用于避免惊群）
从内核视角看，这个调用会做两件事：在红黑树中查找或插入对应的epitem节点，并建立 fd 与 eventpoll 实例之间的关联。红黑树的存在是为了保证O(logN)的增删改查复杂度，不会因为监控 fd 特别多而出现线性退化。
2.2 事件通知的“信号灯”：epoll_wait 的使用方式与返回值
epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)是真正“等待事件”的地方。它把就绪 fd 对应的事件拷贝到用户态events数组里，返回值是本次就绪的 fd 数量，后续遍历数组时只遍历返回值次数就够了，不需要遍历全量连接。
这里有几个容易误解的参数细节：
maxevents必须大于 0，它限制了本次最多拷贝多少个事件。如果实际就绪数超过maxevents，没拷贝走的事件会留在内核的就绪队列里，下次调用继续返回。timeout单位是毫秒，0表示立即返回（相当于非阻塞轮询），-1表示无限等待。- 返回值
0表示超时，-1表示出错。出错时最常见的EINTR是被信号打断，处理方式通常是continue重试，而不是直接退出循环。
很多刚上手的人会疑惑：为什么我在epoll_wait返回后还要自己判断EPOLLIN？因为一个 fd 上可能同时注册了读和写事件，也可能同时携带EPOLLERR和EPOLLHUP，必须用event.events & EPOLLIN这种位运算精确判断。
2.3 一个最小可用的 epoll echo server 代码骨架
纸上谈兵不够直观，我给一个最小可用的 echo server 核心循环，去掉错误处理细节，但保留了关键结构。
#include <sys/epoll.h> #include <fcntl.h> #include <unistd.h> #include <errno.h> #define MAX_EVENTS 1024 int main() { int lfd = socket(AF_INET, SOCK_STREAM, 0); // bind + listen 省略，lfd 已进入 LISTEN 状态 int epfd = epoll_create(1); struct epoll_event ev; ev.events = EPOLLIN; // 默认水平触发 ev.data.fd = lfd; epoll_ctl(epfd, EPOLL_CTL_ADD, lfd, &ev); struct epoll_event events[MAX_EVENTS]; while (1) { int n = epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i = 0; i < n; i++) { if (events[i].data.fd == lfd) { int cfd = accept(lfd, NULL, NULL); int flags = fcntl(cfd, F_GETFL, 0); fcntl(cfd, F_SETFL, flags | O_NONBLOCK); // 见第 3 章 struct epoll_event cev; cev.events = EPOLLIN | EPOLLET; // 边缘触发 cev.data.fd = cfd; epoll_ctl(epfd, EPOLL_CTL_ADD, cfd, &cev); } else if (events[i].events & EPOLLIN) { int cfd = events[i].data.fd; char buf[4096]; while (1) { // 边缘触发必须循环读 ssize_t r = read(cfd, buf, sizeof(buf)); if (r > 0) { write(cfd, buf, r); // echo } else if (r == 0) { close(cfd); break; } else { if (errno == EAGAIN) break; // 数据读完 // 其他错误: 关闭连接 close(cfd); break; } } } } } }这个骨架里已经埋了一个关键习惯：新接受的连接立刻设置O_NONBLOCK。为什么必须这么做，下一章详细展开。
3. LT 与 ET 不是玄学：水平触发和边缘触发的行为差异、适用场景与典型坑
3.1 触发机制的本质区别：数据水位 vs 状态跳变
epoll默认是水平触发（Level-Triggered，LT），可以显式加上EPOLLET切换为边缘触发（Edge-Triggered，ET）。
水平触发的语义是：只要 fd 上还有数据没读干净，epoll_wait就会反复通知你。读缓冲区里只要有 1 个字节，下次调用照样返回EPOLLIN。这跟select/poll的行为一致，心智负担小。
边缘触发的语义是：只有状态发生变化时才通知一次。比如缓冲区从“空”变为“有数据”，此时会通知一次；如果你这次没把数据读干净，内核也不会基于残留数据再通知你——除非又有新数据到达，触发了新一轮“空到有”的跳变。
3.2 ET 模式为什么必须配非阻塞 fd：一次没读完的连锁反应
ET 模式最大的坑就在这：如果read()用的是阻塞 fd，读完当前所有数据后下一次read()会直接阻塞线程，但数据可能永远不再来，线程就卡死了。所以 ET 模式要求 fd 必须是非阻塞的，并且应用层要用while循环读，直到read()返回 -1 且errno == EAGAIN才停。
同样，ET 模式下accept()也要循环调用。如果同一瞬间多个新连接同时到达，accept()只取了一个，剩下的连接已经“就绪”了但内核不会再产生新的边缘事件，新连接就会一直躺在 accept 队列里没人处理。正确写法是while (1) accept()，直到返回EAGAIN再退出。
| 对比维度 | LT 水平触发 | ET 边缘触发 |
|---|---|---|
| 通知频率 | 数据没读完就会反复通知 | 只看状态跳变，通知一次 |
| fd 模式 | 理论上可阻塞，但实践中也建议非阻塞 | 必须非阻塞 |
| 编程复杂度 | 较低，适合新手 | 较高，要求循环读/循环accept |
| 系统调用次数 | 数据多时可能反复唤醒 | 更少，适合大流量场景 |
| 适用场景 | 通用服务、开发调试 | 高吞吐网关、自己管理用户态缓冲 |
3.3 一张表的容量有限，实战选择强迫症
很多人纠结到底该用 LT 还是 ET，我的建议是：如果你的代码还处于“能跑就行”阶段，先老老实实 LT。LT 不会因为漏读一次而卡死连接，调试也容易。ET 的优势主要体现在减少事件重复通知上，但这是有代价的——你要么保证每次循环读干净，要么在用户态维护一个完整的接收缓冲区，把没读完的数据自己保存下来。
我见过不少项目，刚切到 ET 时吞吐确实涨了，但偶尔出现“连接半死”状态，就是因为某次read()收到部分数据后，业务逻辑把这次事件处理完了，剩下半包数据留在内核缓冲区，而新数据又没到，于是这条连接再也没有新事件。不是 ET 有问题，是使用者没理解“状态跳变只通知一次”这个前提。ET 更适合已经决定自己管理接收缓冲区的服务，比如配合内存池、环形缓冲使用。
4. 为什么 epoll 能扛住十万连接：内核回调、红黑树与就绪队列的配合
4.1 和 select/poll 的关键区别：从“每次全量拷贝”到“内核态持续维护”
select/poll的模型是“每次调用都把全量 fd 集合交给内核，内核扫完再返回”。epoll的模型是“通过epoll_ctl把 fd 注册进内核，内核长期持有这些连接的信息，事件发生时直接通过回调把对应连接放入就绪队列”。
也就是说，epoll把“维护监控集合”这件事从用户态挪到了内核态，代价只是注册和修改时需要一次epoll_ctl，之后的epoll_wait不需要再拷贝整个 fd 集合。这个差别在连接总量大的时候非常要命：前者是每次调用 O(N)，后者是每次调用 O(K)，K 是当前就绪的连接数。
4.2 就绪队列与回调机制：外设事件发生时真正发生的事
当一个 fd 上有数据可读时，内核网络协议栈在处理完数据后，会触发一个唤醒流程。epoll在注册 fd 时已经把自己的回调函数挂到了该 fd 的等待队列上，事件发生时这个回调会被执行，回调里做的核心动作就是把对应的epitem节点挂到 eventpoll 实例的rdllist（就绪链表）上。
epoll_wait做的事实际上很简单：检查rdllist是不是空，不空就把链表中记录的 fd 事件拷贝到用户空间数组。内核不需要扫描所有连接，只需要处理真正活跃的那几个。这也是它支持海量连接的关键——十万人里只有一两个人举手，老师不用挨个问。
红黑树在这里承担的是注册/修改/删除时的索引职责。比如你想把某个 fd 的监听事件从EPOLLIN改成EPOLLIN | EPOLLOUT，内核要在已经监控的集合里找到它，红黑树能保证这个查找是 O(logN)，而不是把链表从头到尾翻一遍。
4.3 复杂度错觉：O(N) 与 O(K)，以及隐藏的内存成本
很多人误以为“epoll 是万能的，连接数随便涨”，这是错觉。epoll解决的是事件通知复杂度与连接总量的解耦问题，但每多一个连接，内核里就要多维护一个epitem节点，红黑树节点和文件结构都会吃内存。十万连接意味着十万个 socket 结构、十万个接收缓冲区，内存不是凭空冒出来的。
另外，用户态events数组大小也要根据需求设置。如果maxevents设置太小，比如就绪队列里有 500 个事件，你只传了 64，那剩下的事件不会丢，而是留在就绪队列里，下次epoll_wait继续返回。这在某种程度上能帮我们避免丢事件，但也意味着处理不及时。我会把maxevents至少设置成工作线程的单次处理上限，几百到几千比较常见，太小会导致事件积压延迟。
5. 从“能跑”到“扛得住”：epoll 高并发实战中容易踩的坑
5.1 EPOLLOUT 导致 CPU 空转：一个极其隐蔽的 busy loop
新手最容易犯的错之一，是注册EPOLLOUT后忘记注销。EPOLLOUT表示“发送缓冲区可以写”，而 socket 的发送缓冲区大部分时候都是空的，也就是说，只要注册了 EPOLLOUT，epoll_wait 几乎每次都会立刻返回。
我处理过一个模拟项目 X 的线上案例：连接数只有几百，但 CPU 莫名其妙跑到 40%，epoll_wait每次都是立刻返回，几乎没有睡眠。排查后发现代码在建立连接时注册了EPOLLIN | EPOLLOUT，之后又没有在不需要写数据时把EPOLLOUT去掉。修改思路很明确：平时只注册EPOLLIN，真正要发数据时再通过EPOLL_CTL_MOD加上EPOLLOUT，发完立刻去掉。
5.2 accept/read 忘了循环：ET 模式下最常见的“半包”
第 3 章已经强调过 ET 必须循环accept和循环read，我再补一个实际影响：如果accept()只调一次，新连接可能滞留在 accept 队列里，客户端以为自己连上了，服务端却永远不会处理；如果read()只读一次，剩下的数据会一直滞留在接收缓冲区，直到对方再次发数据才能触发新的边缘事件。这两个 bug 的表现都是“连接静默、偶发卡死”，极难排查。
我现在写 ET 服务时会强制自己遵守两条纪律：一是所有网络 fd 建立或 accept 后立刻设O_NONBLOCK；二是循环读代码统一封装成read_until_eagain()工具函数，避免每次手写 while 出 bug。
5.3 多线程共享 epoll fd 的惊群问题
多线程模型里，如果多个线程同时阻塞在同一个epoll_wait上，一个新的连接事件到达后可能唤醒多个线程，但只有其中一个能成功accept，其他线程会白忙一场甚至直接accept返回失败。这就是“惊群”。
Linux 4.5 之后提供了EPOLLEXCLUSIVE标志，加在要监听的 fd 事件上，内核会尽量只唤醒一个等待线程，减少无谓调度。如果你的内核版本支持，建议对 listen fd 的事件加上这个标志；如果不支持，常见做法是所有线程各自创建自己的 epoll 实例，然后用某种负载均衡策略把连接分发到不同线程，而不是共享同一个实例。
5.4 对端关闭连接时的判断：EPOLLRDHUP 与 EPOLLHUP
对端正常close()时，内核会触发EPOLLRDHUP（如果注册了），同时read()会返回 0。很多只判断EPOLLIN的代码容易忽略一点：如果对端关闭，EPOLLIN也可能被触发，因为“读到一个 EOF”对内核来说也是一种可读状态。最稳妥的处理是同时注册EPOLLRDHUP，在事件处理里单独判断它，并检查read()返回 0 时主动关闭连接。
EPOLLHUP是“挂断”，通常意味着通信两端有问题，这种情况也要及时清理 fd。许多人只关注异常事件里的EPOLLERR，忽略EPOLLHUP，导致死连接占着 fd 不放。我的习惯是：注册时加上EPOLLERR | EPOLLHUP | EPOLLRDHUP，处理逻辑里一旦出现这些标志，优先排查连接是否还要保留。
5.5 排查思路：当 epoll_wait 返回频繁但业务没有流量时
遇到这种情况，我会按“惊群吗、误注册吗、fd 泄漏吗”三步走。先看是不是多个线程共享同一个 epoll 实例导致重复唤醒；再检查所有EPOLL_CTL_ADD的位置，尤其是EPOLLOUT是否不经意被加上；最后用工具看进程打开的 fd 数量是否持续增长，如果不断上涨，大概率是某个连接关闭后没有调用EPOLL_CTL_DEL和close()。
strace是我排查epoll_wait相关问题时最常用的工具，它可以直接打印每次epoll_wait的返回值和触发的事件类型。配合ss -tlnp之类命令看当前 socket 状态，很快就能把“频繁返回但没有业务流量”的根因定位到具体代码路径。
6. 不只是选 epoll：从并发模型到 io_uring 的边界扩展
6.1 epoll 适合哪些形态：长连接、短连接、重流量
没有完美的多路转接方案，只有适合场景的选择。
连接形态偏“多且活跃”的高并发网关，比如消息推送、即时通讯网关，epoll非常顺手。连接多但流量小——比如物联网设备上报心跳——epoll也能很好支撑，因为 fd 数量多本身不会让事件查询变慢。短连接高吞吐场景，比如普通的 HTTP 服务，epoll依然合适，但要特别注意accept风暴和频繁的 epoll_ctl 增删，这两者是短连接场景的主要开销来源。
如果只是十几二十个连接的内部工具，select甚至裸线程都能轻松应付，引入epoll不一定会带来多少收益。轻量是有代价的，代码复杂度就是其中之一。
6.2 现实工程中的组合：epoll + 线程池 vs 单线程 Reactor
epoll本身只是事件通知层，不是完整并发模型。常见组合有两类：单线程 Reactor 模式，也就是一个线程跑epoll_wait，连接事件触发后直接在当前线程处理业务；以及多线程版本，epoll_wait只负责分发事件，具体读写和业务处理交给工作线程池。
单线程模型在纯 I/O 场景下表现优异，很多知名缓存服务就是这种思路：避免锁竞争、避免上下文切换，一切串行化。不过一旦 CPU 计算繁重，单线程就扛不住了，这时要让epoll分发更轻量，把重计算挪到线程池。等到需要把连接级并行提升到极致时，就需要考虑 SO_REUSEPORT 之类内核能力与多进程模型的配合，但那已经是另一个话题了。
6.3 新一代 io_uring 与 epoll 的关系：两个时代的问题出发点
聊epoll绕不开最近越发活跃的io_uring。简单理解，epoll解决的是“等待事件”的效率，但真正读写数据时依然要发起read/write这类系统调用；而io_uring通过内核与用户态共享的环形队列，把“提交 I/O 请求”和“收割 I/O 结果”都变成异步非阻塞的，进一步减少系统调用次数。
那是不是io_uring出现，epoll就该被淘汰了？现阶段远没到那个程度。大量中间件和库仍然是构建在epoll体系上的，迁移成本很高，而且io_uring对使用者的要求更高，很多场景下收益不明显。我的判断是：epoll在可预见的未来依然是服务端网络编程的必修课，但学习路线里值得提前加上io_uring的视野，知道它解决的是什么层次的问题，等真正需要时再深入不会慌。
最后分享一个我自己的习惯：每接入一个 fd 到 epoll 时，我会在代码里用注释写明三件事——这个 fd 用的是 LT 还是 ET、归哪个模块负责关闭、是否需要处理EPOLLRDHUP。看起来是小事，但多线程下排查连接泄漏时能省大量时间。技术选型可以复杂，工程习惯越简单越好，这也是我从多次“线上 CPU 飙高”“连接莫名卡死”里学到的最实在的一条。
