深度剖析：epoll ET 模式下如果不设非阻塞，内核里会发生什么？

在 Linux 高性能网络编程中，**“epoll 的 ET（边缘触发）模式必须配合非阻塞（Non-blocking）Socket 使用”**几乎是一条铁律。

但你是否深入思考过：如果不这么做，到底会发生什么？底层的内核运转逻辑又是怎样的？

这不是一个简单的“会报错”的问题，而是会直接导致进程死锁（Hang住）或数据吞吐停滞（饥饿）。本文将从内核源码逻辑、事件触发机制以及 Reactor 模型的视角，彻底拆解这背后的运行机理。

结论先行：两个致命的“两难困境”

在 ET（Edge Triggered）模式下，内核只会在 Socket 的状态发生变化（如缓冲区从无数据变为有数据，或有新数据到达）时，向用户空间发送一次通知。

如果我们在 ET 模式下使用阻塞（Blocking）Socket，编写读取数据的代码时，会直接陷入以下两种无法调和的死局：

困境一：循环读取导致线程永久阻塞（Hang死）

为了保证把内核缓冲区中的数据“一次性读完”（这是 ET 模式的要求），我们必须写一个循环：

while (true) {
    int n = read(fd, buf, sizeof(buf));
    // ... 处理数据 ...
}

• 如果 Socket 是非阻塞的：当缓冲区读空时，read 会立即返回 -1，并将 errno 设置为 EAGAIN 或 EWOULDBLOCK。此时循环优雅退出，线程继续去执行 epoll_wait 监听其他事件。
• 如果 Socket 是阻塞的：当前面几轮循环把内核缓冲区的数据读完后，最后一轮 read 不会返回 EAGAIN，而是直接阻塞在该 Socket 上，等待对端发送更多数据。此时，当前线程被挂起，无法返回主循环调用 epoll_wait。这意味着该线程管理的整个 Reactor 事件循环直接瘫痪，其他所有连接的请求都将得不到处理。

困境二：单次读取导致数据永久“饥饿”（丢包幻觉）

既然循环读会阻塞，那我不循环，只读一次行不行？

// 收到 ET 通知后，只读一次
int n = read(fd, buf, sizeof(buf)); 

• 如果对端发送的数据小于你的 buf 空间：看起来没问题。
• 如果对端发送的数据大于 buf 空间（或者发生了粘包/半包）：由于你只调用了一次 read，内核缓冲区里还会残留一部分数据。
• 致命问题来了：因为这是 ET 模式，内核只在数据到达的那一刻触发一次通知。由于缓冲区里一直有残留数据，状态没有发生“从无到有”的变化，内核绝对不会再为这个 fd 触发下一次读事件。残留的数据会一直堆积在内核中，直到对端下一次再发送新数据（如果有的话）才会顺便被带出来。这在业务层表现为极其诡异的响应延迟或数据丢失。

内核底层的运行逻辑

要理解为什么内核会表现出上述行为，我们需要深入到 Linux 内核中 epoll 的实现机制。

1. 关键的数据结构

在内核中，每个 epoll 实例对应一个 eventpoll 结构体，其中有两个极其关键的队列：

• rdllist（Ready List，就绪链表）：存放所有已经就绪、等待用户调用的文件描述符（epitem）。
• wq（Wait Queue，等待队列）：存放调用 epoll_wait 并处于阻塞状态的用户进程/线程。

而每个 Socket 本身也有自己的等待队列 sk_wq。

2. LT 与 ET 在内核层面的核心区别

当 Socket 收到网络数据包，硬件中断触发，内核协议栈（如 TCP）处理完数据后，会将数据放入 Socket 的接收缓冲区（sk_receive_queue），并调用 sk->sk_data_ready 回调函数。

在 epoll 场景下，这个回调函数实际上是 ep_poll_callback。它的主要工作是：将该 Socket 对应的 epitem 挂载到 eventpoll 的就绪链表 rdllist 中，并唤醒在 epoll_wait 中睡眠的进程。

