如果你用 Linux 做过网络编程一定对 epoll 不陌生而只要接触过 epoll就躲不开 LT 与 ET 这两个触发方式。网上讲 LT/ET 的文章不少但大多告诉你是“水平触发”和“边沿触发”就结束了真正能从内核事件递送机制讲到实战代码、能说清为什么有些框架选 LT、有些框架偏 ET 的文章却不多。这篇我想从“一次具体的 epoll 返回事件该怎么处理”讲起把 LTLevel Triggered水平触发与 ETEdge Triggered边沿触发这两个触发方式彻底拆开。无论你是刚入门 Linux 网络编程的开发者还是想优化自己事件循环的老手按这篇文章的思路走一遍后面再遇到 epoll 相关的问题心里都会踏实很多。1. 先把结论摆出来LT 与 ET 到底差在哪1.1 收到“可读”通知之后代码发生了什么先创建一个最简单的场景程序注册了一个 socket fd 的可读事件然后调用 epoll_wait 等待。假设从另一端传来了 300 字节数据内核发现这个 fd 可读于是唤醒事件循环epoll_wait 返回告诉我们“这个 fd 有数据可读”。这里有一个关键点事件循环拿到“可读”通知后我们真的要把所有数据都读完吗如果这次只读了 100 字节缓冲区里还剩 200 字节那下次 epoll_wait 还会不会继续通知我们如果你注册的是 LT内核会持续通知直到我们把缓冲区里的数据全部读干净。如果你注册的是 ET内核只在“缓冲区从不可读变成可读”那一刻通知一次。如果这次没读完剩余数据不会再次触发新事件。这就是两者最核心的差别同一个 fd 处于就绪状态时LT 会反复上报ET 只上报一次状态变化。不少老人用“门铃”和“水位”打比方我用一个更生活化的方式描述——LT 像是小区保安只要你家门口一直堆着快递他每次巡逻都会提醒你“快递还在”ET 像是快递柜的短信只在快递员刚把包裹塞进去那一刻发一次你一直不去取它也不会再发第二条。1.2 水平触发只要条件成立就“一直说”水平触发的英文 Level Triggered 很直观“level”指电平、水平也就是状态本身。只要 fd 的可读状态是“真”只要调用 epoll_wait它就会把该 fd 塞进返回列表里。这个“不断提醒”是有好处的它天然适合不完整的读写逻辑。比如一个 HTTP 请求可能分多个 TCP 包到达你每次只 read 一部分慢慢拼包LT 会一直给你机会继续读直到全部读完。这样代码写起来很简单不用特别在意“这次是不是要把数据取完”。但同时如果业务处理特别慢或者 fd 数量非常庞大LT 会导致同一个 fd 被反复加入就绪队列。极端情况下一个缓冲区总是有数据的慢消费者可能让事件循环每次醒来都处理它影响其他 fd 的响应速度。当然这是有办法缓解的比如处理一次后临时摘除事件后续再重新注册但这又增加了一层复杂度。1.3 边沿触发只在“从无到有”的那一刻通知边沿触发的 Edge Triggered“edge”指的是状态变化的边沿从 0 变 1、从不可读变可读的那个跳变瞬间。只要这个跳变发生过一次内核就通知一次之后不管状态保持多久都不会再次通知。所以用 ET 必须面对一个事实通知是无法“补发”的。如果这次没把数据读完剩余数据在缓冲区里干瞪眼而新的数据又迟迟不来你的程序可能就一直不知道还有数据没读。这也引出了 ET 的铁律收到可读事件后必须循环读取直到 read 返回 EAGAIN。EAGAIN 意味着当前缓冲区已经空了再读也是白读此时才算处理干净。这个铁律在写代码时一定要刻进骨子里。2. 从 epoll_wait 返回事件开始手把手写代码2.1 LT 模式下的事件消费模型先看最常见的 LT 读事件写法#include sys/epoll.h #include unistd.h #include errno.h #include stdio.h #define MAX_EVENTS 64 #define BUF_SIZE 1024 // 假设 epfd 已经通过 epoll_create1 创建好 // 假设 client_fd 已经通过 accept 拿到并且注册了 EPOLLIN static void loop_lt(int epfd) { struct epoll_event events[MAX_EVENTS]; for (;;) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (events[i].events EPOLLIN) { char buf[BUF_SIZE]; // LT 模式下不用 while 循环读一部分也行 // 内核会在下一次 epoll_wait 继续上报剩余数据 ssize_t len read(fd, buf, sizeof(buf)); if (len 0) { // 处理这批数据 handle_data(buf, len); } else if (len 0) { // 对端关闭 close(fd); } else { // 错误处理 perror(read); } } } } }如果你之前没接触过这段代码可能想问为什么 read 只调用一次答案正是 LT 的特性read 只读一部分剩下的数据依然处于“可读”状态epoll_wait 会对它继续上报。代码里无需写 while 循环逻辑清爽很多。不过也有代价。假设每次 epoll_wait 返回 1000 个 fd它们都处于可读状态而你每个 fd 又只读了一小部分那下一次调用 epoll_wait 还会返回这 1000 个 fd重复率很高。所以 LT 模式下如果并发量特别大、每个 fd 的数据又频繁“读不完”事件循环的轮询空转成本就会上升。2.2 ET 模式下的事件消费模型ET 的代码在结构上并不复杂真正的难点是理解“为什么必须这样做”。核心代码如下#include sys/epoll.h #include fcntl.h #include unistd.h #include errno.h // 关键ET 模式下 fd 必须是非阻塞 static void set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); } static void loop_et(int epfd) { struct epoll_event events[MAX_EVENTS]; for (;;) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (events[i].events EPOLLIN) { // ET 铁律必须循环读取直到 EAGAIN while (1) { char buf[BUF_SIZE]; ssize_t len read(fd, buf, sizeof(buf)); if (len 0) { handle_data(buf, len); } else if (len 0) { // 对端关闭 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据全部读完退出循环 break; } else if (errno EINTR) { // 被信号打断继续读 continue; } else { perror(read); close(fd); break; } } } } } } }这段代码里最容易被忽略的是set_nonblocking。为什么 ET 必须配非阻塞 fd因为 ET 要求用到 EAGAIN 来判断“数据读完了”。如果 fd 是阻塞模式read在没有数据可读时会阻塞等在那里而不是返回 EAGAIN于是 while 循环可能永远卡死在最后一次 read 上整个事件循环直接瘫掉。你可以在本地用两个 socketpair 试一下把 fd 设置成阻塞然后只读部分数据很快就能复现“进程卡住不退出”的情况。2.3 写事件比读事件更容易踩坑读事件讲清楚了写事件更值得单独说。很多人学 LT/ET 只盯着读方向一遇到 EPOLLOUT 就懵了。写事件的最初触发条件是socket 的发送缓冲区有可用空间。注意TCP 连接的发送缓冲区通常一开始就有空闲尤其刚 accept 之后可能塞下挺多数据。所以在 LT 模式下如果你注册了 EPOLLOUT且一直不注销内核就会“孜孜不倦”地告诉你“可以写”哪怕你根本没什么数据要发事件循环也会被频繁空转唤醒。这是 LT 写事件最著名的坑。标准做法是平时不在事件里注册 EPOLLOUT等到业务上确实有数据要发送而一次 write 又没写完时才把 EPOLLOUT 加到该 fd 的事件集合里等后续 EPOLLOUT 事件到来持续把剩下的数据写完。当所有数据写完再立刻把 EPOLLOUT 从事件集合里摘掉。这样 EPOLLOUT 只会在“有数据没写完”期间存在不会一直空转。ET 模式下的写事件要省心不少。因为 ET 只在状态跳变时通知只要发送缓冲区始终有余量它并不会反复通知。如果你确实一直有数据要发那么在 fd 刚初始化时注册 EPOLLOUT之后每次 EPOLLOUT 事件到达就发起写操作直到 EAGAIN。如果某个时刻缓冲区已满写返回 EAGAIN那下一次缓冲区重新腾出空间时会再次产生边沿通知程序自然会被唤醒继续写。用 ET 处理写事件我省去了反复 add/mod 的麻烦代码路径更简洁。补充一个常见误区ET 也不是注册一次 EPOLLOUT 就万事大吉。如果业务上有大量数据排队发送缓冲区的腾空是分批进行的ET 事件确实会在每次“从满变成不满”时触发一次。但如果缓冲区一直不满只是暂时写不进去比如对端接收窗口为 0一旦窗口恢复状态变化会产生新事件。所以 ET 的写模型可以简单概括为平时挂上 EPOLLOUT触发时写直到 EAGAIN。2.4 从内核行为看两者的实现差异可能有人会问内核到底是怎么做到“LT 反复通知ET 只通知一次”的我把关键行为描述成大白话版本epoll 内部维护了一个就绪链表。当一个 fd 有事件发生它会进入这个链表当 epoll_wait 完成返回时内核会遍历这个链表把就绪事件拷贝给用户。对于 LT 模式fd 处理完事件后如果没有被真正消费干净比如还有数据可读内核会把它重新放回就绪链表保证下一次 epoll_wait 还能看到它对于 ET 模式内核在返回事件后直接把这个 fd 从就绪链表里移除只有下次 fd 再次发生状态变化比如从不可读变为可读才会再次加入链表。这就解释了为什么 ET 下必须循环读到 EAGAIN如果内核已经告诉你一次“可读”而你没读完它不会再主动提醒你。这其实是一种“内核减少重复通知、把压力转给应用程序”的设计哲学。内核省事了应用就得担起责任自己保证不丢数据。理解了这一点很多框架代码里那些while (read(...) 0)的写法你就不会觉得冗余了。3. 选择恐惧症怎么办LT 和 ET 的适用场景3.1 先说一个普遍的规律我的经验里选择 LT 还是 ET绝大多数时候不是“谁性能更好”而是“谁更符合你的编程模型”。如果你的业务模型是“一次读一点慢慢拼包”LT 几乎无脑合适如果追求高吞吐、希望每个事件通知都能触发一次完整的读写循环ET 的方向更对路。用缓冲区思维来理解LT 是“事件驱动 状态查询”的混合体事件来了以后你还要继续向内核查“还有吗”ET 是真正的事件驱动通知本身就是“状态刚刚变了”的信号你不主动消费状态变化就过去了。所以 ET 更接近硬件中断的模型事件密度更低在高并发场景下系统调用次数会更少但代价是实现复杂必须小心消费完状态否则你等不到第二次通知。3.2 选 LT 的典型场景如果你做的是应用层业务而且请求/响应模式并不极端复杂我建议先用 LT。LT 的节奏非常稳定一条事件处理一次处理不完也没关系。你不需要花大量心思去处理 EAGAIN也不需要为了保证所有数据被读完而设计复杂的缓冲区管理。对大部分 MySQL/Redis 客户端封装、普通的进程通信、单元测试 mock server 来说LT 完全够用而且代码可读性高后续接手的人也容易理解。还有一个更实际的场景如果你的某个 fd 会同时被多个线程或协程消费LT 更安全。因为 LT 会在状态一直存在时不断上报即使某个线程消费了一部分、但没消费干净其他线程在后续 epoll_wait 中依然能看到该 fd。而 ET 由于只通知一次一旦消费不完全其他线程可能会再也拿不到这个 fd 的事件导致数据滞留在内核缓冲区里没人处理。3.3 选 ET 的典型场景当你的服务非常在意高并发、单次事件循环要处理的 fd 数以万计且每个连接的数据基本都是“能读就全部读完”的场景ET 是更好的选择。原因很直接ET 减少了重复通知的次数尤其避免了 LT 在大量活跃 fd 时反复把已就绪但没读完的 fd 重新加入链表的问题。在高并发网关、消息推送服务、代理服务器这类场景里连接数动辄十万级每次 epoll_wait 返回的事件里如果掺杂大量重复 fd会明显增加用户态处理成本。ET 让每个事件最多出现一次事件处理完就消失。网络框架里常见的“读事件 - while 读到 EAGAIN - 处理业务数据 - 尝试写回”这种大循环就是为 ET 量身打造的。具体到业界案例很多人在谈 nginx 与 Redis 的选择nginx 的网络核心模块在 Linux 上大量使用 EPoll 的 ET 模式注意它内部会对不同类型事件做适配因为它的 worker 进程要在一轮事件循环里尽可能快速、批量地处理海量连接Redis 则默认用 LT因为 Redis 更在意单线程模型的简单可靠它的请求协议相对短小LT 的重复通知对总吞吐影响不大反而让代码不容易因为“没读完”而出 bug。这里我不做绝对结论只是想说大流量网络中间件通常愿意承担 ET 的复杂度去换性能业务型服务则倾向于保留 LT 的简单性。3.4 如何一眼确认一个项目用的是 LT 还是 ET看一个开源项目的 event loop 时最直接的方法是搜索EPOLLET关键字。如果项目里对 fd 注册事件时传入了EPOLLET那你还要确认它对每个可读事件是否做了 while 循环读取如果没有传EPOLLET那它本质上就是 LT 驱动即使它的代码里也写了 while 循环也多是为了吞掉大数据量而不是为了满足“必须读干净”的要求。这个判断方式对框架源码阅读很有用。我见过不少人看某个开源项目时看到epoll_wait返回值之后套了一个while(read(...))就断定项目用的是 ET。其实只要事件注册时没带EPOLLET它仍然属于 LT 语义即使写成 while 循环也只是把缓冲区尽可能多读点读不完下次还能继续。区分标准永远在“事件注册时是否传入 EPOLLET”而不是“代码里是否写了循环”。4. 用 strace 实测一次看两种模式的真实行为差异4.1 搭建一个最小可复现环境理论讲再多不如实际跑一遍。我建议你自己动手做这个实验写一个极简的 echo server支持通过参数切换 LT 与 ET 模式然后用一个客户端把数据分多次发送同时用 strace 观察服务端 read 系统调用的次数和 epoll_wait 的返回情况。服务端核心代码大致如下static void add_event(int epfd, int fd, uint32_t events) { struct epoll_event ev; ev.events events; ev.data.fd fd; epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ev); } // mode: 0 LT, 1 ET static void add_conn_event(int epfd, int connfd, int mode) { if (mode 1) { set_nonblocking(connfd); add_event(epfd, connfd, EPOLLIN | EPOLLET); } else { add_event(epfd, connfd, EPOLLIN); } }客户端先发送 100 字节休息 3 秒再发送 100 字节。服务端在 LT 模式下每次只 read 50 字节。你猜会怎样LT 模式下第一次 100 字节到达epoll_wait 返回该 fdread 50 字节后还剩 50 字节。由于内核把 fd 重新加入就绪链表下一次 epoll_wait 立刻又返回同一个 fd继续读 50 字节直到这第一个 100 字节全部消费完第二次 100 字节到达后同理。这样我们对“第一批 100 字节”至少要经历两次 epoll_wait 返回。ET 模式下由于代码里是 while 循环读取read 50 字节之后不会退出循环而是继续 read。第一次 100 字节到达后循环会在第二次 read 时把剩余 50 字节读完第三次 read 返回 EAGAIN 退出循环。第二次 100 字节到达后因为 fd 从不可读变为可读又一次产生边沿通知再走一轮 while 循环。4.2 strace 输出的观察重点用 strace 观察服务端进程的系统调用strace -p server_pid -e traceepoll_wait,read -ttLT 模式下你会看到很明显的现象epoll_wait连续多次返回同一个 fd每次后面都跟着一次read(5, ..., 50)由于没有额外数据到来epoll_wait 在短暂返回后又会立刻再次返回。这批事件看起来非常“密集”。ET 模式下则清晰很多epoll_wait返回一次 fd紧跟着 3 到 4 次 read 调用最后一次拿到 EAGAIN然后 epoll_wait 进入正常阻塞直到下一次数据到达才重新返回。把两份 strace 日志并排看会有一种“LT 在抢跑ET 在踩着心跳走”的感觉。这也解释了为什么高并发服务青睐 ET它的 epoll_wait 不会在同一时期内反复被同一个空闲 fd 唤醒系统调用次数明显更少。4.3 一个重要的对照实验LT 下读干净会怎样你还可以把 LT 模式的代码改成 while 循环把缓冲区一次性读净。此时 LT 模式的行为会和 ET 很接近epoll_wait 返回一次后read 连续读取直到 EAGAIN后续就不再有重复通知。因为 fd 的状态已经被消费干净内核没有再把它放回就绪链表的理由。这也说明了一个容易误导新手的事实从应用层观察LT 循环读取 和 ET 循环读取 的结果非常相似。真正的差异体现在“只读部分数据”时LT 会补通知ET 不会。因此在实际生产代码里LT 模式下你到底要不要写 while 循环取决于你是否希望一次事件把数据尽量读净而不是由内核强制。ET 则是内核强制你必须读净。5. 生产环境里的四个大坑与排查手法5.1 坑一ET 模式忘了设置非阻塞事件循环卡死这是新手最容易踩的雷。代码里明明写了EPOLLET也写了 while 循环但运行一段时间后整个服务就像“卡住”了一样CPU 占用也不高日志也不再滚动。用 gdb 附加到进程backtrace 看到线程卡在read上而且 fd 是阻塞模式。原因前面讲过了ET 要求循环读到 EAGAIN 才能结束但阻塞 fd 在数据读完时不会返回 EAGAIN而是阻塞等待。排查方法很直接看代码里是否对 accept 出来的 socket 调用了fcntl(fd, F_SETFL, flags | O_NONBLOCK)。如果没设置赶紧补上。这类问题在本地不一定频繁出现因为本地数据量少、缓冲区一下子读干净了循环直接就退出往往到线上流量大了才暴露危害非常大。5.2 坑二LT 下 EPOLLOUT 长期挂在事件集合里CPU 飙升描述一下现象服务运行后 CPU 占用率很高但业务 QPS 并不高。用 strace 一看epoll_wait 几乎不阻塞每次都立即返回大量返回事件都是 EPOLLOUT而这些事件又触发不了真正有意义的数据发送。这就是 LT 模式一直注册 EPOLLOUT 的典型问题。因为 TCP 发送缓冲区经常处于“有空间”状态LT 会不厌其烦地通知你。解决办法是动态管理 EPOLLOUT有数据没写完时才注册写完立刻移除。如果你使用 epoll_ctl 的 MOD 操作每次改完事件后还有一个隐蔽问题频繁 MOD 会抢占 epoll 内部的锁在高并发下反而成为瓶颈。所以最理想的是业务层先做写缓冲队列管理尽量合并写事件而不是每个字节都去注册/注销 EPOLLOUT。5.3 坑三ET 下只读了一部分数据就开始等出现应用层“假死”另一个高频问题ET 事件到达代码只 read 了一次拿到的数据不足以凑齐一个完整的应用层请求于是进入等待状态结果再也没有新事件到来。客户端那边等不到响应服务端这边也没有报错连接像死了一样。这个问题的根源就是“没有在事件回调里把内核缓冲区的数据读干净”。数据确实还在内核缓冲区里但没有新数据进来就不会产生新的边沿通知EPOLL 自然不会再告诉你。修复方法就是补上while (read(...) ! -1 || errno ! EAGAIN)循环把剩余数据全部读出来。这里我建议你还要小心一种边界如果数据刚好在下次 read 时已经处理完但内核又积压了新的数据循环会因为读到新数据而继续处理也完全符合逻辑。ET 的核心思想就是“一次事件处理到当前能处理的所有数据”不要留尾巴。5.4 坑四多线程消费同一 fd 的 ET 事件丢失还有一个偏进阶的坑出在“多个线程/协程同时消费一个 fd 的可读事件”时。LT 下即使一个线程没读完内核还会再次广播其他线程也有机会捡到事件ET 下事件只通知一次A 线程拿走了事件但只读了一部分B 线程就算也在等事件也不会再收到这个 fd 的通知。最后 A 线程读的不完整B 线程拿不到数据连接就卡住。这种场景下要么把 fd 改成 LT要么确保同一个 fd 的事件只交给一个线程消费并且在消费流程里严格读取到 EAGAIN。现实中还有很多人用 EPOLLONESHOT mutex 来避免多线程同时处理一个 fdET 和 EPOLLONESHOT 结合时尤其要注意读完 EAGAIN 后要重新 arming 事件否则这条连接在后续事件里永远不可见。5.5 一个实用小工具epoll 事件分发小技巧调试这类问题我经常用一个小技巧在事件处理的循环里打印fd、revents以及本次 read 返回的字节数。不要只把一个 fd 的输出连续打印你会看不清要带上时间戳比如printf(%ld.%06ld fd%d revents0x%x len%zd errno%d\n, tv_sec, tv_usec, fd, events[i].events, len, errno)。这样你就能看到 LT 下同一个 fd 被唤醒的节奏也能看到 ET 下 read 什么时候返回 EAGAIN。如果项目对性能要求高不方便加打印那我给你另一个思路在事件回调里用计数器统计“每次 epoll_wait 返回的事件数与去重后的 fd 数”如果去重后的数量远小于返回事件数大概率是 LT 在反复上报同一批 fd如果事件数和 fd 数很接近且每次读事件都能读到 EAGAIN说明基本是 ET 语义。这个统计指标对判断当前事件模型是否合理很有参考价值。6. 我再补充几个很多人容易搞混的细节6.1 EPOLLONESHOT 与 LT/ET 的关系EPOLLONESHOT 的意思是事件通知一次后自动从 epoll 集合中摘除直到你手动重新 MOD 加入。它和 LT/ET 是两个不同维度EPOLLONESHOT 控制的是“通知后是否继续注册”LT/ET 控制的是“通知的重复性”。用 EPOLLONESHOT 时即使你是 LT事件消费完后也会停止通知必须重新 arming用 ET EPOLLONESHOT 时更要注意重新 arming 的时机通常应该在读操作触发 EAGAIN 之后再 MOD否则可能丢事件。6.2 数据到达与 EAGAIN 的边界ET 模式下一个 fd 可读事件发生后如果你在读循环里处理业务逻辑花费了很长时间这段时间内又来了新数据只要内核事件循环还没从 fd 上把事件移除新数据会继续触发又一次回调。这里不必过度担心“新数据被吞掉”内核的等待队列回调机制会处理。真正要担心的是你读到 EAGAIN 后还有数据被延迟到达那就是下一次边沿通知的事与新事件注册与否无关。6.3 为什么我推荐新手先学 LT如果你的目标是快速上手高并发服务我仍然建议刚开始写的时候先用 LT 把事件循环跑通。原因很简单LT 给了你反复试错的机会。你读了一部分数据代码有 bug、业务没处理好至少 epoll 还会继续通知不至于让连接彻底卡死。等你对 read/write 的时序、缓冲区、EAGAIN 的行为都形成了肌肉记忆再切 ET你会发现一切顺理成章。不要一上来就追求“高性能”LT/ET 的差距更多体现在量级和复杂度上而不是“谁更高端”。6.4 云端容器环境下的一个小提醒如果你在容器或者云主机上调试偶尔会遇到 strace 附加进程时权限受限的问题。这种情况下可以直接改用strace -p配合容器内权限配置或者退而求其次用perf trace观察再或者干脆在代码里打日志统计系统调用次数。总之观察 epoll_wait 是否反复唤醒的手段很多别因为工具受限就放弃实证。7. 我个人的一点实践体会从我维护过的一些服务看真正把 LT/ET 用出差距的往往不是那个“选型动作”而是后续事件处理代码的严谨程度。ET 迫使你把每次事件处理都写成“彻底消费干净”的模式代码在一开始就避免了“等待下一次通知”的惰性而 LT 则更容易让人偷懒读一部分就走留下缓冲区数据日积月累在极端流量下产生重复通知风暴。如果非要给一个建议我会说中小型项目、团队经验一般优先 LT大型网关类项目、团队对异步处理模型很有把握优先 ET。自己写框架练手的话两种模式都实现一遍用 strace 观察行为差异远比听别人讲几十遍理论更有用。最后分享一个小技巧当你排查线上 epoll 相关卡顿问题时不要只盯 epoll_wait 返回值最好把 accept、read、write、epoll_ctl 的调用都带到日志里尤其记录 epoll_ctl MOD 的次数。很多时候问题不在 LT/ET 本身而是事件注册和注销过于频繁导致锁竞争或者事件处理中和业务线程互相等待形成死锁。把这几个维度的数据都看一遍你会更快找到根因。
e poll LT与ET触发深度解析：原理、代码与生产实践
如果你用 Linux 做过网络编程一定对 epoll 不陌生而只要接触过 epoll就躲不开 LT 与 ET 这两个触发方式。网上讲 LT/ET 的文章不少但大多告诉你是“水平触发”和“边沿触发”就结束了真正能从内核事件递送机制讲到实战代码、能说清为什么有些框架选 LT、有些框架偏 ET 的文章却不多。这篇我想从“一次具体的 epoll 返回事件该怎么处理”讲起把 LTLevel Triggered水平触发与 ETEdge Triggered边沿触发这两个触发方式彻底拆开。无论你是刚入门 Linux 网络编程的开发者还是想优化自己事件循环的老手按这篇文章的思路走一遍后面再遇到 epoll 相关的问题心里都会踏实很多。1. 先把结论摆出来LT 与 ET 到底差在哪1.1 收到“可读”通知之后代码发生了什么先创建一个最简单的场景程序注册了一个 socket fd 的可读事件然后调用 epoll_wait 等待。假设从另一端传来了 300 字节数据内核发现这个 fd 可读于是唤醒事件循环epoll_wait 返回告诉我们“这个 fd 有数据可读”。这里有一个关键点事件循环拿到“可读”通知后我们真的要把所有数据都读完吗如果这次只读了 100 字节缓冲区里还剩 200 字节那下次 epoll_wait 还会不会继续通知我们如果你注册的是 LT内核会持续通知直到我们把缓冲区里的数据全部读干净。如果你注册的是 ET内核只在“缓冲区从不可读变成可读”那一刻通知一次。如果这次没读完剩余数据不会再次触发新事件。这就是两者最核心的差别同一个 fd 处于就绪状态时LT 会反复上报ET 只上报一次状态变化。不少老人用“门铃”和“水位”打比方我用一个更生活化的方式描述——LT 像是小区保安只要你家门口一直堆着快递他每次巡逻都会提醒你“快递还在”ET 像是快递柜的短信只在快递员刚把包裹塞进去那一刻发一次你一直不去取它也不会再发第二条。1.2 水平触发只要条件成立就“一直说”水平触发的英文 Level Triggered 很直观“level”指电平、水平也就是状态本身。只要 fd 的可读状态是“真”只要调用 epoll_wait它就会把该 fd 塞进返回列表里。这个“不断提醒”是有好处的它天然适合不完整的读写逻辑。比如一个 HTTP 请求可能分多个 TCP 包到达你每次只 read 一部分慢慢拼包LT 会一直给你机会继续读直到全部读完。这样代码写起来很简单不用特别在意“这次是不是要把数据取完”。但同时如果业务处理特别慢或者 fd 数量非常庞大LT 会导致同一个 fd 被反复加入就绪队列。极端情况下一个缓冲区总是有数据的慢消费者可能让事件循环每次醒来都处理它影响其他 fd 的响应速度。当然这是有办法缓解的比如处理一次后临时摘除事件后续再重新注册但这又增加了一层复杂度。1.3 边沿触发只在“从无到有”的那一刻通知边沿触发的 Edge Triggered“edge”指的是状态变化的边沿从 0 变 1、从不可读变可读的那个跳变瞬间。只要这个跳变发生过一次内核就通知一次之后不管状态保持多久都不会再次通知。所以用 ET 必须面对一个事实通知是无法“补发”的。如果这次没把数据读完剩余数据在缓冲区里干瞪眼而新的数据又迟迟不来你的程序可能就一直不知道还有数据没读。这也引出了 ET 的铁律收到可读事件后必须循环读取直到 read 返回 EAGAIN。EAGAIN 意味着当前缓冲区已经空了再读也是白读此时才算处理干净。这个铁律在写代码时一定要刻进骨子里。2. 从 epoll_wait 返回事件开始手把手写代码2.1 LT 模式下的事件消费模型先看最常见的 LT 读事件写法#include sys/epoll.h #include unistd.h #include errno.h #include stdio.h #define MAX_EVENTS 64 #define BUF_SIZE 1024 // 假设 epfd 已经通过 epoll_create1 创建好 // 假设 client_fd 已经通过 accept 拿到并且注册了 EPOLLIN static void loop_lt(int epfd) { struct epoll_event events[MAX_EVENTS]; for (;;) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (events[i].events EPOLLIN) { char buf[BUF_SIZE]; // LT 模式下不用 while 循环读一部分也行 // 内核会在下一次 epoll_wait 继续上报剩余数据 ssize_t len read(fd, buf, sizeof(buf)); if (len 0) { // 处理这批数据 handle_data(buf, len); } else if (len 0) { // 对端关闭 close(fd); } else { // 错误处理 perror(read); } } } } }如果你之前没接触过这段代码可能想问为什么 read 只调用一次答案正是 LT 的特性read 只读一部分剩下的数据依然处于“可读”状态epoll_wait 会对它继续上报。代码里无需写 while 循环逻辑清爽很多。不过也有代价。假设每次 epoll_wait 返回 1000 个 fd它们都处于可读状态而你每个 fd 又只读了一小部分那下一次调用 epoll_wait 还会返回这 1000 个 fd重复率很高。所以 LT 模式下如果并发量特别大、每个 fd 的数据又频繁“读不完”事件循环的轮询空转成本就会上升。2.2 ET 模式下的事件消费模型ET 的代码在结构上并不复杂真正的难点是理解“为什么必须这样做”。核心代码如下#include sys/epoll.h #include fcntl.h #include unistd.h #include errno.h // 关键ET 模式下 fd 必须是非阻塞 static void set_nonblocking(int fd) { int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK); } static void loop_et(int epfd) { struct epoll_event events[MAX_EVENTS]; for (;;) { int n epoll_wait(epfd, events, MAX_EVENTS, -1); for (int i 0; i n; i) { int fd events[i].data.fd; if (events[i].events EPOLLIN) { // ET 铁律必须循环读取直到 EAGAIN while (1) { char buf[BUF_SIZE]; ssize_t len read(fd, buf, sizeof(buf)); if (len 0) { handle_data(buf, len); } else if (len 0) { // 对端关闭 close(fd); break; } else { if (errno EAGAIN || errno EWOULDBLOCK) { // 数据全部读完退出循环 break; } else if (errno EINTR) { // 被信号打断继续读 continue; } else { perror(read); close(fd); break; } } } } } } }这段代码里最容易被忽略的是set_nonblocking。为什么 ET 必须配非阻塞 fd因为 ET 要求用到 EAGAIN 来判断“数据读完了”。如果 fd 是阻塞模式read在没有数据可读时会阻塞等在那里而不是返回 EAGAIN于是 while 循环可能永远卡死在最后一次 read 上整个事件循环直接瘫掉。你可以在本地用两个 socketpair 试一下把 fd 设置成阻塞然后只读部分数据很快就能复现“进程卡住不退出”的情况。2.3 写事件比读事件更容易踩坑读事件讲清楚了写事件更值得单独说。很多人学 LT/ET 只盯着读方向一遇到 EPOLLOUT 就懵了。写事件的最初触发条件是socket 的发送缓冲区有可用空间。注意TCP 连接的发送缓冲区通常一开始就有空闲尤其刚 accept 之后可能塞下挺多数据。所以在 LT 模式下如果你注册了 EPOLLOUT且一直不注销内核就会“孜孜不倦”地告诉你“可以写”哪怕你根本没什么数据要发事件循环也会被频繁空转唤醒。这是 LT 写事件最著名的坑。标准做法是平时不在事件里注册 EPOLLOUT等到业务上确实有数据要发送而一次 write 又没写完时才把 EPOLLOUT 加到该 fd 的事件集合里等后续 EPOLLOUT 事件到来持续把剩下的数据写完。当所有数据写完再立刻把 EPOLLOUT 从事件集合里摘掉。这样 EPOLLOUT 只会在“有数据没写完”期间存在不会一直空转。ET 模式下的写事件要省心不少。因为 ET 只在状态跳变时通知只要发送缓冲区始终有余量它并不会反复通知。如果你确实一直有数据要发那么在 fd 刚初始化时注册 EPOLLOUT之后每次 EPOLLOUT 事件到达就发起写操作直到 EAGAIN。如果某个时刻缓冲区已满写返回 EAGAIN那下一次缓冲区重新腾出空间时会再次产生边沿通知程序自然会被唤醒继续写。用 ET 处理写事件我省去了反复 add/mod 的麻烦代码路径更简洁。补充一个常见误区ET 也不是注册一次 EPOLLOUT 就万事大吉。如果业务上有大量数据排队发送缓冲区的腾空是分批进行的ET 事件确实会在每次“从满变成不满”时触发一次。但如果缓冲区一直不满只是暂时写不进去比如对端接收窗口为 0一旦窗口恢复状态变化会产生新事件。所以 ET 的写模型可以简单概括为平时挂上 EPOLLOUT触发时写直到 EAGAIN。2.4 从内核行为看两者的实现差异可能有人会问内核到底是怎么做到“LT 反复通知ET 只通知一次”的我把关键行为描述成大白话版本epoll 内部维护了一个就绪链表。当一个 fd 有事件发生它会进入这个链表当 epoll_wait 完成返回时内核会遍历这个链表把就绪事件拷贝给用户。对于 LT 模式fd 处理完事件后如果没有被真正消费干净比如还有数据可读内核会把它重新放回就绪链表保证下一次 epoll_wait 还能看到它对于 ET 模式内核在返回事件后直接把这个 fd 从就绪链表里移除只有下次 fd 再次发生状态变化比如从不可读变为可读才会再次加入链表。这就解释了为什么 ET 下必须循环读到 EAGAIN如果内核已经告诉你一次“可读”而你没读完它不会再主动提醒你。这其实是一种“内核减少重复通知、把压力转给应用程序”的设计哲学。内核省事了应用就得担起责任自己保证不丢数据。理解了这一点很多框架代码里那些while (read(...) 0)的写法你就不会觉得冗余了。3. 选择恐惧症怎么办LT 和 ET 的适用场景3.1 先说一个普遍的规律我的经验里选择 LT 还是 ET绝大多数时候不是“谁性能更好”而是“谁更符合你的编程模型”。如果你的业务模型是“一次读一点慢慢拼包”LT 几乎无脑合适如果追求高吞吐、希望每个事件通知都能触发一次完整的读写循环ET 的方向更对路。用缓冲区思维来理解LT 是“事件驱动 状态查询”的混合体事件来了以后你还要继续向内核查“还有吗”ET 是真正的事件驱动通知本身就是“状态刚刚变了”的信号你不主动消费状态变化就过去了。所以 ET 更接近硬件中断的模型事件密度更低在高并发场景下系统调用次数会更少但代价是实现复杂必须小心消费完状态否则你等不到第二次通知。3.2 选 LT 的典型场景如果你做的是应用层业务而且请求/响应模式并不极端复杂我建议先用 LT。LT 的节奏非常稳定一条事件处理一次处理不完也没关系。你不需要花大量心思去处理 EAGAIN也不需要为了保证所有数据被读完而设计复杂的缓冲区管理。对大部分 MySQL/Redis 客户端封装、普通的进程通信、单元测试 mock server 来说LT 完全够用而且代码可读性高后续接手的人也容易理解。还有一个更实际的场景如果你的某个 fd 会同时被多个线程或协程消费LT 更安全。因为 LT 会在状态一直存在时不断上报即使某个线程消费了一部分、但没消费干净其他线程在后续 epoll_wait 中依然能看到该 fd。而 ET 由于只通知一次一旦消费不完全其他线程可能会再也拿不到这个 fd 的事件导致数据滞留在内核缓冲区里没人处理。3.3 选 ET 的典型场景当你的服务非常在意高并发、单次事件循环要处理的 fd 数以万计且每个连接的数据基本都是“能读就全部读完”的场景ET 是更好的选择。原因很直接ET 减少了重复通知的次数尤其避免了 LT 在大量活跃 fd 时反复把已就绪但没读完的 fd 重新加入链表的问题。在高并发网关、消息推送服务、代理服务器这类场景里连接数动辄十万级每次 epoll_wait 返回的事件里如果掺杂大量重复 fd会明显增加用户态处理成本。ET 让每个事件最多出现一次事件处理完就消失。网络框架里常见的“读事件 - while 读到 EAGAIN - 处理业务数据 - 尝试写回”这种大循环就是为 ET 量身打造的。具体到业界案例很多人在谈 nginx 与 Redis 的选择nginx 的网络核心模块在 Linux 上大量使用 EPoll 的 ET 模式注意它内部会对不同类型事件做适配因为它的 worker 进程要在一轮事件循环里尽可能快速、批量地处理海量连接Redis 则默认用 LT因为 Redis 更在意单线程模型的简单可靠它的请求协议相对短小LT 的重复通知对总吞吐影响不大反而让代码不容易因为“没读完”而出 bug。这里我不做绝对结论只是想说大流量网络中间件通常愿意承担 ET 的复杂度去换性能业务型服务则倾向于保留 LT 的简单性。3.4 如何一眼确认一个项目用的是 LT 还是 ET看一个开源项目的 event loop 时最直接的方法是搜索EPOLLET关键字。如果项目里对 fd 注册事件时传入了EPOLLET那你还要确认它对每个可读事件是否做了 while 循环读取如果没有传EPOLLET那它本质上就是 LT 驱动即使它的代码里也写了 while 循环也多是为了吞掉大数据量而不是为了满足“必须读干净”的要求。这个判断方式对框架源码阅读很有用。我见过不少人看某个开源项目时看到epoll_wait返回值之后套了一个while(read(...))就断定项目用的是 ET。其实只要事件注册时没带EPOLLET它仍然属于 LT 语义即使写成 while 循环也只是把缓冲区尽可能多读点读不完下次还能继续。区分标准永远在“事件注册时是否传入 EPOLLET”而不是“代码里是否写了循环”。4. 用 strace 实测一次看两种模式的真实行为差异4.1 搭建一个最小可复现环境理论讲再多不如实际跑一遍。我建议你自己动手做这个实验写一个极简的 echo server支持通过参数切换 LT 与 ET 模式然后用一个客户端把数据分多次发送同时用 strace 观察服务端 read 系统调用的次数和 epoll_wait 的返回情况。服务端核心代码大致如下static void add_event(int epfd, int fd, uint32_t events) { struct epoll_event ev; ev.events events; ev.data.fd fd; epoll_ctl(epfd, EPOLL_CTL_ADD, fd, ev); } // mode: 0 LT, 1 ET static void add_conn_event(int epfd, int connfd, int mode) { if (mode 1) { set_nonblocking(connfd); add_event(epfd, connfd, EPOLLIN | EPOLLET); } else { add_event(epfd, connfd, EPOLLIN); } }客户端先发送 100 字节休息 3 秒再发送 100 字节。服务端在 LT 模式下每次只 read 50 字节。你猜会怎样LT 模式下第一次 100 字节到达epoll_wait 返回该 fdread 50 字节后还剩 50 字节。由于内核把 fd 重新加入就绪链表下一次 epoll_wait 立刻又返回同一个 fd继续读 50 字节直到这第一个 100 字节全部消费完第二次 100 字节到达后同理。这样我们对“第一批 100 字节”至少要经历两次 epoll_wait 返回。ET 模式下由于代码里是 while 循环读取read 50 字节之后不会退出循环而是继续 read。第一次 100 字节到达后循环会在第二次 read 时把剩余 50 字节读完第三次 read 返回 EAGAIN 退出循环。第二次 100 字节到达后因为 fd 从不可读变为可读又一次产生边沿通知再走一轮 while 循环。4.2 strace 输出的观察重点用 strace 观察服务端进程的系统调用strace -p server_pid -e traceepoll_wait,read -ttLT 模式下你会看到很明显的现象epoll_wait连续多次返回同一个 fd每次后面都跟着一次read(5, ..., 50)由于没有额外数据到来epoll_wait 在短暂返回后又会立刻再次返回。这批事件看起来非常“密集”。ET 模式下则清晰很多epoll_wait返回一次 fd紧跟着 3 到 4 次 read 调用最后一次拿到 EAGAIN然后 epoll_wait 进入正常阻塞直到下一次数据到达才重新返回。把两份 strace 日志并排看会有一种“LT 在抢跑ET 在踩着心跳走”的感觉。这也解释了为什么高并发服务青睐 ET它的 epoll_wait 不会在同一时期内反复被同一个空闲 fd 唤醒系统调用次数明显更少。4.3 一个重要的对照实验LT 下读干净会怎样你还可以把 LT 模式的代码改成 while 循环把缓冲区一次性读净。此时 LT 模式的行为会和 ET 很接近epoll_wait 返回一次后read 连续读取直到 EAGAIN后续就不再有重复通知。因为 fd 的状态已经被消费干净内核没有再把它放回就绪链表的理由。这也说明了一个容易误导新手的事实从应用层观察LT 循环读取 和 ET 循环读取 的结果非常相似。真正的差异体现在“只读部分数据”时LT 会补通知ET 不会。因此在实际生产代码里LT 模式下你到底要不要写 while 循环取决于你是否希望一次事件把数据尽量读净而不是由内核强制。ET 则是内核强制你必须读净。5. 生产环境里的四个大坑与排查手法5.1 坑一ET 模式忘了设置非阻塞事件循环卡死这是新手最容易踩的雷。代码里明明写了EPOLLET也写了 while 循环但运行一段时间后整个服务就像“卡住”了一样CPU 占用也不高日志也不再滚动。用 gdb 附加到进程backtrace 看到线程卡在read上而且 fd 是阻塞模式。原因前面讲过了ET 要求循环读到 EAGAIN 才能结束但阻塞 fd 在数据读完时不会返回 EAGAIN而是阻塞等待。排查方法很直接看代码里是否对 accept 出来的 socket 调用了fcntl(fd, F_SETFL, flags | O_NONBLOCK)。如果没设置赶紧补上。这类问题在本地不一定频繁出现因为本地数据量少、缓冲区一下子读干净了循环直接就退出往往到线上流量大了才暴露危害非常大。5.2 坑二LT 下 EPOLLOUT 长期挂在事件集合里CPU 飙升描述一下现象服务运行后 CPU 占用率很高但业务 QPS 并不高。用 strace 一看epoll_wait 几乎不阻塞每次都立即返回大量返回事件都是 EPOLLOUT而这些事件又触发不了真正有意义的数据发送。这就是 LT 模式一直注册 EPOLLOUT 的典型问题。因为 TCP 发送缓冲区经常处于“有空间”状态LT 会不厌其烦地通知你。解决办法是动态管理 EPOLLOUT有数据没写完时才注册写完立刻移除。如果你使用 epoll_ctl 的 MOD 操作每次改完事件后还有一个隐蔽问题频繁 MOD 会抢占 epoll 内部的锁在高并发下反而成为瓶颈。所以最理想的是业务层先做写缓冲队列管理尽量合并写事件而不是每个字节都去注册/注销 EPOLLOUT。5.3 坑三ET 下只读了一部分数据就开始等出现应用层“假死”另一个高频问题ET 事件到达代码只 read 了一次拿到的数据不足以凑齐一个完整的应用层请求于是进入等待状态结果再也没有新事件到来。客户端那边等不到响应服务端这边也没有报错连接像死了一样。这个问题的根源就是“没有在事件回调里把内核缓冲区的数据读干净”。数据确实还在内核缓冲区里但没有新数据进来就不会产生新的边沿通知EPOLL 自然不会再告诉你。修复方法就是补上while (read(...) ! -1 || errno ! EAGAIN)循环把剩余数据全部读出来。这里我建议你还要小心一种边界如果数据刚好在下次 read 时已经处理完但内核又积压了新的数据循环会因为读到新数据而继续处理也完全符合逻辑。ET 的核心思想就是“一次事件处理到当前能处理的所有数据”不要留尾巴。5.4 坑四多线程消费同一 fd 的 ET 事件丢失还有一个偏进阶的坑出在“多个线程/协程同时消费一个 fd 的可读事件”时。LT 下即使一个线程没读完内核还会再次广播其他线程也有机会捡到事件ET 下事件只通知一次A 线程拿走了事件但只读了一部分B 线程就算也在等事件也不会再收到这个 fd 的通知。最后 A 线程读的不完整B 线程拿不到数据连接就卡住。这种场景下要么把 fd 改成 LT要么确保同一个 fd 的事件只交给一个线程消费并且在消费流程里严格读取到 EAGAIN。现实中还有很多人用 EPOLLONESHOT mutex 来避免多线程同时处理一个 fdET 和 EPOLLONESHOT 结合时尤其要注意读完 EAGAIN 后要重新 arming 事件否则这条连接在后续事件里永远不可见。5.5 一个实用小工具epoll 事件分发小技巧调试这类问题我经常用一个小技巧在事件处理的循环里打印fd、revents以及本次 read 返回的字节数。不要只把一个 fd 的输出连续打印你会看不清要带上时间戳比如printf(%ld.%06ld fd%d revents0x%x len%zd errno%d\n, tv_sec, tv_usec, fd, events[i].events, len, errno)。这样你就能看到 LT 下同一个 fd 被唤醒的节奏也能看到 ET 下 read 什么时候返回 EAGAIN。如果项目对性能要求高不方便加打印那我给你另一个思路在事件回调里用计数器统计“每次 epoll_wait 返回的事件数与去重后的 fd 数”如果去重后的数量远小于返回事件数大概率是 LT 在反复上报同一批 fd如果事件数和 fd 数很接近且每次读事件都能读到 EAGAIN说明基本是 ET 语义。这个统计指标对判断当前事件模型是否合理很有参考价值。6. 我再补充几个很多人容易搞混的细节6.1 EPOLLONESHOT 与 LT/ET 的关系EPOLLONESHOT 的意思是事件通知一次后自动从 epoll 集合中摘除直到你手动重新 MOD 加入。它和 LT/ET 是两个不同维度EPOLLONESHOT 控制的是“通知后是否继续注册”LT/ET 控制的是“通知的重复性”。用 EPOLLONESHOT 时即使你是 LT事件消费完后也会停止通知必须重新 arming用 ET EPOLLONESHOT 时更要注意重新 arming 的时机通常应该在读操作触发 EAGAIN 之后再 MOD否则可能丢事件。6.2 数据到达与 EAGAIN 的边界ET 模式下一个 fd 可读事件发生后如果你在读循环里处理业务逻辑花费了很长时间这段时间内又来了新数据只要内核事件循环还没从 fd 上把事件移除新数据会继续触发又一次回调。这里不必过度担心“新数据被吞掉”内核的等待队列回调机制会处理。真正要担心的是你读到 EAGAIN 后还有数据被延迟到达那就是下一次边沿通知的事与新事件注册与否无关。6.3 为什么我推荐新手先学 LT如果你的目标是快速上手高并发服务我仍然建议刚开始写的时候先用 LT 把事件循环跑通。原因很简单LT 给了你反复试错的机会。你读了一部分数据代码有 bug、业务没处理好至少 epoll 还会继续通知不至于让连接彻底卡死。等你对 read/write 的时序、缓冲区、EAGAIN 的行为都形成了肌肉记忆再切 ET你会发现一切顺理成章。不要一上来就追求“高性能”LT/ET 的差距更多体现在量级和复杂度上而不是“谁更高端”。6.4 云端容器环境下的一个小提醒如果你在容器或者云主机上调试偶尔会遇到 strace 附加进程时权限受限的问题。这种情况下可以直接改用strace -p配合容器内权限配置或者退而求其次用perf trace观察再或者干脆在代码里打日志统计系统调用次数。总之观察 epoll_wait 是否反复唤醒的手段很多别因为工具受限就放弃实证。7. 我个人的一点实践体会从我维护过的一些服务看真正把 LT/ET 用出差距的往往不是那个“选型动作”而是后续事件处理代码的严谨程度。ET 迫使你把每次事件处理都写成“彻底消费干净”的模式代码在一开始就避免了“等待下一次通知”的惰性而 LT 则更容易让人偷懒读一部分就走留下缓冲区数据日积月累在极端流量下产生重复通知风暴。如果非要给一个建议我会说中小型项目、团队经验一般优先 LT大型网关类项目、团队对异步处理模型很有把握优先 ET。自己写框架练手的话两种模式都实现一遍用 strace 观察行为差异远比听别人讲几十遍理论更有用。最后分享一个小技巧当你排查线上 epoll 相关卡顿问题时不要只盯 epoll_wait 返回值最好把 accept、read、write、epoll_ctl 的调用都带到日志里尤其记录 epoll_ctl MOD 的次数。很多时候问题不在 LT/ET 本身而是事件注册和注销过于频繁导致锁竞争或者事件处理中和业务线程互相等待形成死锁。把这几个维度的数据都看一遍你会更快找到根因。
