Linux epoll 怎样理解 ET 和 LT 的读取差异

我第一次把 epoll 从 LT 改成 ET 时，最容易误判的一点是：epoll_wait 返回“可读”，不等于这次调用只需要读一次。LT 关注的是“现在仍然满足可读条件”，只要缓冲区还有数据，下一轮通常还会返回；ET 关注的是“状态发生了变化”，事件处理后如果只读走一部分数据，剩余数据可能再也等不到新的通知。

先把 LT 和 ET 的“读取差异”说清

假设 pipe 或 socket 的输入缓冲区一次进入 2 KB，第一次事件返回后只读取 1 KB。LT 下一次等待仍能看到可读状态，因为缓冲区里还剩 1 KB；ET 则可能没有新边沿，下一次 epoll_wait 直接等待，剩余数据就卡在内核缓冲区里。

所以两者的差异不在于“ET 一定更快”，而在于应用承担的责任不同。LT 可以把一次就绪当作一次处理机会；ET 必须把这次机会用到当前 I/O 空间耗尽。Linux man-pages 还特别提醒，ET 场景应使用非阻塞文件描述符，避免读取调用把整个事件循环卡住。

ET 迁移前先固定三个前置条件

第一，监听 socket 和已接受连接都要设为非阻塞，不能只设置其中一个。第二，事件处理函数不能把“读到一小段”当成“本轮完成”，而应继续读取。第三，必须规定读取循环的结束信号：对流式 socket 来说，非阻塞 read 返回 EAGAIN 或 EWOULDBLOCK，才表示暂时没有更多数据。

如果业务协议有完整帧、换行符或长度字段，读到 EAGAIN 只代表本轮内核缓冲区暂时耗尽，不代表一条业务消息已经完整。应用仍要把半包保存在连接状态里，等下一次事件继续拼接。

把“只读一次”的旧代码改成可回收循环

下面是一个只展示读取核心的 C 片段。它没有假装处理完整协议帧，重点是把 ET 的读取终点、EOF 和错误分开。实际项目还需要把 data 追加到连接自己的输入缓冲区。

char data[4096];
for (;;) {
    ssize_t n = read(fd, data, sizeof(data));

    if (n > 0) {
        // 把本次字节追加到连接缓冲区，再按协议拆出完整消息。
        append_input_buffer(conn, data, (size_t)n);
        continue; // ET 要继续读，直到内核暂时没有数据。
    }

    if (n == 0) {
        // 返回 0 表示对端有序关闭，先完成剩余业务数据的处理。
        close_connection(conn);
        break;
    }

    if (errno == EINTR) {
        // 被信号打断不代表连接异常，本轮直接重试读取。
        continue;
    }

    if (errno == EAGAIN || errno == EWOULDBLOCK) {
        // 非阻塞 fd 的 EAGAIN 是本轮读取结束，不是失败。
        arm_next_event(conn);
        break;
    }

    // 其他 errno 需要记录并按连接错误策略清理资源。
    report_read_error(conn, errno);
    close_connection(conn);
    break;
}

这里的 arm_next_event 只是示意：若采用 EPOLLONESHOT，需要通过 epoll_ctl(EPOLL_CTL_MOD) 重新激活 fd；未使用 one-shot 时，则要确保连接状态仍在 ready 集合的管理范围内。不要把 EAGAIN 当作“连接关闭”，也不要在 ET 下无条件调用阻塞式读取。

选择模式时看维护成本，而不是只看吞吐

ET 也不是“读到 EAGAIN 就永远不能停”。如果单个连接持续有海量数据，完全排空可能让其他 fd 长时间得不到调度。更稳妥的做法是给每个连接设置本轮字节或消息预算，达到预算后放回 ready 队列；下一轮继续从上次的位置读取。这是应用层公平性策略，不改变 ET 必须正确处理剩余数据的事实。

上线前用这份清单回归

• 注册事件时是否明确知道自己使用 LT 还是 ET，代码注释是否和实际 flags 一致？
• ET 下监听 fd、连接 fd 是否都设置了非阻塞？
• 读取循环是否覆盖正数、0、EINTR、EAGAIN 和其他错误？
• 半包是否保存在连接状态，而不是把一次 read 当成完整消息？
• 是否限制单个 fd 的处理预算，并在关闭时移除事件、释放缓冲区？

我的取舍是：新服务先用 LT 把协议状态和关闭路径跑通，确认连接数和调度压力确实需要再迁移 ET。若已经采用 ET，就把“读到 EAGAIN”写成代码结构的一部分，而不是依赖开发者记忆。

常见问题

LT 模式也能把 fd 设置成非阻塞吗？

可以，而且通常更安全。LT 与阻塞/非阻塞是两层概念；非阻塞能避免单个连接的读取拖住整个事件循环。

ET 下一次 read 返回小于缓冲区大小，能直接停止吗？

对流式文件描述符，这常常意味着当前可读空间被耗尽，但通用代码仍应以非阻塞读取返回 EAGAIN 为明确终点，避免把不同类型 fd 的行为混为一谈。

EPOLLONESHOT 和 ET 是一回事吗？

不是。ET 改变就绪通知的触发语义，EPOLLONESHOT 则是在一次事件交付后暂时禁用该 fd；使用 one-shot 时要在处理结束后显式 MOD 重新激活。