Linux epoll 怎样区分水平与边沿触发

Linux epoll 默认是水平触发（LT）。只有在注册事件时显式加入 EPOLLET，才会切换到边沿触发（ET）。实际选择时可以记住一句话：LT 关注“现在仍然可读吗”，ET 关注“状态是否刚刚从不可读变成可读”。如果使用 ET，文件描述符应设为非阻塞，并在一次唤醒后持续读取到 EAGAIN；否则接收缓冲区里还留着数据，事件循环却可能等不到下一次提醒。

默认不写 EPOLLET 时，epoll 采用水平触发

LT 的判断标准是文件描述符当前的就绪状态。以 socket 为例，接收缓冲区里只要还有可读数据，epoll_wait 就可能继续返回 EPOLLIN。本次回调只读出一部分并不等于事件被永久消费，下一轮仍有机会继续处理。

因此 LT 更像一个宽容的默认模式：业务处理可以分段进行，事件循环也不必把所有数据一次读完。代价是同一个 fd 在数据未消费完时可能反复出现在就绪集合里，处理逻辑必须避免无效空转。

ET 的变化点是“状态边沿”，不是另一种数据读取 API

设置 EPOLLET 后，内核更关注状态变化。例如缓冲区从空变为可读时给出提醒；如果第一次只读走一部分，剩余数据并不会自动保证再次提醒。这个边界正是 LT 与 ET 最容易混淆的地方：ET 仍然调用普通的 read，只是应用必须自己维护“还有多少数据未消费”的状态。

ET 必须配合非阻塞读取

ET 场景先把 fd 设为非阻塞，再在 EPOLLIN 分支里循环 read。读到 EAGAIN 代表当前内核缓冲区暂时没有更多数据，本轮读取可以结束；这不是异常，也不是应该立即关闭连接的信号。

// 说明：ET 事件只展示读取边界，fd 已在注册前设为非阻塞。
for (;;) {
    ssize_t n = read(fd, buf, sizeof buf);
    if (n > 0) {
        // 处理本次拿到的数据；真实项目还要维护半包状态。
        consume_bytes(buf, (size_t)n);
        continue;
    }
    if (n == -1 && (errno == EAGAIN || errno == EWOULDBLOCK)) {
        // 读到当前边界，保留连接状态，等待后续事件。
        break;
    }
    if (n == 0) {
        // 对端关闭连接，释放 fd 对应的业务状态。
        close_connection(fd);
        break;
    }
    // 其他错误按项目策略记录并关闭，避免事件循环空转。
    handle_read_error(fd, errno);
    break;
}

怎么选模式：先看读取责任，再看并发规模

如果目标是让事件循环容易理解、每次只做有限工作，LT 往往是更稳的起点；如果连接数量较多，且团队已经有非阻塞读写、半包缓存和状态机，ET 才有明确的控制价值。不要只因为“ET 更高效”就切换，漏读、阻塞调用和未处理的写缓冲都可能让整个循环停住。

• 检查清单：注册时是否真的带了 EPOLLET。
• ET 下 fd 是否非阻塞，读和写是否都以 EAGAIN 作为边界。
• 一次事件是否限制处理量，避免单个 fd 长时间占用事件循环。

常见问题

不设置 EPOLLET 就一定是 LT 吗？

对 epoll 的常规事件注册来说是这样。LT 是默认语义，代码中看不到 EPOLLET 时先按 LT 理解。

ET 读到 EAGAIN 后要不要重新 epoll_ctl？

普通 ET 监听不需要因为一次读到 EAGAIN 就重复 ADD；保留 fd 和业务状态即可。若使用 EPOLLONESHOT，则还要按并发模型通过 epoll_ctl(EPOLL_CTL_MOD) 重新布防。

LT 会不会比 ET 慢？

不能只凭模式下结论。LT 的重复唤醒成本要结合数据量、处理批次和 fd 数量测量；正确性优先时，先用 LT 把读取边界写清楚通常更容易。