当用户调用 epoll_wait 时，内核会将 rdllist 中的事件复制到用户空间。

重点在于复制完成后，内核如何处理这个事件：

                    用户调用 epoll_wait()
                             │
                    内核检查 rdllist 是否为空
                             │
           ┌─────────────────┴─────────────────┐
       [ 存在就绪事件 ]                     [ 无就绪事件 ]
           │                                   │
   将事件复制到用户空间                       进程挂起在 epoll 的 wq
           │                                   │
   ┌───────┴──────────────────────┐            └─────────── ... 
   │ 检查事件的触发模式             │
   ▼                              ▼
[ LT 模式 (Level Triggered) ]   [ ET 模式 (Edge Triggered) ]
   │                              │
 重新将该 epitem 放回 rdllist        不放回 rdllist
   │                              │
(只要内核缓冲区还有数据，          (除非下一次收到新数据，
下一次 epoll_wait 还会触发)        否则该 fd 不会再触发事件)

• LT 模式（水平触发）：内核在将事件复制给用户后，会检查这个 fd 的状态。如果发现用户没把缓冲区读完，或者当前仍然可读，内核会重新将该 epitem 放回 rdllist。因此，下一次调用 epoll_wait 时，它依然会立即返回。
• ET 模式（边缘触发）：内核将事件复制给用户后，直接从 rdllist 中将其移除，且不放回。这意味着，该事件在内核的就绪链表中消失了。只有当该 Socket 下一次再次发生状态变化（例如协议栈又收到了新的 TCP 报文）时，ep_poll_callback 被再次触发，它才会被重新放入 rdllist。

3. 阻塞 Socket 如何搞垮内核级的事件驱动

当你在 ET 模式下使用阻塞 Socket 并尝试循环读取时，发生了什么？

1. 第 1 步：网卡收到数据，内核将 Socket 状态标记为可读，并将 epitem 挂载到 rdllist。
2. 第 2 步：用户调用 epoll_wait 成功拿到该 fd，内核同时将该 fd 从 rdllist 中彻底移除。
3. 第 3 步：用户进入 while(read) 循环。
   • 第一次 read：成功，拿到数据。
   • 第二次 read：成功，拿到剩余数据。
   • 第三次 read：此时内核接收缓冲区已空。
4. 第 4 步（灾难发生）：由于 Socket 是阻塞的，内核的 sys_read 发现 sk_receive_queue 为空，它不会返回 EAGAIN。相反，内核会：
   • 将当前用户线程的状态设为 TASK_INTERRUPTIBLE（可中断睡眠状态）。
   • 将该线程的 wait_queue_entry_t 挂载到 Socket 本身的等待队列 sk->sk_wq 中，而不是 epoll 的等待队列。
   • 调度器切走该线程。

此时，该线程彻底失去了对整个事件循环（Reactor）的控制权。即使其他连接有海量数据到达，或者有新连接请求（listenfd 就绪），由于处理它们的线程正阻塞在这个单薄的 Socket 读操作上，整个程序也会表现为完全卡死。

避坑指南：Reactor 模式的黄金组合

在实际的高并发网络库（如 Netty、Nginx、Muduo）设计中，非阻塞 I/O 是 Reactor 模式得以运转的基石。

核心代码套路（ET + Non-blocking）

如果你选择使用 ET 模式，请务必保证：

1. 使用 fcntl(fd, F_SETFL, O_NONBLOCK) 将 Socket 设为非阻塞。
2. 读写操作必须包裹在 while 循环中，直到返回 EAGAIN 或 EWOULDBLOCK。
3. 当写操作（write/send）返回 EAGAIN 时，需要注册 EPOLLOUT 事件；当再次可写并写完所有数据后，需要及时清除 EPOLLOUT 事件，避免 CPU 飙升。