Linux epoll ET 模式为什么容易漏事件

服务端明明收到了一次 EPOLLIN，代码也成功读出了一部分数据，随后循环返回 EAGAIN，但客户端剩下的数据却迟迟没有进入下一次处理。这个现象通常不是 epoll 丢事件，而是把 ET（边沿触发）误当成了“每次有数据都提醒”。

ET 的安全写法是：fd 设置为非阻塞；收到事件后持续读或写，直到返回 EAGAIN / EWOULDBLOCK。只读一次就回到 epoll_wait，剩余数据可能没有新的边沿变化，自然不会再次提醒。

先还原现场：为什么剩余数据不再提醒

假设 socket 缓冲区里来了 2 KB，第一次 epoll_wait 返回可读，程序只取走 1 KB。ET 记录的是“不可读变为可读”这一变化；剩下的 1 KB 没有再次经历同样的状态变化，所以后续等待可能阻塞。LT 则会因为缓冲区仍可读而继续报告，这正是两者最容易混淆的地方。

非阻塞和持续读取必须成对出现

ET 处理时如果 fd 仍是阻塞模式，第一次 recv 取完现有数据后可能继续等待下一批数据，一个连接就能卡住整个事件循环。因此监听 fd 用 accept4 设置 SOCK_NONBLOCK，连接 fd 也要保持非阻塞。

for (;;) {
    ssize_t n = recv(fd, buf, sizeof buf, 0);
    if (n > 0) {
        /* 消费本次读到的数据；真实项目应交给协议解析器。 */
        feed_parser(buf, (size_t)n);
        continue; // ET 要继续读，直到内核明确说暂时读尽
    }
    if (n == 0) {
        /* 对端有序关闭，先移出 epoll 再释放连接状态。 */
        close_connection(epfd, fd);
        break;
    }
    if (errno == EINTR) {
        /* 信号中断不代表连接异常，直接重试本次读取。 */
        continue;
    }
    if (errno == EAGAIN || errno == EWOULDBLOCK) {
        /* 非阻塞读到当前边界，回到事件循环等待下一次变化。 */
        break;
    }
    /* 其他 errno 是真实 I/O 错误，记录后清理 fd。 */
    log_socket_error(fd, errno);
    close_connection(epfd, fd);
    break;
}

这里的关键不是“循环次数多”，而是把 EAGAIN 当作本轮读操作的结束信号。没有这个边界，程序要么只读半包，要么在非阻塞循环里误报错误。

读到 EAGAIN 后，如何判断到底有没有漏事件

先看应用层是否保存了半包。TCP 是字节流，一次 recv 返回小于请求长度并不等于一条消息完整结束；协议解析器应把数据追加到连接缓冲区，按长度字段或分隔符拆包。若解析器只处理本次返回值，剩余半包会被误诊为 epoll 漏事件。

排查时同时记录 fd、每轮读取字节数、errno 和协议缓冲区长度。只看到“事件来了”或“返回 EAGAIN”其中一项，证据还不完整。

常见问题：ET 代码最容易错在哪里

读到 EAGAIN 后要不要再次 epoll_ctl？

通常不需要。只要 fd 仍注册且关注 EPOLLIN|EPOLLET，就回到 epoll_wait；新的数据到达会形成新的可读变化。

为什么 ET 一定要设置 O_NONBLOCK？

因为你无法预先知道下一次数据何时到达。阻塞读会把事件循环卡在单个 fd 上，非阻塞读才能用 EAGAIN 明确结束本轮工作。

循环读到 EAGAIN 还是会卡住怎么办？

检查是否真的设置了非阻塞，以及循环里是否混入了阻塞的协议处理或同步写。对高流量连接增加单轮预算，并把未完成 fd 放回就绪队列。

EPOLLONESHOT 能解决漏事件吗？

它解决的是多线程或多 worker 重复处理同一 fd 的问题，不会替代 ET 的读尽逻辑。使用后每轮处理完成还必须用 EPOLL_CTL_MOD 重新 arm。

复查清单

上线前按这个顺序复查：连接 fd 是否为非阻塞；EPOLLIN 分支是否循环到 EAGAIN；EOF、EINTR 和其他错误是否分开处理；协议缓冲区是否支持半包；单连接是否有公平预算。满足这些条件后，ET 的“漏事件”大多会还原成一次错误的读取边界，而不是内核异常。