讲讲IO复用三个函数的底层逻辑

在 Linux 网络编程中，IO 复用是高并发服务的核心基石 。我们熟知的 Nginx、Redis、日志服务、后端网关，全部都是基于 IO 复用实现高并发。很多同学只会用 select / poll / epoll 这三个函数，但完全不懂内核底层到底发生了什么，遇到性能问题就无从下手，面试时也只能背几句套话。

本文带你从零吃透三个 IO 复用函数的内核底层逻辑、工作机制、优缺点、本质区别，不仅让你会用，更让你懂为什么这么用，彻底解决这个面试高频难点。

---

一、先搞懂：什么是 IO 复用？

1.1 传统阻塞 IO 的痛点

在没有 IO 复用之前，最原始的 socket 编程采用的是阻塞 IO 模型：一个线程只能处理一个客户端连接。

当服务器调用 accept() 等待客户端连接，或者调用 recv() 等待客户端发送数据时，如果没有事件发生，整个线程就会被操作系统挂起阻塞，什么也干不了，只能傻等。

如果想要支持 1000 个同时在线的客户端，就必须创建 1000 个线程。这种模式的代价是毁灭性的：

• 内存开销巨大：每个线程默认栈空间是 8MB，1000 个线程就要消耗 8GB 内存
• CPU 调度开销爆炸：操作系统需要在 1000 个线程之间频繁切换上下文，大量 CPU 时间浪费在调度上，而不是处理业务
• 扩展性极差：当连接数达到上万时，服务器会直接被线程拖垮，完全无法响应

1.2 IO 复用的核心思想

IO 复用的出现，就是为了解决 "一个线程只能处理一个 IO" 的问题。

它的核心思想非常简单：用一个线程，同时监听成千上百个文件描述符（fd）。

用户线程不需要自己去挨个检查每个 fd 有没有数据，而是把所有要监听的 fd 交给内核。内核会帮我们监控所有 fd，哪个 fd 有数据可读、可写或者发生异常，就把哪个 fd 返回给用户。用户线程只需要处理这些已经就绪的 fd，不会浪费任何时间在等待上。

一句话总结：单线程管理海量 IO 事件。

1.3 三个 IO 复用函数的演进关系

Linux 上的 IO 复用技术经历了三代演进，每一代都解决了上一代的部分问题：

select（1983年，最老、低效）→ poll（1997年，小幅优化）→ epoll（2002年，Linux 2.6，最终版、高效）

二、select 底层逻辑（最原始的 IO 复用）

2.1 核心原理

select 是最早出现的 IO 复用函数，它的本质非常简单粗暴：用户态把所有要监听的 fd 打包传给内核，内核全程轮询遍历所有 fd，找出其中就绪的，再返回给用户态。

完整的执行流程分为 5 步：

1. 用户程序在用户态创建一个 fd_set 类型的变量，这是一个位图数组，每一位代表一个 fd 是否需要监听
2. 调用 select() 函数，把整个 fd_set 从用户态拷贝到内核态
3. 内核在内核态遍历所有传入的 fd，逐个检查是否有可读、可写或异常事件
4. 内核把就绪的 fd 对应的位标记为 1，再把整个 fd_set 拷贝回用户态
5. 用户程序再次遍历整个 fd_set，找出哪些位被标记了，然后处理对应的 fd

2.2 底层致命缺点（面试必背）

select 的设计从诞生之初就注定了它无法支撑高并发，有四个无法解决的致命问题：

1. 有硬编码的最大 fd 限制 ：fd_set 的大小由内核宏 FD_SETSIZE 定义，默认是 1024。这意味着 select 最多只能同时监听 1024 个 fd。想要修改这个限制，必须重新编译 Linux 内核，几乎没有可行性。
2. 每次调用都要全量内存拷贝 ：每次调用 select，都要把整个 fd_set 从用户态拷贝到内核态，调用结束后再拷贝回来。当 fd 数量很多时，这个拷贝开销会非常大。
3. 两次全量遍历：内核要遍历所有 fd 检查就绪状态，用户态拿到结果后还要再遍历一次所有 fd 找出就绪的。当有 10000 个 fd 但只有 1 个就绪时，9999 次遍历都是完全无效的。连接数越多，性能越差。
4. fd_set 会被内核修改 ：内核会直接修改传入的 fd_set 来标记就绪 fd。这意味着每次调用 select 之前，都必须重新初始化 fd_set，把所有要监听的 fd 再添加一遍，代码非常繁琐且容易出错。

2.3 适用场景

