在网络编程和高并发服务器开发中，I/O 多路复用是绕不开的核心话题。无论是准备跳槽面试，还是日常排查线上服务瓶颈，select、poll、epoll 这三者之间的区别都是高频考点。本文将从底层数据结构出发，逐步拆解它们的工作机制，并给出清晰的性能对比和选型建议。
为什么需要 I/O 多路复用？
假设你有一个 TCP 服务器，需要同时处理上千个客户端连接。最朴素的做法是每个连接开一个线程，但线程上下文切换和内存开销会迅速拖垮系统。另一种做法是用非阻塞 I/O 轮询所有连接，但大量系统调用同样低效。
I/O 多路复用的思路是：用一次系统调用，同时监视多个文件描述符（fd），当其中某些 fd 就绪时再通知应用程序。这样既避免了多线程开销，也避免了盲目轮询。
select、poll、epoll 就是 Linux 下三种主要的实现方式，它们的目标一致，但底层设计决定了性能上限截然不同。
select 的底层实现
select 的函数原型如下：
int select(int nfds, fd_set *readfds, fd_set *writefds,
fd_set *exceptfds, struct timeval *timeout);
fd_set 本质上是一个位图（bitmap），每一位对应一个 fd。在 Linux 内核中，它通常被定义为 __kernel_fd_set，内部是一个 unsigned long 数组，长度固定为 FD_SETSIZE / __NFDBITS，而 FD_SETSIZE 默认为 1024。
调用 select 时，内核会做以下几件事：
- 将用户空间的
fd_set拷贝到内核空间。 - 遍历所有被监视的 fd，调用每个 fd 对应的
poll方法，检查是否有事件就绪。 - 如果没有就绪，当前进程会进入睡眠，直到某个 fd 就绪或超时。
- 唤醒后，再次遍历所有 fd，将就绪的 fd 标记在
fd_set中，然后拷贝回用户空间。
核心问题：
- fd 数量限制：受
FD_SETSIZE限制，默认最多 1024 个。 - 每次调用都要拷贝：用户态和内核态之间的
fd_set拷贝无法避免。 - 每次调用都要线性扫描：无论有多少 fd 就绪，内核和用户态都需要遍历整个集合。
- 返回后需要再次遍历：用户程序拿到
fd_set后，还得自己轮询哪些 fd 被置位了。
poll 的底层实现
poll 对 select 做了一定改进：
int poll(struct pollfd *fds, nfds_t nfds, int timeout);
struct pollfd {
int fd;
short events;
short revents;
};
poll 不再使用位图，而是使用一个 pollfd 数组。每个元素包含 fd、关注的事件和返回的事件。这样：
- 没有 1024 的数量限制（只受系统 fd 上限约束）。
- 不需要每次重新构造 fd 集合，因为
events和revents是分离的。
但 poll 依然没有解决根本问题：每次调用仍需将整个 pollfd 数组拷贝到内核，内核仍需线性扫描所有 fd，返回后用户仍需遍历数组查找就绪项。当 fd 数量达到数万时，性能会急剧下降。
epoll 的底层实现
epoll 是 Linux 2.6 引入的机制，它从设计上彻底改变了游戏规则。epoll 由三个系统调用组成：
int epoll_create(int size);
int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event);
int epoll_wait(int epfd, struct epoll_event *events,
int maxevents, int timeout);
核心数据结构
epoll 在内核中维护了两个关键结构：
- 红黑树（rbtree）：用于存储所有被监视的 fd。
epoll_ctl的增删改操作都在红黑树上进行，时间复杂度为 O(log n)。 - 就绪链表（ready list）：一个双向链表，当某个 fd 就绪时，内核通过回调函数将其加入就绪链表。
工作流程
epoll_create创建一个eventpoll对象，包含红黑树和就绪链表。epoll_ctl将 fd 插入红黑树，并向内核注册回调函数。当该 fd 对应的设备就绪时，回调函数会被触发，将 fd 加入就绪链表。epoll_wait直接检查就绪链表是否为空。如果不为空，就将链表中的节点拷贝到用户空间的事件数组中，然后返回就绪数量。
关键优化
- 无需重复拷贝：fd 信息在
epoll_ctl时一次性注册到内核，epoll_wait不需要再次传入所有 fd。 - 无需线性扫描：就绪事件由回调函数主动加入链表，
epoll_wait只需读取链表，复杂度为 O(1)（就绪 fd 数量）。 - 无数量限制：只受系统最大 fd 数限制。
LT 与 ET 模式
epoll 支持两种触发模式：
- 水平触发（LT，Level Triggered）：默认模式。只要 fd 上还有数据可读，每次
epoll_wait都会通知。编程简单，不易丢事件。 - 边缘触发（ET，Edge Triggered）：只在状态变化时通知一次。必须配合非阻塞 I/O 循环读取直到
EAGAIN，否则会丢数据。效率更高，但编程复杂度也更高。
性能差异对比
| 维度 | select | poll | epoll |
|---|---|---|---|
| 底层结构 | 位图 | pollfd 数组 | 红黑树 + 就绪链表 |
| fd 上限 | 1024（FD_SETSIZE） | 无硬限制 | 无硬限制 |
| 每次调用拷贝 | 整个 fd_set | 整个 pollfd 数组 | 仅就绪事件 |
| 内核扫描方式 | 线性扫描全部 fd | 线性扫描全部 fd | 回调通知，O(1) |
| 用户态查找就绪 fd | 遍历全部 fd | 遍历全部 fd | 直接读取返回数组 |
| 时间复杂度 | O(n) | O(n) | O(1)（就绪数） |
| 触发模式 | LT | LT | LT / ET |
结论：
- 当连接数较少（比如几十到几百）且活跃比例较高时，
select和poll的性能与epoll差距不大。 - 当连接数达到数千甚至数万，且活跃连接比例较低时，
epoll的优势呈指数级放大。 select还有 1024 的硬限制，在现代高并发场景下基本被淘汰。
面试常见追问
1. epoll 为什么用红黑树而不是哈希表？
红黑树在增删改查上都是 O(log n)，且能保证有序遍历。哈希表虽然平均 O(1)，但需要处理冲突，且在内核中动态扩容复杂。对于 fd 数量通常不会极端巨大的场景，红黑树是更稳妥的选择。
2. epoll_wait 返回后，用户需要遍历所有 fd 吗？
不需要。epoll_wait 返回的 events 数组只包含就绪的 fd，用户直接遍历这个数组即可，长度就是返回值。
3. ET 模式下为什么必须用非阻塞 I/O？
因为 ET 只通知一次，如果使用阻塞 I/O 循环读取，最后一次 read 会阻塞住整个线程，导致其他 fd 无法处理。非阻塞 I/O 配合 EAGAIN 才能安全地读完所有数据。
4. select 的 fd_set 拷贝具体发生在哪里？
发生在 select 系统调用进入内核时（copy_from_user）和返回用户空间时（copy_to_user）。每次调用都会发生，无法避免。
选型建议
- 新项目：直接使用
epoll，配合 LT 模式降低编程复杂度。 - 需要跨平台：
select和poll在 POSIX 系统上通用，epoll是 Linux 专属。如果必须跨平台，可以考虑 libevent、libuv 等封装库。 - 极高性能场景：
epoll+ ET + 非阻塞 I/O，但需要仔细处理边界条件。 - 面试回答：重点说清楚三者的数据结构和扫描方式差异，再结合具体场景给出选型理由，基本就能拿到高分。
理解 select、poll、epoll 的底层差异，不仅是为了应付面试，更是为了在真实系统中做出正确的架构决策。希望本文能帮你把这块知识彻底串起来。
未经允许不得转载：任鹏个人博客 » Linux 面试题：select、poll、epoll 的底层实现与性能差异
