Linux epoll ET 模式为什么会漏事件：非阻塞读取、EAGAIN 与 EPOLLONESHOT

服务端偶发卡住时，日志里常见的不是崩溃，而是某个连接明明还有数据，事件循环却再也收不到提醒。边沿触发（EPOLLET）最容易踩的坑就在这里：一次通知只代表“状态发生过变化”，不代表应用已经把缓冲区读空。

EPOLLET 配合非阻塞 fd 时，收到 EPOLLIN 后要持续读取，直到 read/recv 返回 EAGAIN；如果再叠加 EPOLLONESHOT，处理完成后还要用 EPOLL_CTL_MOD 重新 arm，否则这个 fd 不会再次被 epoll 报告。

先复现：只读一次，为什么连接像“消失”

把一个 TCP 连接注册为 EPOLLIN | EPOLLET，客户端连续写入两段数据。第一次 epoll_wait 返回后，如果服务端只调用一次 recv，恰好只拿走第一段，内核接收缓冲区里仍有第二段。

这时不要把“下一次没有事件”理解为连接没有数据。边沿触发关注的是从未就绪到就绪的变化；应用没有把当前就绪状态消费干净，下一次变化可能迟迟不会出现。官方 epoll(7) 也用“缓冲区没有读空，下一次等待可能挂住”的例子说明了这个边界。

for (;;) {
    int n = recv(fd, buf, sizeof buf, 0);
    if (n > 0) {
        append_request(fd, buf, n);
        break; /* 错误：还有数据也提前退出 */
    }
    if (n == 0) { close_peer(fd); break; }
    if (errno == EAGAIN || errno == EWOULDBLOCK) break;
    close_peer(fd);
    break;
}

这段代码在水平触发下可能只是少做了一点工作；换成 EPOLLET 后，它把“还有数据”留成了一个没有新边沿的状态。

把通知拆成三个状态：就绪、消费、重新等待

更稳妥的事件循环可以分成三步。第一步，epoll_wait 告诉你 fd 当前值得处理；第二步，非阻塞读取或写入，把本轮能消费的内容尽量清空；第三步，只有在返回 EAGAIN 后才回到等待状态。

读取循环的结束条件不是“这次拿到的字节数小于缓冲区”，而是对 socket 来说明确得到 EAGAIN。短读可能只是暂时拿到了一部分数据，不能把它当成缓冲区已空。

static void drain_read(int fd) {
    char buf[8192];
    for (;;) {
        ssize_t n = recv(fd, buf, sizeof buf, 0);
        if (n > 0) {
            feed_parser(fd, buf, (size_t)n);
            continue;
        }
        if (n == 0) {
            close_peer(fd);
            return;
        }
        if (errno == EAGAIN || errno == EWOULDBLOCK) {
            return;
        }
        record_socket_error(fd, errno);
        close_peer(fd);
        return;
    }
}

这里的 feed_parser 只负责把字节交给协议解析器，不在读取循环里等待完整业务请求。这样既能把内核缓冲区排空，也不会因为一条慢请求饿住同一个事件循环里的其他连接。

EPOLLONESHOT：交给工作线程后要记得 rearm

当多个工作线程共享一个 epoll 实例时，可以给连接加上 EPOLLONESHOT，让一次事件只交给一个处理者。它解决的是“同一个 fd 被多个工作者同时取走”的协调问题，但不会替你完成下一轮监听。

struct epoll_event ev = {0};
ev.events = EPOLLIN | EPOLLET | EPOLLONESHOT;
ev.data.fd = client_fd;
epoll_ctl(epfd, EPOLL_CTL_ADD, client_fd, &ev);

/* 线程完成 drain_read 和协议处理后 */
ev.events = EPOLLIN | EPOLLET | EPOLLONESHOT;
epoll_ctl(epfd, EPOLL_CTL_MOD, client_fd, &ev);

如果处理线程忘记 EPOLL_CTL_MOD，现象通常是第一次请求正常、同一连接的后续请求沉默。排查时要把 rearm 的返回值记录下来；fd 已关闭、被其他线程处理或事件掩码写错，都可能让“看似重新注册”实际上失败。

性能和公平性：读到 EAGAIN 也不能无限霸占循环

“读到 EAGAIN”解决了漏读，却可能带来另一个问题：某个连接持续有大量数据，单次 drain_read 会长时间占用事件循环。实践中可以给每个 fd 设置本轮字节预算或消息预算，超过预算就把剩余工作放入待处理队列，并让其他 ready fd 先获得机会。

这个限额是调度策略，不是 EPOLLET 的替代结束条件。若预算耗尽时没有读到 EAGAIN，代码不能直接把 fd 当成空闲；应保留“仍有待处理数据”的状态，避免下一轮调度把它误判为已消费完。

常见问题

EPOLLET 一定比水平触发更快吗？

不一定。它减少了反复报告同一就绪状态的开销，但要求应用严格维护非阻塞读取、排空和调度边界。连接数不高或代码更看重简单性时，水平触发往往更容易维护。

读到短包就可以停止吗？

对流式 socket，短包不等于 EAGAIN。想确认本轮已经没有可读数据，应继续读取直到 EAGAIN，或者采用明确的协议帧边界并仍然处理内核缓冲区的剩余内容。

EPOLLONESHOT 和 EPOLLET 必须一起使用吗？

不是。EPOLLONESHOT 解决一次通知交给一个处理者的问题，EPOLLET 改变就绪通知语义；是否组合取决于线程模型。组合使用时，必须同时遵守 drain-to-EAGAIN 和 rearm 两条规则。

如何确认问题确实是漏读？

在一次事件的 fd 生命周期内记录事件掩码、每次 recv 的返回值、errno、累计字节数以及 EPOLL_CTL_MOD 的结果。如果最后一次读取不是 EAGAIN，却马上进入长时间 epoll_wait，优先检查是否提前退出了读取循环。

把验收点留在日志里

一条可复用的验收记录至少应能回答四个问题：本次事件什么时候到达、读取循环读了多少次、何时得到 EAGAIN、如果启用了 oneshot 是否成功 rearm。只要这四个节点能对上，EPOLLET 的“漏事件”通常就能从感觉问题变成可定位的状态转移。