select 只适用于连接数极少（<100）、并发极低的场景。由于它的跨平台性最好（Windows、Linux、macOS 都支持），现在只在一些老旧的跨平台项目中还能见到，在 Linux 服务器开发中已经基本被淘汰。

---

三、poll 底层逻辑（select 的小升级版）

3.1 核心原理

poll 是 select 的改进版，它完全沿用了 select 的整体工作流程 ，只是把数据结构从位图 fd_set 改成了结构体数组 struct pollfd。

struct pollfd 的定义如下：

struct pollfd {
    int fd;         // 要监听的文件描述符
    short events;   // 用户要监听的事件（POLLIN/POLLOUT/POLLERR）
    short revents;  // 内核返回的就绪事件
};

poll 的执行流程和 select 几乎一模一样：

1. 用户程序在用户态填充一个 struct pollfd 数组，每个元素包含要监听的 fd 和对应的事件
2. 调用 poll() 函数，把整个数组从用户态拷贝到内核态
3. 内核遍历所有 pollfd 结构体，检查每个 fd 是否有就绪事件
4. 内核把就绪事件写入每个结构体的 revents 字段，再把整个数组拷贝回用户态
5. 用户程序遍历整个 pollfd 数组 ，检查每个元素的 revents 字段，处理就绪的 fd

3.2 相比 select 的优化

poll 只解决了 select 最明显的两个问题：

1. 突破了 1024 最大 fd 限制：由于使用了动态数组，理论上可以监听任意数量的 fd，只受限于系统内存。
2. 不需要每次重置监听集合 ：用户设置的事件存在 events 字段，内核返回的就绪事件存在 revents 字段，两者分离。内核不会修改 events 字段，所以不需要每次调用 poll 之前重新填充数组，代码更简洁。
3. 支持更多的事件类型：poll 支持比 select 更丰富的事件类型，比如优先级数据、挂起事件等。

3.3 依然存在的致命问题

poll 只是对 select 做了 "换皮"，核心的性能问题一个都没有解决：

• 仍然需要每次调用都把整个 fd 数组从用户态拷贝到内核态
• 内核仍然需要全量遍历所有 fd 来检查就绪状态
• 用户态仍然需要全量遍历整个数组 来找出就绪的 fd

当连接数达到上万时，poll 的性能会和 select 一样急剧下降。

结论：poll 只是比 select 稍微好用一点，但依然不适合高并发场景。

---

四、epoll 底层逻辑（Linux 终极 IO 复用）

epoll 是 Linux 独有的 IO 复用函数，它彻底抛弃了 select/poll 的轮询遍历模式，采用了事件驱动 + 回调机制，从根本上解决了 select/poll 的性能问题。这也是 Nginx、Redis 能支撑十万甚至百万并发的根本原因。

4.1 epoll 三个核心函数（对应底层三步）

epoll 的使用分为三个步骤，对应三个核心函数：

1. epoll_create(int size) ：创建一个 epoll 实例，在内核中开辟一块独立的空间，用来存放要监听的 fd 事件表。size 参数现在已经没有实际意义，只是为了兼容旧版本，传任意大于 0 的数即可。
2. epoll_ctl(int epfd, int op, int fd, struct epoll_event *event) ：向内核事件表中增加、删除或修改一个 fd 及其对应的监听事件。这是一个非阻塞函数，只是操作内核中的数据结构。
3. epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout) ：阻塞等待事件发生。它只会返回已经就绪的 fd，不会返回任何无效 fd。

4.2 底层核心机制（和 select/poll 最大区别）

epoll 对 select/poll 做了三个革命性的改进，这也是它性能碾压前两者的根本原因：

1. 内核维护常驻事件表，无需重复拷贝

select/poll 每次调用都要把所有 fd 重新拷贝一遍，因为内核不保存任何状态。

而 epoll 会在内核中维护一个常驻的事件表 。你只需要调用 epoll_ctl 把 fd 注册到内核事件表中一次，这个 fd 就会永久保存在内核里，直到你主动删除它。后续所有的 epoll_wait 调用都不需要再传递任何 fd 列表，完全避免了频繁的用户态和内核态之间的内存拷贝。

2. 事件回调机制，无需遍历所有 fd

这是 epoll 最核心的创新。

select/poll 采用的是轮询模式：内核每次都要傻乎乎地遍历所有 fd，检查有没有就绪事件。

而 epoll 采用的是事件驱动 + 回调模式：

• 当你把一个 fd 注册到 epoll 事件表时，内核会给这个 fd 注册一个回调函数
• 当这个 fd 有数据到来或者可写时，网卡会触发硬件中断，内核会调用这个回调函数
• 回调函数会自动把这个 fd 加入到一个就绪链表中

