epoll源码分析，还搞不懂epoll的看过来

epoll 是 Linux 下高性能网络编程的核心利器，几乎所有的高并发服务器（如 Nginx、Redis）都在使用它。但很多人停留在“用 epoll”的层面，对其内部实现一知半解。本文将从 Linux 内核源码视角，深入剖析 epoll 的底层机制，让你彻底搞懂它为什么快、怎么用、以及注意事项。

一、epoll 是什么，解决了什么问题

epoll 全称 event poll，是 Linux 2.6 内核引入的 I/O 事件通知机制。它解决了传统 select/poll 的两个致命缺陷：一是每次调用都要传入整个 fd 集合，内核需要遍历所有 fd 检查状态，O(n) 复杂度在高并发下不堪重负；二是 fd 集合大小受限于 FD_SETSIZE（通常 1024），无法支撑上万连接。epoll 通过“事件驱动 + 回调机制”将复杂度降为 O(1)（就绪事件数），并支持任意多的 fd。

二、核心数据结构：从 epoll_create 说起

要理解 epoll，先看它的三个系统调用：epoll_create、epoll_ctl、epoll_wait。我们从 epoll_create 开始。内核中，每个 epoll 实例对应一个 struct eventpoll 对象，其核心成员包括：

• wq：等待队列，存放阻塞在 epoll_wait 上的进程。

• rdllist：就绪链表，存放所有发生事件的 fd 节点（epitem）。

• rbr：红黑树根节点，用于管理所有被监控的 fd，实现快速增删改查。

• ovflist：溢出列表，用于在并发情况下暂存事件。

源码位于 fs/eventpoll.c。创建时，内核分配一个 eventpoll 结构，并返回一个匿名文件描述符（通过 anon_inode_getfile）。这个 fd 本身不表示任何 I/O 资源，而是作为 epoll 实例的句柄。

三、红黑树与回调注册：epoll_ctl 的精髓

epoll_ctl 负责添加、修改或删除监控的 fd。以 EPOLL_CTL_ADD 为例，核心流程如下：

1. 根据传入的 fd，找到对应的 struct file 对象。

2. 在 eventpoll 的红黑树（rbr）中查找是否已存在该 fd 的 epitem。若存在则返回错误，否则新建一个 epitem。

3. 将 epitem 的 fllink 挂到目标 file 的等待队列上（通过 file->f_op->poll 或 vfs_poll），并设置回调函数 ep_poll_callback。

4. 将 epitem 插入红黑树，同时初始化其就绪状态（未就绪）。

这里最关键的是回调注册：当被监控的 fd 发生 I/O 事件（如可读、可写）时，设备驱动会调用其等待队列上的唤醒函数，而 epoll 注册的回调 ep_poll_callback 会被触发。该回调函数会将当前 epitem 加入到 eventpoll 的就绪链表 rdllist 中，并唤醒在 wq 上睡眠的进程（如果有）。这就是 epoll 的“被动通知”机制，完全避免了遍历所有 fd 的开销。

红黑树（rbtree）的作用在于快速管理大量 fd。增删改查的时间复杂度为 O(log N)，虽然 select 的 O(N) 在 N 很小时可能更快，但 N 达到数千上万时，红黑树的优势不可比拟。内核使用红黑树而非哈希表，是因为需要支持范围查询和有序遍历（虽然 epoll 实际未用到顺序），且红黑树在动态增删场景下更稳定。

四、就绪链表与 epoll_wait 的唤醒逻辑

epoll_wait 是用户态获取就绪事件的入口。其核心是检查 rdllist 是否为空。若为空且设置了超时，则调用 schedule_hrtimeout 让当前进程进入睡眠，挂到 wq 等待队列上。当回调 ep_poll_callback 被触发并添加事件到 rdllist 后，会调用 wake_up 唤醒等待进程。

被唤醒后，epoll_wait 会遍历 rdllist，将每个 epitem 中的事件（events 掩码）和用户数据（data）拷贝到用户传入的 epoll_event 数组中。这里有一个关键优化：LT（水平触发）和 ET（边沿触发） 的实现差异。

• LT 模式：当事件就绪后，如果用户没有一次性读完数据，下次 epoll_wait 会再次返回该 fd 的事件（因为 rdllist 中的 epitem 不会被移除，除非用户处理完）。内核实现中，LT 模式下 epitem 在 ep_send_events 后不会被移出 rdllist，而是保留，除非检查到 fd 已无更多数据。

• ET 模式：epitem 在每次 epoll_wait 返回后会被从 rdllist 中移除，后续必须由新的事件触发才会重新加入。这意味着用户必须一次把数据读完，否则会丢失事件。ET 模式下，回调 ep_poll_callback 仅在 rdllist 中不存在该 epitem 时才加入，避免重复。

源码中，ep_send_events 函数负责将 rdllist 中的事件拷贝到用户空间，并依据模式决定是否将 epitem 放回 rdllist（LT 模式且事件未处理完则放回）。

