select、poll 和 epoll 有什么区别？｜阿里巴巴算法面经解析

60 秒回答模板

select、poll、epoll 都是 I/O 多路复用机制，目的是让一个线程同时等待多个 fd 的可读、可写或异常事件，避免为每个连接创建一个阻塞线程。select 使用 fd_set 位图表达关注集合，每次调用都要把集合从用户态拷到内核态，返回后还要线性扫描所有 fd，并且通常受 FD_SETSIZE 数量限制。poll 用 pollfd 数组替代位图，突破了 select 固定 fd 编号上限的问题，事件表达也更清晰，但每次调用仍然要传入完整数组，内核和用户态仍要遍历所有 fd。epoll 则把“注册关注的 fd”和“等待就绪事件”拆开，epoll_ctl 维护内核中的关注集合，常用红黑树管理 fd，事件就绪后进入就绪队列，epoll_wait 主要返回已经就绪的事件，避免每次重复拷贝和全量扫描。epoll 还支持水平触发和边缘触发，更适合事件驱动服务器。但 epoll 并不是所有场景都一定最快：fd 数量很少、活跃比例很高、一次性短任务或跨平台代码中，select 或 poll 的简单性可能更有优势。

考点 多路复用目的

主线 select 机制

易错点 只回答 epoll 比 select、poll 快，却…

深入解析

多路复用目的

I/O 多路复用的核心目的不是让一次系统调用真正并行执行多个 I/O，而是让一个执行流能够同时等待多个文件描述符的事件。典型场景是网络服务器维护大量 socket，线程不应阻塞在某一个连接的 read 或 write 上，否则其他连接即使已经就绪也无法及时处理。select、poll 和 epoll 都把“等待事件”交给内核，由内核判断哪些 fd 可读、可写或异常，再把结果返回给应用层，应用层随后用非阻塞 I/O 做真正的数据读写。

select 机制

select 的接口使用 fd_set 位图表示读、写、异常三类关注集合，调用时还要传入最大 fd 加一的 nfds。它的问题主要来自两个方面：一是 fd_set 通常有 FD_SETSIZE 限制，很多系统默认是 1024，虽然可通过编译配置改变，但并不优雅；二是每次调用都需要把 fd_set 从用户态拷贝到内核态，返回后 fd_set 会被内核改写，应用还需要重新准备集合，并线性扫描从 0 到 nfds 的范围才能找出真正就绪的 fd。

poll 机制

poll 用 pollfd 数组替代 fd_set，每个元素包含 fd、关注事件 events 和返回事件 revents。它相比 select 的改进是没有固定的位图大小限制，能自然表达更大的 fd 值，也避免了根据最大 fd 编号扫描一大片空洞区域。不过 poll 的根本模型仍然是“每次把完整关注列表交给内核，再把结果带回来”，内核需要遍历数组检查状态，用户态也通常要遍历数组找 revents，因此当连接数很大但活跃连接很少时，成本仍然随总连接数线性增长。

epoll 机制

epoll 把关注集合的维护从等待调用中拆出去：应用先通过 epoll_create 创建实例，再用 epoll_ctl 添加、修改或删除 fd，最后用 epoll_wait 等待就绪事件。内核中会长期保存关注关系，常见解释是用红黑树维护已注册 fd，便于增删改查；当设备或 socket 状态变化时，内核回调把就绪事件放入就绪队列。这样 epoll_wait 不需要每次提交完整 fd 集合，返回时也主要拿到已经就绪的事件，更符合高并发事件驱动服务器的工作方式。

成本对比

select 和 poll 的主要成本是重复拷贝和重复遍历：每次等待都要把关注集合传入内核，并且无论是否只有一个连接活跃，都可能扫描全部关注 fd。epoll 的优势在于关注集合常驻内核，注册成本发生在 epoll_ctl 阶段，等待阶段关注就绪队列，避免频繁全量提交和全量扫描。对于十万连接但每次只有少量连接活跃的服务，epoll 的事件返回模型明显更合适；但如果只有几十个 fd，系统调用和数据结构维护的差别可能并不构成瓶颈。

