Linux epoll 模型详解
epoll（event poll）是 Linux 内核为了解决大规模并发连接而引入的一种 I/O 多路复用机制，它旨在替代传统的 select 和 poll 模型,极大地提高了在处理成千上万个并发连接时的性能。
为什么需要 epoll？（对比 select/poll）
在 select 和 poll 模型中,存在两个核心痛点：
- 线性扫描：每次调用都需要将所有监控的文件描述符（FD）从用户态拷贝到内核态，并且在事件触发后，内核需要遍历整个 FD 集合来找出哪个 FD 准备好了，时间复杂度为 O(n)。
- 重复拷贝：每次调用都要重新传递整个 FD 集合,造成了巨大的内存拷贝开销。
epoll 通过以下方式解决了这些问题：
- 内核维护状态：在内核中维护一个红黑树，记录所有需要监控的 FD,无需每次调用都拷贝。
- 事件驱动：当 FD 状态改变时，内核通过回调机制将其放入一个“就绪队列”中，
epoll_wait只需要检查该队列，时间复杂度为 O(1)。
epoll 的核心工作机制
epoll 的实现主要依赖于三个核心系统调用：
1 epoll_create
- 功能：创建一个 epoll 实例。
- 原理：在内核中创建一块内存区域，包含一棵 红黑树（RB-Tree） 和一个 就绪链表（Ready List）。
2 epoll_ctl
- 功能：控制 epoll 实例，用于添加、修改或删除需要监控的 FD。
- 原理：将 FD 插入到红黑树中，红黑树保证了在添加、删除和查找 FD 时具有高效的性能（时间复杂度为 $O(log n)$）。
3 epoll_wait
- 功能：等待 I/O 事件的发生。
- 原理：进程调用此函数后会进入睡眠状态，直到就绪链表中出现 FD，此时内核将就绪链表中的事件拷贝到用户空间,并唤醒进程。
epoll 的触发模式
epoll 提供了两种触发模式,这是其最关键的特性之一：
1 水平触发 (Level Triggered, LT)
- 行为：只要 FD 处于就绪状态（例如缓冲区有数据），
epoll_wait就会不断地通知应用程序。 - 特点：比较安全，类似于
poll
epoll_wait依然会提醒。 - 适用场景：大多数通用场景。
2 边缘触发 (Edge Triggered, ET)
- 行为：只有在 FD 的状态发生 变化（从无数据变为有数据）时，
epoll_wait才会通知一次。 - 特点：效率更高，减少了重复唤醒，但要求应用程序必须 一次性将数据读完（通常需要配合 非阻塞 I/O 和
while循环读取）,否则会导致数据遗留在缓冲区而无法再次触发通知。 - 适用场景：高性能网络服务器（如 Nginx, Redis）。
epoll 的优势总结
- 海量连接支持：由于不依赖线性扫描，支持 10 万甚至百万级并发连接。
- 极低的 CPU 消耗：仅在有事件发生时才处理就绪列表,避免了无效的轮询。
- 内存效率高：FD 集合在内核中持久化,避免了用户态与内核态之间频繁的重复拷贝。
核心对比表
| 特性 | select | poll | epoll |
|---|---|---|---|
| 底层数据结构 | 数组/位图 | 链表 | 红黑树 + 就绪链表 |
| 时间复杂度 | $O(n)$ | $O(n)$ | $O(1)$ |
| FD 数量限制 | 有限制 (1024) | 无限制 | 无限制 |
| 拷贝开销 | 每次调用全量拷贝 | 每次调用全量拷贝 | 仅在 ctl 时拷贝一次 |
| 触发模式 | 仅水平触发 | 仅水平触发 | 支持 LT 和 ET |
首发原创文章，作者：世雄 - 原生数据库架构专家，如若转载，请注明出处：https://idctop.com/article/490653.html
