【笔记】聊聊更强大的 epoll
在上次聊完 poll 之后，我们今天来聊聊更强大的 epoll。它是 Linux 系统上处理高并发网络 I/O 的“终极武器”，尤其适合构建需要同时维护数万甚至数十万连接的大型服务器。
为了让您对这三者有个快速的整体印象，我们先通过一个表格来对比它们的核心特性。
| 特性 | select | poll | epoll |
|---|---|---|---|
| 最大连接数 | 有限制 (通常 1024)〔1〕〔5〕 | 无限制（基于数组）〔1〕〔2〕 | 无限制（基于内核事件表）〔7〕 |
| 工作效率 | 线性扫描所有 fd，O(n)〔1〕〔3〕 | 线性扫描所有 fd，O(n)〔1〕〔6〕 | 事件驱动，只通知就绪的 fd，O(1)〔5〕〔7〕 |
| 内存开销 | 每次调用需拷贝整个 fd_set〔1〕〔4〕 | 每次调用需拷贝整个 pollfd 数组〔1〕〔7〕 | 仅拷贝一次，内核内部维护事件表〔4〕〔7〕 |
| 事件触发模式 | 仅支持水平触发 (LT)〔1〕〔8〕 | 仅支持水平触发 (LT)〔1〕〔8〕 | 支持水平触发 (LT) 和边缘触发 (ET)〔5〕〔8〕 |
| 编程复杂度 | 中等 | 中等 | 稍高（需管理多个函数） |
| 可移植性 | 跨平台支持好〔5〕〔10〕 | 多数 Unix 系统支持〔9〕 | Linux 特有〔5〕〔10〕 |
🔧 Epoll 的核心机制与 API
你可以把 epoll 想象成一个智能管家。它不再像 select/poll 那样每次都要你提供一份完整的待检查名单（fdset 或 pollfd 数组），而是让你先创建一个“任务看板”（epoll 实例），然后通过“任务便签”（epollctl）将需要监视的连接和事件注册到这个看板上。
一旦有事件发生，管家只会把那些已经完成的任务便签（就绪的事件）整理成一个清单给你（epoll_wait），你无需再逐个询问。这种机制彻底解决了 select/poll 随着连接数增加性能线性下降的问题。
Epoll 的操作主要通过三个系统调用完成：
-
int epoll_create(int size)：创建 epoll 实例
这个调用会在内核中创建一个 epoll 实例，并返回一个文件描述符（epfd）来代表这个实例。参数 size 在现代 Linux 中已无实际限制，仅作为提示，可忽略。 -
int epollctl(int epfd, int op, int fd, struct epollevent event)：管理事件注册*
这是你向“任务看板”上添加、修改或删除“任务便签”的方法。
· epfd：epoll 实例的描述符。
· op：操作类型，如 EPOLLCTLADD（添加）、EPOLLCTLMOD（修改）、EPOLLCTLDEL（删除）。
· fd：要监视的文件描述符（如 socket）。
· event：指向 epoll_event 结构的指针，指定了感兴趣的事件（如 EPOLLIN-可读）和可能的用户数据。 -
int epollwait(int epfd, struct epollevent events, int maxevents, int timeout)：等待事件*
这是等待事件发生的调用，也是效率的关键。
· epfd：epoll 实例。
· events：一个由调用者分配的数组，用于输出就绪的事件。这是与 select/poll 的关键区别：内核只填充有事件发生的元素。
· maxevents：指定 events 数组的大小，一次调用最多能返回的事件数。
· timeout：超时时间。
⚡ Epoll 的高效性源自何处？
Epoll 的高性能主要得益于其设计上的两大优势：
-
避免了不必要的遍历
select/poll 每次调用时，内核都必须线性扫描全部的文件描述符，以检查其状态。当有 10 万个连接但只有 10 个活跃时，这种扫描是巨大的浪费〔7〕。而 epoll 采用回调机制。当某个文件描述符就绪时，内核会直接将其放入一个就绪链表〔8〕。epoll_wait 只需检查这个链表是否为空即可，时间复杂度是 O(1)，与文件描述符总数无关〔7〕。 -
避免了内存的重复拷贝
select/poll 每次调用都需要将整个描述符集合从用户空间拷贝到内核空间，调用返回时可能还要再次拷贝〔1〕〔4〕。Epoll 通过 epollctl 提前将监控信息注册到内核维护的一个事件表中（通常使用红黑树实现），之后调用 epollwait 时，只需拷贝少量就绪的事件信息，大大减少了开销〔4〕〔7〕〔8〕。
🔄 水平触发与边缘触发
这是 epoll 独有的重要特性，也是其强大和需要小心使用的地方。
· 水平触发（LT，Level-Triggered）：这是 epoll 的默认模式，行为与 select/poll 一致。只要文件描述符处于就绪状态（例如，socket 的读缓冲区中有数据可读），每次调用 epoll_wait 都会报告该事件〔8〕。好处是：编程更简单，即使你一次没有读完所有数据，下次调用时 epoll 还会提醒你。
· 边缘触发（ET，Edge-Triggered）：只有当文件描述符状态发生变化时（例如，从不可读变为可读），epoll_wait 才会报告一次该事件〔8〕。好处是：可以减少事件被触发的次数，在某些场景下性能更高。但要求是：当事件被通知后，应用程序必须一次性将数据读完或写完，直到系统调用（如 read/write）返回 EAGAIN 或 EWOULDBLOCK 错误，否则可能再也无法收到这个事件的通知〔5〕。使用 ET 模式时，文件描述符通常需要设置为非阻塞模式。
💡 如何选择？
综合来看，选择哪种 I/O 多路复用机制可以参考以下准则：
· 追求极致性能和高并发，且平台为 Linux：毫无疑问，选择 epoll〔5〕〔6〕。
· 需要跨平台兼容：考虑 poll〔6〕〔9〕，或者根据平台特性封装不同的实现（如 Linux 用 epoll，BSD 用 kqueue）。
· 连接数很少（如 < 1024），且对可移植性要求极高：select 仍然是一个简单可行的选择〔10〕。
💎 总结
总而言之，epoll 通过其事件驱动、回调通知和内核内维护事件表的机制，完美解决了 select 和 poll 在连接数大增时性能骤降的问题，成为构建现代 Linux 高性能网络服务的基石。
希望这次的讲解能让你对 epoll 有一个清晰的理解。如果你想深入了解 epoll 的 ET/LT 模式的具体代码示例，或者对 BSD 的 kqueue 也感兴趣，我们可以继续探讨。
注：本文关于 epoll 机制的解析主要基于 Linux 环境，其他平台（如 Windows）有不同的高性能 I/O 模型。