昨天参加了一场技术面试，面试官问到了一个经典问题："能不能讲讲 epoll 的原理，以及它为什么比 select 和 poll 更高效？"这个问题我之前准备过，但现场还是有点紧张，回答得不够流畅。今天复盘一下，一方面是总结经验教训，另一方面也借机把 epoll 的原理梳理清楚，分享出来，希望对大家有所帮助。
背景：从 select 和 poll 说起
在讲 epoll 之前，先简单回顾一下它的"前辈"------select 和 poll，这样更容易理解 epoll 的设计动机。
-
select：这是最早的 I/O 多路复用机制。核心思想是通过一个文件描述符集合（fd_set），让内核帮忙监控这些文件描述符是否有事件（比如可读、可写）。但它有几个问题： 1. 文件描述符数量受限（通常是 1024）。 2. 每次调用select都需要把 fd_set 从用户态拷贝到内核态，效率不高。 3. 内核返回时，只告诉你"有事件发生"，但没说具体是哪些 fd，用户需要逐个遍历检查，时间复杂度是 O(n)。 -
poll：相比select，poll用链表替代了 fd_set，突破了文件描述符数量限制。但它本质上还是要用户把所有 fd 传给内核，内核检查后再返回事件集合，用户依然需要遍历，效率瓶颈没根本解决。
面试官问到这里时，我稍微卡了一下，因为我没立刻说出两者的复杂度对比。事后想想，应该直接点明：select 和 poll 的时间复杂度都是 O(n)，n 是监控的文件描述符数量。这也是 epoll 要优化的核心问题。
epoll 的登场
epoll 是 Linux 2.6 内核引入的高效 I/O 多路复用机制，号称是为处理大规模并发连接设计的"杀手锏"。它解决了 select 和 poll 的两大痛点： 1. 重复传递 fd 的开销 ：每次调用 select 或 poll 都需要把所有 fd 传给内核，而 epoll 只需注册一次，之后通过事件通知机制工作。 2. 事件查找的效率 ：epoll 直接返回有事件的 fd，用户无需遍历整个集合。
epoll 的三大核心函数
epoll 的工作离不开三个关键 API，我在面试时大致讲了这些，但没展开细节，这里补全一下：
epoll_create(int size)
创建一个 epoll 实例，返回一个文件描述符（epoll_fd）。这个实例本质上是内核中的一个数据结构，用于管理所有被监控的 fd。参数 size 是早期版本用来提示内核预分配空间的，现在基本被忽略，内核会动态调整。
epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
用来操作 epoll 实例，比如添加（EPOLL_CTL_ADD）、修改（EPOLL_CTL_MOD）或删除（EPOLL_CTL_DEL）某个 fd 的监控。
epfd是epoll_create返回的描述符。 -op指定操作类型。 -fd是要监控的文件描述符。 -event是个结构体，定义了关心的事件类型（比如 EPOLLIN 表示可读，EPOLLOUT 表示可写）。
epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)
阻塞等待事件发生，返回就绪的 fd 数量。
events是个数组，内核会把就绪的事件填进去。 -maxevents是数组的最大容量。 -timeout是超时时间（-1 表示永久阻塞，0 表示非阻塞）。
面试时我提到这三个函数时，面试官点点头，但追问了一句："那内核是怎么实现这个高效通知的？"当时我只模糊说了"红黑树和事件回调"，没讲透，下面详细补上。
epoll 的内核实现原理
epoll 的高效离不开内核的两大"法宝"：红黑树 和就绪队列。
- 红黑树管理 fd
当你调用 epoll_ctl 添加 fd 时，内核会把这些 fd 存进一个红黑树。红黑树是一种自平衡二叉搜索树，插入、删除、查找的时间复杂度都是 O(log n)。相比 select 和 poll 每次都把 fd 集合全量拷贝，epoll 的红黑树只需要维护一次，之后增删改查都很高效。
- 事件回调机制
每个被监控的 fd 都会绑定一个回调函数。当 fd 上有事件发生（比如 socket 可读），内核通过中断触发这个回调，回调函数会把对应的 fd 加入一个就绪链表（ready list）。
调用 epoll_wait 时，内核直接从这个就绪链表中取出已就绪的 fd，返回给用户。这样用户拿到的事件集合就是"精确打击"，无需再遍历检查，时间复杂度降到 O(1)。
- 边缘触发 vs 水平触发
epoll支持两种工作模式： - LT（水平触发，默认） ：只要 fd 还有数据未处理，就会一直通知。类似select的行为，适合简单场景。 - ET（边缘触发） ：只在 fd 状态变化时通知一次（比如从无数据到有数据），效率更高，但需要用户自己确保数据处理完整。
面试时我没主动提到这点，事后觉得是个遗漏，因为 ET 模式是 epoll 高性能的一个体现。
为什么 epoll 更高效？
总结一下，epoll 比 select 和 poll 高效的原因： - 数据结构优化 ：用红黑树管理 fd，复杂度从 O(n) 降到 O(log n)。 - 事件通知机制 ：通过回调和就绪队列，避免了用户态的全量遍历，复杂度从 O(n) 降到 O(1)。 - 内存拷贝减少：fd 只需注册一次，不用每次调用都传整个集合。
面试官听到这里时，问了个场景题："假设有 10 万个连接，但只有 10 个活跃，epoll 和 select 的表现差别有多大？"我当时回答得不够量化，复盘后可以这样说： - select 需要检查 10 万个 fd，复杂度 O(10 万)。 - epoll 只返回 10 个活跃 fd，复杂度 O(1)。 差别是指数级的，尤其在高并发场景下。
复盘心得
这次面试让我意识到，讲技术原理时不能只停留在表面，面试官往往更关注你对底层实现的理解。回答 epoll 时，我应该更有条理地从数据结构（红黑树）、事件机制（回调+就绪队列）和模式（LT/ET）三个层次展开，同时结合复杂度分析和场景对比。如果下次再遇到类似问题，我会尽量把这些点讲全、讲透。