先问个问题：你在线上是不是也遇到过这样的场景——连接数一上来，进程的CPU就飙到80%以上，但实际吞吐量却低得可怜，请求延迟动不动就几百毫秒？我当年排查这类问题的时候，脑子里只有一个念头：这个服务根本不是在“处理”连接，而是把所有时间都花在“检查这些连接有没有数据来”上面了。后来把核心模块从多线程阻塞模型改成epoll驱动的事件模型，同一台机器上，连接数从几千涨到几万，CPU反而降了一半，延迟也稳住了。这篇文章就把epoll从内核原理到工程落地完整拆开讲一遍，算是这个系列的终篇，适合已经接触过并发编程、想彻底搞懂epoll并且能直接用到生产环境的朋友。
epoll是Linux上最核心的高并发I/O多路复用方案，它解决的问题非常纯粹：在数百万文件描述符中，快速找到那些真正“可读”或“可写”的fd，并交给应用程序处理。相比老一代的select和poll，epoll把“轮询所有fd”变成了“主动通知你哪些fd有事件”，性能不再随着连接数增加而线性劣化。这篇文章会从内核数据结构和事件通知机制讲起，配合可直接落地的TCP服务端代码、边缘触发的正确玩法、生产环境的坑和调优手段，把epoll从原理到使用一次说透。
1. 先搞懂为什么是epoll：从C10K到多路复用
1.1 阻塞I/O的瓶颈到底在哪里
要理解epoll的价值，得先回到最原始的阻塞I/O模型。最朴素的写法是：每个连接分配一个线程，线程里调用read()去等数据，没有数据就挂起。这种模型在线少的时候没问题，但想象一下：一个线程的内核栈默认是8MB左右，加上用户态各种资源开销，你开个一万个线程试试，内存直接爆掉。更致命的是，线程切换是有开销的。内核要保存上下文、调度、切换，当活跃线程数量超过CPU核心数很多倍时，大量时间耗在切换上，真正的业务逻辑反而跑不动。
所以大家很快意识到：我不能让一个线程去等一个连接，那样线程和连接的比例是1:1，撑不住。正确的思路应该是少量线程去管理大量连接。怎么管？通过I/O多路复用：调用一个系统调用，传入一批fd，内核告诉你哪些fd有事件发生。有事件就处理，没事件就继续等。这样线程和连接的比例可能变成1:上万。
1.2 select和poll到底差在哪
select是第一个被广泛使用的多路复用方案，但它有几个非常让人头疼的限制。第一，fd数量有上限，FD_SETSIZE通常是1024，意味着你一个进程最多管1024个fd，C10K问题解决不了。第二，每次调用select()，你得把全部fd集合从用户态拷贝到内核态，等内核检查完了再拷贝回来，这个全量拷贝的开销随fd数量线性增长。第三，内核检查fd状态的方式是遍历，也就是挨个看每个fd是不是可读可写，O(n)的复杂度，fd越多越慢。
poll针对fd上限做了改进，去掉了1024的限制，用的是链表结构，但“全量拷贝+全量遍历”这两个本质问题依然存在。也就是说，几万fd的时候，每次调用内核都要扫描一遍全部fd，活跃的fd比例很低，绝大多数检查是白做的。用生活类比就是：你有个几千人的通讯录，每次都要挨个打电话问“你有事吗”，结果往往只有几个人真有事，这个效率肯定是灾难。
1.3 epoll胜出的关键：由事件驱动，而不是轮询
epoll思考问题的方式完全换了一个角度。它不让你每次把全部fd传给内核，而是让你先把关注哪些fd告诉内核，内核负责记住；之后某个fd有事件了，内核主动把它放进一个就绪列表，你调用epoll_wait()的时候内核只把“真正就绪的fd”返回给你，没有事件就挂起等待。
这种“被动通知”机制最大的好处是，时间复杂度和总连接数无关，只看就绪fd的数量。假设你有10万个连接，但同一时刻只有100个请求到达，epoll只需要返回这100个就绪事件。内核在底层维护好数据结构，等事件发生再回调，而不是每次傻乎乎地扫描全部。这就是epoll能在高并发场景下胜出的核心原因。
2. epoll的内核原理：三个数据结构与一条通知链路
2.1 从一次socket连接开始：内核怎么知道你关注的fd
理解epoll，建议先把内核里的几个关键角色搞清楚。当你调用epoll_create()时，内核创建一个eventpoll对象，这个对象里有两个最重要的成员：一个红黑树和一个双向链表。红黑树用来存你关心的所有fd，双向链表用来存“已经就绪待处理”的fd。注册fd用的epoll_ctl(EPOLL_CTL_ADD)，就是把fd信息插入红黑树；当fd上的I/O事件发生时，内核会找到这个红黑树节点，把它对应的epitem移动到就绪链表里。
这里最关键的是一个“回调机制”。每个通过epoll注册的fd，它的底层socket结构里都有一个等待队列（wait queue）。内核的驱动代码在不同事件发生点会触发对应的回调函数。比如网卡收到数据包、协议栈把数据放入socket接收缓冲区之后，会调用wake_up()遍历等待队列，而epoll早就在这个等待队列里放了一个自己的回调函数——ep_poll_callback。这个回调做的事很简单：把当前fd对应的epitem加入就绪链表，然后唤醒正在epoll_wait()里睡眠的进程。
这个设计你可以理解成一个“钓鱼竿+铃铛”的联动：把竿子（fd）交给epoll这个管家，管家在鱼钩上挂好铃铛（回调）。鱼一咬钩（数据到达），铃铛立刻响，管家马上把人叫过来收货。整个过程不需要挨个去检查所有竿子，哪个响了处理哪个。
2.2 红黑树与就绪链表：为什么增删改查都高效
红黑树的引入解决了两个问题：一是快速查找。当你要从epoll里删除一个fd的时候，不需要遍历整个集合，红黑树查找复杂度是O(log n)，即使有几十万fd，删除操作也是毫秒级的。二是保持有序。红黑树本身是带颜色的平衡二叉搜索树，任何时候插入、查找、删除都可以高效完成。很多初学者不理解“为什么非要用红黑树”，其实核心就一句话：fd的数量可能非常多，而 Linux 内核必须保证对大量fd的管理成本可控，链表插入是O(1)但查找是O(n)，哈希表理论上更快但实现复杂且存在冲突处理成本，红黑树在一个效率和复杂度之间非常平衡的工程选择。
就绪链表则负责承载“就绪事件”的传递。它每个节点对应一个发生了I/O事件的fd。epoll_wait()的逻辑很简单：检查就绪链表是否为空，空就睡眠，不空就把链表里的节点拷到用户态，然后清空。注意这个过程也不是把全部连接扫描一遍，而是扫描“发生了事的连接”，这就是性能优势的核心来源。
2.3 水平触发与边缘触发：同一份数据，两种通知方式
epoll提供了两种事件触发模式，很多人面试都会被问，但真正用起来才明白其中的坑。
水平触发（LT，Level Triggered）：只要fd上有数据可读，每次epoll_wait()都会返回这个fd。也就是说，你一次没把数据读完，下一次调用还是会通知你。这个是epoll默认模式，也是最安全、最容易理解的方式。它的语义和select/poll一致，对于不熟悉触发模式的人建议先用LT。
边缘触发（ET，Edge Triggered）：只在fd的状态发生“跳变”时通知一次。什么叫跳变？比如缓冲区从“没有数据”变成“有数据”，这是一次上升沿；从“有数据”变成“没有数据”，是下降沿。ET模式下，只有上升沿会触发通知。如果你在通知之后没有把数据全部读完，剩余数据不会再次触发通知，直到下一次新的数据到达，产生新的上升沿。
ET模式听起来更“高效”，因为减少了重复通知，但用不好非常容易丢数据。ET模式下收数据，你必须配合非阻塞fd，并且要循环read()直到返回EAGAIN，因为一旦有数据到来只通知一次，你不读完就亏了。LT模式下read一次没读完也没关系，下次继续。后面我会专门讲这个坑，这也是生产环境最容易翻车的地方。
2.4 理解epoll_wait的睡眠与唤醒
epoll_wait()系统调用在内核态的逻辑可以简化为三步。第一步，检查就绪链表，如果有事件直接拷给用户态返回；第二步，如果没有事件，把当前进程挂在eventpoll对象的等待队列上，然后主动睡眠；第三步，等某个fd事件触发回调之后，回调函数会唤醒等待队列里的进程，进程醒来后再次扫描就绪链表，取走事件返回。
这里要注意一个细节：真正被唤醒的进程不一定立刻就能抢到所有事件，因为可能有多个线程同时调用epoll_wait()等待同一个epoll实例。这种情况就是著名的“惊群”问题，后面第4章会详细讲。能够睡眠和唤醒，依赖的是Linux内核的等待队列机制，这也是epoll能实现“事件驱动”的根本原因——没有事件时进程不占CPU，有事件时立刻被叫醒。
3. 从API到实战：手写一个可用的epoll服务
3.1 三个系统调用的正确打开方式
epoll的用户态API只有三个函数，简单到让人怀疑，但细节非常多。
第一个是epoll_create：
int epollfd = epoll_create(1);旧版本里这个参数告诉内核期望管理的fd数量，新版本内核会忽略这个值，只需要传一个大于0的整数即可。也有人用epoll_create1(EPOLL_CLOEXEC)，这个更好，因为给返回的fd自动加上了close-on-exec标志，避免在调用exec()时泄漏给子进程。
第二个是epoll_ctl：
struct epoll_event ev; ev.events = EPOLLIN; // 监听可读事件 ev.data.fd = client_fd; // 自定义数据，常用来存fd或指针 epoll_ctl(epollfd, EPOLL_CTL_ADD, client_fd, &ev);EPOLL_CTL_ADD用来添加fd，EPOLL_CTL_MOD用来修改事件类型，EPOLL_CTL_DEL用来删除fd。很多人忽略了一个点：epoll_event.data是个联合体，你可以存fd，也可以存指针。工程上我习惯存一个结构体指针，里面包含fd、读缓冲区指针、业务状态位等，这样epoll_wait返回后能直接拿到上下文，避免用全局映射表查来查去。
第三个是epoll_wait：
struct epoll_event events[1024]; int n = epoll_wait(epollfd, events, 1024, -1);events数组用来接收就绪事件，数组大小自己定，建议不要太大，典型值64到1024。timeout传-1表示永久阻塞，传0表示立即返回，传正数表示最多等多少毫秒。有人说epoll_wait返回后还要遍历整个数组去检查每个fd，性能损耗很大。实际上这个数组里只有就绪的fd，不是全部fd，所以遍历成本低得多。
3.2 手写一个完整的TCP服务端骨架
我直接给一个最小可用的例子，这个骨架去掉了复杂的业务逻辑，保留了epoll服务的关键路径。它做的事是：监听一个端口，把监听socket注册进epoll，然后循环处理accept事件和读写事件。
#include <stdio.h> #include <stdlib.h> #include <string.h> #include <unistd.h> #include <errno.h> #include <sys/epoll.h> #include <sys/socket.h> #include <netinet/in.h> #include <fcntl.h> #define MAX_EVENTS 64 #define PORT 8080 static int set_nonblock(int fd) { int flags = fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); return 0; } int main() { int listen_fd = socket(AF_INET, SOCK_STREAM, 0); int opt = 1; setsockopt(listen_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt)); set_nonblock(listen_fd); struct sockaddr_in addr; memset(&addr, 0, sizeof(addr)); addr.sin_family = AF_INET; addr.sin_port = htons(PORT); addr.sin_addr.s_addr = htonl(INADDR_ANY); bind(listen_fd, (struct sockaddr*)&addr, sizeof(addr)); listen(listen_fd, 512); int epollfd = epoll_create1(EPOLL_CLOEXEC); struct epoll_event ev; ev.events = EPOLLIN; ev.data.fd = listen_fd; epoll_ctl(epollfd, EPOLL_CTL_ADD, listen_fd, &ev); struct epoll_event events[MAX_EVENTS]; for (;;) { int n = epoll_wait(epollfd, events, MAX_EVENTS, -1); if (n < 0) { if (errno == EINTR) continue; break; } for (int i = 0; i < n; i++) { if (events[i].data.fd == listen_fd) { // 处理新连接 for (;;) { int conn_fd = accept(listen_fd, NULL, NULL); if (conn_fd < 0) { if (errno == EAGAIN || errno == EWOULDBLOCK) break; break; } set_nonblock(conn_fd); struct epoll_event c_ev; c_ev.events = EPOLLIN; // LT模式 c_ev.data.fd = conn_fd; epoll_ctl(epollfd, EPOLL_CTL_ADD, conn_fd, &c_ev); } } else { // 处理可读事件 int fd = events[i].data.fd; char buf[4096]; ssize_t r = read(fd, buf, sizeof(buf)); if (r <= 0) { close(fd); epoll_ctl(epollfd, EPOLL_CTL_DEL, fd, NULL); } else { // 这里只是演示，你可以在真正的业务里处理数据 write(fd, buf, (size_t)r); } } } } return 0; }这段代码有几个点值得注意。
监听fd也设置成非阻塞，然后accept()外面再套一层循环，直到返回EAGAIN才退出。为什么？因为在LT模式下，只要监听fd可读，epoll_wait每次都会返回它。如果你只accept一次，多个连接同时到来时，剩下的连接会滞留在内核队列里，但只要监听fd还有连接可接受，epoll会持续通知你，这一般不会丢数据，但处理不及时会影响新连接接入速度。用循环把所有pending的连接都收下来更高效。
还有一点容易被忽略：当read()返回0的时候，说明对端关闭了连接，这时候别忘记从epoll里删除fd并close。有些人只关fd不删epoll，结果epoll里留着一个已关闭的fd，下次epoll_wait返回事件，处理时发现fd无效，白处理一趟。
3.3 关于ET模式你必须知道的细节
上面代码用的是LT模式，也就是默认模式。如果你想把conn_fd改成ET模式，只需要：
c_ev.events = EPOLLIN | EPOLLET;但架不住这里面的连环坑。ET模式的通知语义是“状态跳变只通知一次”。假设客户端发来1000字节，内核通知你可读。你只read()了500字节，剩下的500字节依然在缓冲区里，但内核不会再通知你了。下次想要被通知，除非又有新数据到达，产生新的上升沿，但谁能保证新数据一定来？这就是ET模式下数据滞留的典型原因。
所以ET模式的标准姿势是：循环读，直到返回EAGAIN。
char buf[4096]; for (;;) { ssize_t r = read(fd, buf, sizeof(buf)); if (r > 0) { // 处理这批数据 } else if (r == 0) { // 对端关闭 close(fd); break; } else { if (errno == EAGAIN || errno == EWOULDBLOCK) { break; // 数据已经读完 } // 真正的错误 close(fd); break; } }这里就带出了另一个强制性要求：ET模式下fd必须是非阻塞的。原因很简单，如果你用阻塞fd，最后一次read()把缓冲区数据读完了，再次read()会一直阻塞在那里等新数据，整个服务就卡死了。只有非阻塞fd才能在你读不到数据时立刻返回EAGAIN，从而让你知道“这次真的读完了”。
当然，LT模式也可以用非阻塞fd，甚至建议都这么做。但在LT模式下，如果你不要求读取完，漏掉一点数据问题不大，因为下次还会通知。用阻塞fd配合LT模式也行，但那样可能被某个慢客户端拖死进程，所以工程上统一推荐非阻塞。
4. 实测中踩过的坑：epoll避坑清单
4.1 ET模式下的“饥饿”问题
ET模式的高效来自“只通知一次”，但如果一个连接特别活跃，一直有数据进来，它就可能一直占据你的处理循环。我举一个真实场景：某个连接在持续大流量下载文件，数据源源不断到来，read()永远有数据可读，ET模式下你会一直循环读。如果你的服务模型是“单线程主循环里同步处理”，这个活跃连接会让后续所有事件排队等待，其他连接得不到响应，连接被饿死。用术语说就是“饥饿问题”。
解决思路有几个方向。一般建议在一个fd的数据处理里设置一个预算，比如最多连续读多少次或读多少字节，到预算后就暂停处理，即使缓冲区里可能还有数据，也先把控制权交还给epoll_wait，让其他事件有机会处理。但这里有个逻辑悖论：ET模式下如果不读完，不会再有新事件通知。所以更稳妥的方案是，不在ET模式下做复杂的多事件轮流处理，而是配合多线程：主线程负责派发事件，工作线程负责实际执行读写，这样即使单个连接处理耗时较长，也不会阻塞其他连接的事件派发。
4.2 惊群效应与EPOLLONESHOT
惊群问题在epoll里也很经典。当你用多线程模型时，多个线程同时阻塞在同一个epoll fd的epoll_wait()调用上。一个事件到来时，内核会唤醒所有等待线程，但最终可能只有一个线程真正处理这个事件，其他线程白醒一场，空跑了调度和唤醒开销。这么描述可能有点抽象，你想象一下：办公室里有人说“有活了”，结果所有人立刻从工位上站起来，最后只有一个人被分配了任务，其他人再坐下，来来回回全是无用功。
解决方案之一是EPOLLONESHOT。给fd注册事件时加上这个标志后，这个fd触发一次后就会被自动从epoll中禁用，直到你主动调用epoll_ctl重新为它注册。这保证了同一个连接在某一时刻只会被一个线程处理，不会出现多个线程同时处理同一个fd的竞态。而且因为fd在事件处理后需要你手动重新注册，正好给线程切换处理和重新武装留出了时间，避免处理期间又被唤醒。
要注意的是，EPOLLONESHOT要求在每次事件处理完之后，由处理线程重新调用epoll_ctl(epollfd, EPOLL_CTL_MOD, fd, &ev)，所以别忘记这个重注册动作。我用这个方案的时候，会在处理完数据、准备重新监听读事件时，顺带把写事件也根据情况一起注册进去，减少不必要的调用次数。
4.3 LT还是ET，生产环境到底怎么选
我的经验是：如果你的业务逻辑不复杂，或者是首次使用epoll，优先LT。LT模式容错率高，数据没读完不会丢，逻辑容易推断。很多高并发框架也是基于LT模式做二次封装的，它对你的要求更低，你不需要担忧漏读问题。
ET模式适合的是那些追求极致性能、并且愿意承担复杂性的人。它的优势在于每次事件上报更精准，不会反复唤醒进程去处理同一个fd上的持续数据。但前提是你的实现必须严格遵循“非阻塞+循环读至EAGAIN”的规则，并且要接受饥饿问题的挑战。如果你没有十足的把握把边界情况处理好，我劝你老老实实用LT。性能差距在绝大多数业务场景里没有想象中那么大，真正的瓶颈往往在业务逻辑和锁竞争上。
4.4 别忽略超时时间和错误处理
epoll_wait的timeout参数很多人直接写-1，永久阻塞。但对某些服务来说，永久阻塞意味着无法周期性执行一些后台任务，比如心跳检查、连接超时管理。如果你需要定期扫一遍所有连接，建议把timeout设为一个较小的值，比如50ms，每次epoll_wait返回后顺带执行定时任务。
另外要处理好EINTR错误。当进程收到信号时，epoll_wait会返回-1且errno为EINTR。如果不处理这个情况，循环会直接退出，服务就挂了。标准的做法是判断errno == EINTR时继续循环。还有一点容易被忽略：epoll_wait返回0并不一定是出错，它表示超时时间到了但没有任何就绪事件，也要正确处理。
5. 性能调优与落地建议
5.1 大循环里的事件处理策略
好的epoll服务，主循环不会太长。epoll_wait拿到一批事件后，推荐的做法是快速将事件分发给工作线程，而不是在主循环里同步处理完整业务。主循环越短，它就越快回到epoll_wait继续等待新的内核事件，整体事件响应的延迟就越低。
我写过一版单线程处理业务的server，压测时发现单连接吞吐还行，但连接数一大，处理某个连接时其他连接全部排队，延迟抖动极其严重。后来改成分发模型：主线程只做accept、读数据、把数据扔进队列；工作线程池负责解包、处理、响应。同样的配置下，P99延迟下降了80%以上。这说明在高并发I/O场景里，epoll只解决了“怎么知道有事件”的问题，而“事件来了怎么高效处理”必须靠线程模型来兜底。
5.2 线程模型怎么搭：单线程还是线程池
这里给几种参考组合。
- 单线程事件循环：适合业务极简、响应极快、没有阻塞调用的场景，比如静态代理、端口转发。优点是代码简单，无锁，但任何一个阻塞操作都会卡死整体。
- 多线程事件循环+全局work队列：多个线程各自跑一个
epoll_wait，但共享同一个任务队列。适合业务有一定的CPU计算，但计算时间可控的场景。注意队列要加锁，存在竞争，但可控。 - 多线程事件循环+每个连接绑定固定线程：用EPOLLONESHOT保证一个fd同一时间只被一个线程处理。适合业务处理时间差异大、需要保证并发安全的场景。这也是多数成熟框架的路线。
不管选哪种，都建议把处理慢业务的部分放在独立线程池里，不要把阻塞操作（数据库查询、外部HTTP请求）直接放在事件回调里。哪怕你的连接数再高、epoll再好，只要某个回调里睡了100ms，整体吞吐直接掉一个量级。
5.3 监控与排查：从/proc到strace
排查epoll相关问题的手段不多，但很管用。一个是看/proc下的fd信息。/proc/<pid>/fd/里能看到进程打开了多少fd，如果数量异常增长，多半是有fd泄漏。配合/proc/<pid>/fdinfo/，可以看到每个fd关联的epoll信息，比如这个fd挂在哪个epoll上、注册了哪些事件标志。
strace -p <pid> -e trace=epoll_wait,epoll_ctl,read,write可以抓包级别的看到系统调用情况。如果发现epoll_wait频繁返回、每次返回的事件很少，说明事件批次太小，可以考虑增加单次返回的事件数组大小，减少系统调用的次数。如果epoll_wait返回后某个fd的read()一直返回大量数据，说明这个连接是热点连接，可能需要加流量限制或切换处理方式。
还有一个隐藏指标：进程CPU是不是大量消耗在系统态。用top看sy占比，如果系统态CPU高，但业务吞吐低，说明很大可能在socket读写和内核数据拷贝上，这时候可以考虑调整socket缓冲区大小，或减少不必要的数据拷贝，比如用sendfile、splice等零拷贝手段。
6. 系列收尾的一点心得
epoll这种从内核层面解决问题的手段，我用了这么多年，最大的感触就是：理解原理不是为了回答面试题，而是为了在线上出问题的时候，你能快速判断问题到底出现在用户态还是内核态，出现在事件机制还是业务处理上。有一次线上连接数暴增，服务CPU飙升，我第一反应是epoll参数没配对，后面用strace一看，epoll_wait返回后处理逻辑里有个热点锁，线程全部卡在抢锁上。这时候再调epoll就完全没意义。
如果你正要开始用epoll，我的建议是先写一个极简的echo服务，反复测试LT和ET模式的差异，再手动制造一个“读一半”的场景，亲眼看看ET模式会漏掉多少数据，这才叫真正入了门。然后再去想怎么平衡事件循环和线程池，怎么改造业务让非阻塞逻辑贯穿到底。等这些都想通了你就会发现，epoll本身不算难，难的是你对你服务的理解——你真正把它用对用好，比熟练背诵一堆API更有价值。