触发模式

epoll 支持水平触发和边缘触发。水平触发是默认模式，只要 fd 仍处于就绪状态，epoll_wait 后续还会继续返回它，语义接近 select、poll，使用更简单，不容易漏事件。边缘触发只在状态从未就绪变为就绪时通知一次，减少重复通知，适合高性能事件循环，但通常必须配合非阻塞 fd，并在收到事件后循环读到 EAGAIN 或写到不能继续为止，否则缓冲区里残留的数据可能不会再次触发通知，造成连接卡住。

工程选择

工程上选择哪一种机制要看规模、平台和复杂度。select 可移植性较好，适合小规模 fd、简单工具或教学场景；poll 接口比 select 更自然，适合中等规模、fd 编号较大或希望避免 fd_set 限制的场景；epoll 是 Linux 下高并发网络服务的常用选择，适合大量长连接和事件驱动架构。回答时要避免把 epoll 绝对化，因为当活跃连接比例很高、fd 数量很小、代码跨平台或逻辑瓶颈不在等待事件时，epoll 的收益会下降。

易错点

只回答 epoll 比 select、poll 快，却说不出拷贝、遍历和就绪队列的差异。
把 I/O 多路复用理解成同时执行多个读写操作，忽略它本质上只是等待多个 fd 的就绪事件。
认为 poll 已经彻底解决 select 的性能问题，没有指出 poll 仍然需要全量数组遍历。
混淆水平触发和边缘触发，尤其是不知道边缘触发通常要配合非阻塞 I/O 使用。
把 epoll 描述成所有场景下都最优，忽略少量 fd、跨平台和高活跃比例场景下的实际取舍。
只记住 select 有 1024 限制，却没有说明 fd_set 位图、nfds 扫描和集合被改写这些细节。

面试官追问

为什么 select 有 fd 数量限制？

因为 select 的关注集合通常由 fd_set 位图表示，位图大小由 FD_SETSIZE 决定，很多环境默认值是 1024。即使可以通过重新编译等方式调整，也会影响接口使用和兼容性，因此它不适合直接管理大量连接。

poll 为什么没有完全解决 select 的性能问题？

poll 用数组替代 fd_set，解决了固定大小位图和 fd 编号限制的问题，但每次调用仍然要把整个 pollfd 数组交给内核。内核需要遍历所有元素检查事件，应用返回后也要遍历 revents，因此成本仍与总 fd 数量相关。

epoll 为什么适合高并发长连接？

高并发长连接常见特点是连接总数很大，但某一时刻真正活跃的连接较少。epoll 把注册集合长期保存在内核中，并通过就绪队列返回活跃事件，避免每次都提交和扫描全部连接，所以更适合这种稀疏活跃模型。

水平触发和边缘触发有什么使用差异？

水平触发下，只要 fd 仍可读或可写，后续 epoll_wait 仍可能返回这个事件，编程容错性较好。边缘触发只在状态变化时通知一次，应用必须使用非阻塞 I/O 并尽量读写到 EAGAIN，否则可能遗漏缓冲区中尚未处理的数据。

epoll 一定比 select 和 poll 快吗？

不一定。epoll 的优势主要体现在大量 fd 且活跃比例较低的场景。如果 fd 很少，select 或 poll 的线性扫描成本很低；如果几乎所有连接都活跃，epoll 返回事件数量也很大，优势会变小，还会引入更复杂的状态维护。

epoll 中红黑树和就绪队列分别解决什么问题？

红黑树常用于管理已经注册到 epoll 实例上的 fd，使添加、删除和修改关注事件更高效；就绪队列用于保存已经发生事件的 fd，让 epoll_wait 可以直接取出就绪项，而不是每次从头扫描全部注册 fd。