• 一、 内核核心数据结构准备
• 二、 重点拆解：水平触发（LT）的内核源码演进
• 1. 核心链路调用
• 2. 深入 `ep_send_events_proc()` 源码剖析
• 3. LT 机制的数学/逻辑闭环
• 三、 对比剖析：边缘触发（ET）的内核细节
• 1. ET 的断开逻辑
• 2. ET 是如何再次被唤醒的？
• 四、 内核处理数据流时的细节差异与性能影响
• 深度考量：LT 的“惊群”与 CPU 暴涨隐患
• 五、 系统工程师的高级架构建议

前言

本文旨在记录近期研读Java源码的学习心得与疑难问题。由于个人理解水平有限，文中内容难免存在疏漏，恳请读者不吝指正。

epoll水平触发源码剖析

作为一名系统工程师，理解 epoll 的水平触发（Level-Triggered, LT）和边缘触发（Edge-Triggered, ET）的核心差异，不能仅停留在“LT 会重复通知，ET 只通知一次”的表面结论，而是要深入到 Linux 内核源码的内核事件驱动机制、就绪链表（rdllist）的管理策略逻辑中。

以下我们以 Linux 内核主流版本（如 5.x/6.x）的 fs/eventpoll.c 源码为核心，深度拆解它们在处理数据流时的底层细节差异，并重点剖析水平触发（LT）的内核运转逻辑。

一、 内核核心数据结构准备

在进入源码前，先复习 epoll 在内核中的两个关键数据结构，这是理解整个触发机制的基石：

• struct eventpoll：每一个 epoll 实例的顶层结构体，内部包含红黑树 rbr（管理所有被监听的 fd）和双向链表 rdllist（就绪链表，保存当前有事件触发的 fd）。
• struct epitem：被监听的每一个 fd 在 epoll 内核中的代表。它既是红黑树的节点，也是就绪链表的节点。

二、 重点拆解：水平触发（LT）的内核源码演进

水平触发是 epoll 的默认模式。从内核视角来看，水平触发的本质是：“只要底层缓冲区还有数据（满足事件条件），该节点的引用就必须保留在就绪链表中，或者在被消费后重新放回就绪链表。”

我们通过用户态调用 epoll_wait() 的链路，来看内核是如何处理 LT 事件的。

1. 核心链路调用

当用户态调用 epoll_wait() 时，内核会依次触发以下核心函数：

sys_epoll_wait() 
  └── do_epoll_wait()
        └── ep_poll()
              └── ep_send_events()
                    └── ep_send_events_proc()  <-- 核心逻辑就在这里

2. 深入 ep_send_events_proc() 源码剖析

ep_send_events_proc 的主要任务是将内核就绪链表 rdllist 中的事件拷贝到用户态的 events 数组中。

为了防止频繁加锁影响性能，内核采用了一个精妙的设计：先将 ep->rdllist 链表整体拼接（Splice）转移到一个局部的临时链表 txlist 中，然后解锁主链表，专注于处理 txlist。

以下是精简后的内核核心逻辑代码：

static int ep_send_events_proc(void *priv, void *cookie, int call_nacks)
{
struct ep_send_events_data *esed = priv;
struct eventpoll *ep = esed->ep;
struct epitem *epi, *tmp;
struct list_head txlist;
    poll_table pt;

// 1. 初始化临时链表，并将 ep->rdllist 挪到 txlist 中清空原链表
    INIT_LIST_HEAD(&txlist);
    list_splice_init(&ep->rdllist, &txlist);

// ... 省略加锁与初始化逻辑 ...

// 2. 遍历临时就绪链表 txlist
    list_for_each_entry_safe(epi, tmp, &txlist, rdllist) {
struct epoll_event event;
__poll_t revents;

// 将当前节点从 txlist 中移除
        list_del_init(&epi->rdllist);

// 3. 关键：调用底层驱动的 poll 虚函数（如 sock_poll），再次确认当前 fd 实际发生的事件
        revents = ep_item_poll(epi, &pt, 1);

if (revents) {
// 将事件掩码和用户数据组合成标准 epoll_event
            event.events = revents & epi->event.events;
            event.data = epi->event.data;

// 4. 将事件拷贝到用户态空间
if (__put_user(event.events, &esed->events[esed->res].events) ||
                __put_user(event.data, &esed->events[esed->res].data)) {

// 如果拷贝失败，将节点放回原 rdllist 并退出
                list_add(&epi->rdllist, &ep->rdllist);
return -EFAULT;
            }
            esed->res++; // 成功拷贝的事件计数加 1

/* * 5. 【重头戏】水平触发与边缘触发的分水岭 
             */
if (epi->event.events & EPOLLET) {
// 如果是边缘触发（ET），这里什么都不做！
// 节点已经移出了 txlist，且没有放回 ep->rdllist，它彻底离开了就绪队列
            } else {
// 如果是水平触发（LT），内核会把这个节点【重新放回】epoll 的就绪链表 rdllist 中！
                list_add_tail(&epi->rdllist, &ep->rdllist);
            }
        }

// 如果处理的用户数组满了，提前跳出
if (esed->res == esed->maxevents)
break;
    }

// 6. 如果由于 maxevents 限制导致 txlist 没遍历完，把剩余的节点无条件放回 ep->rdllist
if (!list_empty(&txlist)) {
        list_splice(&txlist, &ep->rdllist);
    }

// ... 省略解锁逻辑 ...
return esed->res;
}

