epoll边沿触发与水平触发区别详解

本文深入剖析了epoll中水平触发（LT）与边缘触发（ET）两种工作模式的本质区别：LT作为默认模式，持续通知未处理完的就绪事件，对新手友好却易掩盖设计缺陷、引发性能损耗；而ET仅在状态变化时通知一次，要求应用必须用非阻塞IO循环读/写至EAGAIN，虽显著减少系统调用、提升高并发场景吞吐（如nginx所采用），但容错性极低、调试复杂，稍有疏忽就会导致数据滞留或事件丢失——尤其强调listenfd务必使用LT以防连接被静默丢弃，真正考验工程能力的，是在各种网络边界条件下确保ET逻辑万无一失。

LT模式下epoll_wait会反复通知未处理完的就绪事件

水平触发（LT）是epoll的默认行为，只要文件描述符处于就绪状态，epoll_wait就会持续返回该事件。比如socket接收缓冲区里还有100字节没读完，下次调用epoll_wait仍会报告EPOLLIN，直到缓冲区真正为空。

这种行为对初学者友好，但容易掩盖逻辑缺陷：

• 误以为一次recv就能收完所有数据，实际只读了部分，后续靠LT“兜底”继续触发
• 在高并发场景下，同一fd频繁出现在events数组中，增加无谓遍历开销
• 若程序在处理事件时阻塞或耗时过长，LT会不断堆积重复通知，放大延迟感知

典型写法：event.events = EPOLLIN（不显式加EPOLLLT，因为默认就是LT）

ET模式必须一次性处理完缓冲区全部数据

边缘触发（ET）只在文件描述符状态变化时通知一次——例如从“不可读”变为“可读”，或发送缓冲区从满变为不满。之后即使接收缓冲区仍有数据，epoll_wait也不会再提醒你。

这意味着你必须在收到EPOLLIN后，用循环+非阻塞IO把数据全读光：

• socket必须设为非阻塞（fcntl(fd, F_SETFL, O_NONBLOCK)），否则recv可能卡住
• 每次recv返回-1且errno == EAGAIN或EWOULDBLOCK，才表示本次读取完毕
• 漏掉这个判断，剩余数据就永远滞留在内核缓冲区，应用再也收不到通知

启用ET只需在事件标志中加EPOLLET：event.events = EPOLLIN | EPOLLET

listenfd用LT更稳妥，避免丢连接请求

监听套接字（listenfd）的就绪，代表有新的客户端连接到达。但内核的accept队列可能一次入队多个连接，而accept()每次只能取出一个。

如果对listenfd使用ET模式：

• 新连接批量到达时，epoll_wait只通知一次
• 你只调用一次accept，其余连接就卡在队列里，直到下次有新连接到来才再次触发
• 结果就是部分客户端连接被静默丢弃，表现为“偶发性连接失败”

所以生产环境几乎都对listenfd用LT：event.events = EPOLLIN；而对已建立的连接套接字（cfd）才考虑ET以提升吞吐

ET性能更高，但容错性差，调试难度大

ET减少事件重复通知，降低用户态与内核态切换次数，在连接数多、单连接流量小的场景（如HTTP短连接）优势明显。nginx就默认用ET。

但它把“事件完整性”的责任完全交给应用层：

• 忘记设非阻塞？recv或send直接阻塞，整个event loop卡死
• 没检查EAGAIN就跳出读循环？数据残留，后续收不到新通知
• 写事件（EPOLLOUT）用ET更要小心：只有发送缓冲区从满变空才触发，但多数时候你并不需要监听它，除非做流控或零拷贝发送

真正难的不是写ET代码，而是验证它在各种边界条件下（断网重连、突发包、半包粘包）是否始终能一次清空缓冲区

到这里，我们也就讲完了《epoll边沿触发与水平触发区别详解》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！