Linux epoll LT 模式什么时候更易维护

在高并发服务里，epoll 的难点通常不是“能不能收到事件”，而是事件到达以后，连接状态、读写缓冲区和关闭清理能不能长期保持一致。如果团队更看重代码可读性、故障定位和后续接手成本，默认的 LT（Level-Triggered，水平触发）通常更容易维护；ET（Edge-Triggered，边沿触发）只有在团队能稳定执行非阻塞、持续处理到 EAGAIN、并控制单连接工作量时才值得引入。

先按语义区分 LT 与 ET

epoll 实例可以看成两个内核维护的集合：interest list 保存已经注册的文件描述符，ready list 保存当前可以进行 I/O 的引用。epoll_wait 从 ready list 取出事件。LT 和 ET 的区别不在于“一个快、一个慢”，而在于 ready 条件被消费一部分后，内核是否继续提醒用户态。

官方示例说明：如果缓冲区里还有数据，LT 会继续保持可读语义；ET 只在状态变化时发出通知，因此只读走一部分数据后，下一次等待可能不会再次提醒。这个差异决定了 ET 的代码必须把“本次没处理完”记录在连接状态中，而 LT 可以把一部分重试交给下一轮事件等待。

把维护成本拆成事件循环和连接状态

在服务端循环中，LT 的优势是让“仍然可读”保持显式。处理一个连接时，即使本轮只读完了协议头或一部分请求体，只要内核条件仍满足，下一轮仍有机会再次拿到该 fd。连接状态机只需要记录已读字节、解析阶段和待发送缓冲，不必额外保证每一次状态变化都重新触发事件。

ET 把更多责任推给用户态：fd 必须是非阻塞的；读侧要处理到 EAGAIN 或明确的 EOF/错误；写侧要保留未发送完的字节，并在发送缓冲从“有数据”变成“可继续写”时正确调整关注事件。这样做可以减少某些重复通知，但会把事件循环、缓冲区和状态机绑得更紧。

高压场景里，两种模式都要处理公平性。LT 如果一个 fd 始终可读，可能产生重复唤醒；ET 如果一次把一个大缓冲区全部排空，也可能让其他连接饥饿。因此真正需要维护的是每轮工作预算、连接生命周期和可回收状态，而不是只盯着触发模式的名字。

/* 这是结构示例：省略 socket、bind、listen 和错误日志细节 */
int epfd = epoll_create1(0);
struct epoll_event watch = {0};

/* 不设置 EPOLLET，表示采用默认的 LT 语义，连接状态更容易分层管理 */
watch.events = EPOLLIN | EPOLLRDHUP;
watch.data.fd = client_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &watch);

for (;;) {
    struct epoll_event events[64];
    int count = epoll_wait(epfd, events, 64, -1);
    if (count 

这段骨架没有把“读到 EAGAIN”当作唯一的状态推进条件，也没有伪造运行输出。它表达的是维护边界：事件循环负责分发，连接处理器负责协议状态，关闭路径负责先从 epoll 集合移除再释放关联对象。

用最小服务循环做模式选择

如果系统的请求体大小变化大、协议解析阶段多、团队成员经常需要排查半包和异常关闭，先用 LT 往往更稳。它允许实现者把“读一次”“读到当前缓冲上限”“本轮预算用尽”作为清晰的策略，而不是把所有情况都塞进一个 drain 循环。

ET 更适合有明确事件驱动状态机的服务：所有相关 fd 已设置非阻塞；读写函数都能在 EAGAIN、EOF、错误和部分完成之间做区分；发送队列可以在需要时重新关注 EPOLLOUT；连接关闭时不会留下缓存事件指向已释放对象。若这些约束还没有成为团队的固定模板，ET 的维护收益通常会被排障成本抵消。

按上线后的运行信号维护

上线后不要只用吞吐量判断模式选择。先观察几个更能说明维护成本的信号：同一连接是否长期占用事件循环、可读事件是否反复出现却没有推进协议状态、ET 代码是否在异常路径漏掉 EAGAIN、关闭后是否仍处理指向旧连接对象的缓存事件。

# 查看进程打开的 fd 数量，先确认连接泄漏是否正在扩大
ls "/proc/$PID/fd" | wc -l

# 查看 epoll 实例关联的 fd，辅助核对 interest list 的规模变化
cat "/proc/$PID/fdinfo/$EPOLL_FD"

# 只记录排障方向：不要把示例 PID 当成真实线上结果

如果 LT 出现重复唤醒，优先增加每连接的读取预算、拆分大请求处理或检查是否持续关注不必要的写事件；如果 ET 出现偶发卡住，优先检查非阻塞设置、是否真的处理到 EAGAIN、发送队列是否正确重臂以及关闭路径是否清理完整。只有这些信号稳定后，才有理由把 ET 当成架构优化，而不是把它当成默认答案。

相关问题

LT 是否一定比 ET 慢？

不一定。LT 可能增加重复通知，但它的语义接近传统的 poll 使用方式；实际收益取决于连接分布、单次工作量、协议状态机和调度策略，不能只凭模式名称下结论。

用了 ET 还需要非阻塞 fd 吗？

需要。阻塞读写可能让负责多个 fd 的事件循环被单个连接拖住；官方建议 ET 配合非阻塞 fd，并在读写返回 EAGAIN 后再次等待事件。

什么时候可以从 LT 迁移到 ET？

当连接状态、读写缓冲、异常关闭、工作预算和监控指标都有统一实现，并能用压测与故障演练证明重复通知确实是瓶颈时，再以小范围迁移评估。否则保留 LT 往往是更低维护成本的工程选择。

参考文档：https://man7.org/linux/man-pages/man7/epoll.7.html