epoll_wait 要做的事情非常简单：只是检查这个就绪链表有没有元素。如果有，就把链表中的 fd 返回给用户；如果没有，就阻塞等待。

整个过程内核不需要遍历任何 fd，只有事件真正发生时才会处理，完全没有无效的 CPU 开销。

3. 只返回就绪 fd，用户态无需无效遍历

select/poll 会把所有 fd 都返回给用户，用户需要自己遍历找出哪些是就绪的。

而 epoll_wait 只会返回已经发生事件的 fd。如果有 10000 个 fd 但只有 10 个就绪，它就只返回这 10 个 fd。用户程序只需要遍历这 10 个 fd 进行处理即可，没有任何无效遍历。

4.3 epoll 两种工作模式

epoll 支持两种工作模式：水平触发（LT）和边缘触发（ET）。

LT 水平触发（默认模式）

只要 fd 上还有数据没有读完，epoll_wait 就会一直通知这个 fd 就绪。

这是 epoll 的默认模式，和 select/poll 的行为完全一致，兼容旧代码，新手友好，不容易出 bug。

ET 边缘触发（高性能模式）

只有当 fd 上的状态发生变化的一瞬间 ，epoll_wait 才会通知一次。即使 fd 上还有数据没有读完，也不会再重复通知。

ET 模式是 epoll 的高性能模式，它可以大大减少 epoll_wait 的调用次数，提高系统吞吐量。但它有一个硬性要求：必须搭配非阻塞 IO 使用 。因为如果使用阻塞 IO，当一次没有读完所有数据时，下一次就不会再收到通知，程序会一直阻塞在 recv() 上。

Nginx 就是使用的 ET 模式来实现极致的性能。

4.4 epoll 无敌的核心优势总结

• 无 fd 数量上限，理论上只受限于系统内存，单机可以轻松支持百万级并发
• 无需重复的用户态和内核态之间的内存拷贝
• 内核无轮询遍历，事件驱动，零浪费 CPU
• 用户态只处理就绪 fd，没有无效遍历
• 支持水平触发和边缘触发两种模式，灵活适配不同场景

---

五、一张表总结底层本质差异（核心精髓）

表格

特性	select	poll	epoll
核心机制	全量轮询	全量轮询	事件驱动 + 回调
最大 fd 数量	1024（硬编码）	无限制（受内存限制）	无限制（受内存限制）
内存拷贝	每次调用全量拷贝	每次调用全量拷贝	fd 只需注册一次，无重复拷贝
内核遍历方式	全量遍历所有 fd	全量遍历所有 fd	无需遍历，就绪事件主动回调
用户态遍历方式	全量遍历所有 fd	全量遍历所有 fd	只遍历就绪 fd
性能随连接数变化	连接数越多，性能越差	连接数越多，性能越差	性能几乎不受连接数影响
工作模式	仅水平触发	仅水平触发	水平触发 + 边缘触发
跨平台性	全平台支持	全平台支持	Linux 独有

---

六、面试满分总结（直接背）

1. select 的缺点 ：有 1024 个 fd 的硬编码限制；每次调用都需要全量拷贝 fd 集合；内核和用户态都需要全量遍历所有 fd；fd_set 会被内核修改，每次调用都需要重新初始化。性能随连接数增加急剧下降。
2. poll 的改进：使用结构体数组替代位图，突破了 1024 的 fd 数量限制；将用户设置的事件和内核返回的就绪事件分离，不需要每次重置监听集合。但核心的全量拷贝和全量遍历问题依然存在，高并发下性能依然很差。
3. epoll 的底层革新 ：采用事件驱动机制，内核维护常驻事件表，fd 只需注册一次，无需重复拷贝；fd 就绪时通过回调函数主动加入就绪链表，内核无需遍历；epoll_wait 只返回就绪 fd，用户态无需无效遍历。性能极高，支持百万级并发，是 Linux 下高并发服务的首选方案。

七、适用场景最终对比

• select：老旧跨平台项目、连接数极少（<100）的简单场景，几乎淘汰
• poll：中等连接数、对性能要求不高的嵌入式设备或简单服务
• epoll：Linux 服务器高并发场景，Nginx、Redis、网关、后端网络服务的主流选择

---

写在最后

IO 复用是 Linux 网络编程的核心，也是后端开发工程师必须掌握的基本功。很多人觉得 epoll 很神秘，其实它的底层原理非常简单：就是把 select/poll 那种 "用户轮询" 的低效模式，改成了 "内核事件通知" 的高效模式。