五、并发与锁：epoll 如何保证线程安全

epoll 支持多线程并发调用 epoll_wait 和 epoll_ctl，内核通过 ep->mtx 互斥锁（或 ep->lock 自旋锁）保护红黑树和 rdllist 的访问。在 ep_poll_callback 中，由于可能被中断上下文调用（如网卡中断），必须使用自旋锁 ep->lock 来保护 rdllist 的插入操作，避免与线程上下文冲突。

另外，epoll_wait 在遍历 rdllist 拷贝事件时，会先将 rdllist 整体转移到临时链表（通过 list_splice_init），然后释放锁，再逐个处理。这减少了锁的持有时间，提高了并发性能。但这也带来了“饥饿”问题：如果事件产生速度极快，用户态处理不及，可能导致事件积压，但 epoll 通过 maxevents 参数限制单次返回数量，并在下次调用继续处理。

六、epoll 的局限与常见误区

尽管 epoll 强大，但并非万能。首先，epoll 只支持文件描述符（sockets、pipes、eventfd 等），不支持普通文件（如磁盘文件），因为普通文件总是可读写的，其 poll 操作会立即返回，无法触发回调。其次，ET 模式虽然高效，但要求用户必须循环读取直到 EAGAIN，编码复杂度增加，容易丢事件。

常见误区：认为 epoll 是异步 I/O（AIO）。实际上，epoll 仍是同步 I/O 模型，它只是通知你“可以读/写了”，但读写操作本身仍是阻塞的（除非设置 O_NONBLOCK）。真正的异步 I/O（如 Linux 的 io_uring）是由内核完成读写操作后通知用户。

七、源码中的性能优化细节

内核开发者对 epoll 做了大量微优化：

• 内存池：epitem 使用 kmem_cache 分配，避免频繁内存碎片。

• 批量处理：ep_scan_ready_list 一次性将多个就绪事件转移，减少锁竞争。

• 避免重复回调：在 ep_poll_callback 中，若 epitem 已在 rdllist 中，则不再重复加入（ET 模式），防止事件风暴。

• 超时精度：使用高精度定时器（hrtimer）支持毫秒级超时。

另外，epoll 还支持 EPOLLONESHOT 标志，让事件触发一次后自动从监控中移除，减少用户态再调用 epoll_ctl 删除的代价，适合多线程分发场景。

八、一次完整的 epoll_wait 流程追踪

为了直观，我们串联整个路径：

1. 用户调用 epoll_wait，内核进入 do_epoll_wait。

2. 检查 rdllist，若不为空则直接处理；若为空且超时>0，则当前进程调用 __add_wait_queue 加入 wq，并设置任务状态为 TASK_INTERRUPTIBLE。

3. 调用 schedule_hrtimeout 让出 CPU，进程休眠。

4. 网卡接收数据，设备驱动调用 sock 的 wake_up，最终触发 ep_poll_callback。

5. 回调中，获取 ep->lock，检查 epitem 是否已在 rdllist（ET模式检查），若未在则 list_add_tail 加入，并递增就绪计数。

6. 然后调用 wake_up(&ep->wq) 唤醒等待进程。

7. 进程被调度到，返回 epoll_wait 继续执行，调用 ep_send_events 将 rdllist 中的事件拷贝至用户数组。

8. 根据 LT/ET 模式处理 rdllist 中 epitem 的保留或移除。

9. 返回就绪事件个数，用户处理。

整个过程没有遍历所有 fd，只处理有事件发生的 fd，效率极高。

九、与 select/poll 的性能对比实测

假设 10000 个连接，只有 10 个活跃。select/poll 每次需要遍历 10000 个 fd，而 epoll 只需处理 10 个就绪事件。当连接数从 100 增长到 10000，select/poll 的耗时线性增长，epoll 几乎不变。这就是 epoll 被称为“高效”的根本原因。

但请注意，如果连接数很少（如几十个），且所有连接都活跃，select 的简单数组遍历可能比 epoll 的红黑树+回调开销更小。因此，epoll 适用于大规模、低活跃度的场景。

十、总结：epoll 的设计哲学

epoll 的成功在于它完美契合了“事件驱动”模型：将“主动查询”变为“被动回调”。内核中维护两大数据结构——红黑树负责管理，就绪链表负责通知，分工明确。通过回调机制，将 I/O 事件的处理从用户态 poll 循环中解放出来，让 CPU 只在真正有事件时才忙碌。

理解 epoll 源码，不仅有助于写出高性能的网络程序，更能深刻体会 Linux 内核的异步事件处理框架。当你下次使用 epoll 时，记住背后的红黑树、回调链、等待队列和锁机制，你就能从容应对各种疑难杂症，甚至自己实现轻量级的事件驱动库。

最后，推荐阅读 Linux 内核源码 fs/eventpoll.c（约 2000 行），配合本文的思路，相信你一定能彻底搞懂 epoll。高并发之路，从理解 epoll 开始。