3. LT 机制的数学/逻辑闭环

从上面的第 5 步可以看到：

• 在 LT 模式下：只要底层 ep_item_poll() 返回的 revents 不为 0（即缓冲区还有未读数据或可写空间），内核在把事件塞给用户态之后，立马通过 list_add_tail 把这个 epitem重新挂回了 ep->rdllist 的末尾。
• 结果：下一次用户再次调用 epoll_wait() 时，内核一看 rdllist 里面居然还有这个节点，就会立刻再次触发 ep_send_events_proc，继续向用户态报告：“别吃了，这里还有饭！”

三、 对比剖析：边缘触发（ET）的内核细节

既然看懂了 LT 的“回放机制”，ET 的机制就极好理解了。

1. ET 的断开逻辑

如源码中所示，在 ET 模式下（epi->event.events & EPOLLET 成立），内核执行完用户态拷贝后，直接对该 epitem 放任不管。因为之前已经执行了 list_del_init(&epi->rdllist)，该节点已经与就绪链表脱离了关系。

2. ET 是如何再次被唤醒的？

既然从就绪链表中被移除了，ET 模式下的 fd 怎么才能再次被 epoll_wait 感知？ 答案是：必须等待底层协议栈（或文件系统驱动）的下一次状态状态翻转（Transition）。

例如，对于 TCP 接收流：

1. 网卡收到新数据包 -> 触发硬件中断 -> 软中断。
2. 内核协议栈处理并将数据塞入 TCP 接收缓冲区（sk_receive_queue）。
3. 协议栈调用 sk->sk_data_ready 唤醒回调函数，在 epoll 中，这个回调被注册为 ep_poll_callback()。

我们来看 ep_poll_callback() 的简化核心代码：

static int ep_poll_callback(wait_queue_entry_t *wait, unsigned mode, int flags, void *key)
{
struct epitem *epi = ep_item_from_wait(wait);
struct eventpoll *ep = epi->ep;

// ... 检查事件是否匹配 ...

// 关键点：如果当前节点不在 rdllist 中，则将其加入
if (!ep_is_linked(epi)) {
        list_add_tail(&epi->rdllist, &ep->rdllist);

// 唤醒在 epoll_wait 中睡眠的进程
if (waitqueue_active(&ep->wq))
            wake_up(&ep->wq);
    }

return 1;
}

ET 的本质： 只有网卡再次来新数据、或者缓冲区状态发生明确改变时，才会触发 ep_poll_callback 重新把节点挂回 rdllist。如果用户在 ET 模式下没有一次性把缓冲区数据读完（读到 EAGAIN），剩余的数据将永远留在内核缓冲区里，直到下一次新数据到达，才会“顺便”被报上来。

四、 内核处理数据流时的细节差异与性能影响

将上述内核源码的行为映射到上层应用的数据流处理上，会带来巨大的架构设计差异：

深度考量：LT 的“惊群”与 CPU 暴涨隐患

做过高并发网络优化的同学都知道，LT 虽然写代码爽快，但有巨大的内核开销隐患：

1. Busy-Loop 隐患：如果你的应用层收到一个 LT 的可读通知，但因为应用层业务缓冲区满了，你选择暂时不读它。此时，你的事件循环（Reactor）只要再次调用 epoll_wait，内核就会因为 LT 的 list_add_tail 机制疯狂立刻返回，导致整个线程跑满 CPU（100% 死循环），这在工程师术语里叫“LT 触发地狱”。
2. Epoll 惊群（Thundering Herd）：在旧版本内核中，多个工作线程/进程共同 epoll_wait 同一个 epoll_fd。当一个 LT 模式下的 fd 有数据时，即使一个线程被唤醒并开始处理，由于它还在 rdllist 中，内核可能会同时唤醒其他也在等待的多个线程。现代内核虽然引入了 EPOLLEXCLUSIVE 进行了部分修正，但 ET 在机制上天生就对减少不必要的唤醒更加友好。

五、 系统工程师的高级架构建议

根据以上的内核细节分析，在定制高性能网络引擎（如类 Nginx、Envoy 架构）时，可以总结出如下开发范式：

• 选择 ET 的场景：追求极致吞吐量、连接数达到数十万/百万级、Proxy 型服务（只负责转发，数据来多少转多少）。此时必须配合非阻塞 I/O + while(read) 直到 EAGAIN。
• 选择 LT 的场景：连接数相对可控、对开发心智负担要求低、或者需要精细控制流量的场景。

💡 高级技巧（LT 的正确打开方式）：如果用 LT 又想避免 Busy-Loop，可以在收到可读事件但应用层无法消费时，调用 epoll_ctl(..., EPOLL_CTL_MOD, ...) 将该 fd 的监听事件暂时改为 0（或者只听错误事件）。等到应用层腾出空间了，再 EPOLL_CTL_MOD 恢复监听 EPOLLIN。这种做法在内核中会通过红黑树操作将其从 rdllist 中彻底剥离，有效消除了 LT 的空转开销。