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

在 Linux 网络编程中IO 复用是高并发服务的核心基石。我们熟知的 Nginx、Redis、日志服务、后端网关全部都是基于 IO 复用实现高并发。很多同学只会用select / poll / epoll这三个函数但完全不懂内核底层到底发生了什么遇到性能问题就无从下手面试时也只能背几句套话。本文带你从零吃透三个 IO 复用函数的内核底层逻辑、工作机制、优缺点、本质区别不仅让你会用更让你懂为什么这么用彻底解决这个面试高频难点。一、先搞懂什么是 IO 复用1.1 传统阻塞 IO 的痛点在没有 IO 复用之前最原始的 socket 编程采用的是阻塞 IO 模型一个线程只能处理一个客户端连接。当服务器调用accept()等待客户端连接或者调用recv()等待客户端发送数据时如果没有事件发生整个线程就会被操作系统挂起阻塞什么也干不了只能傻等。如果想要支持 1000 个同时在线的客户端就必须创建 1000 个线程。这种模式的代价是毁灭性的内存开销巨大每个线程默认栈空间是 8MB1000 个线程就要消耗 8GB 内存CPU 调度开销爆炸操作系统需要在 1000 个线程之间频繁切换上下文大量 CPU 时间浪费在调度上而不是处理业务扩展性极差当连接数达到上万时服务器会直接被线程拖垮完全无法响应1.2 IO 复用的核心思想IO 复用的出现就是为了解决 一个线程只能处理一个 IO 的问题。它的核心思想非常简单用一个线程同时监听成千上百个文件描述符fd。用户线程不需要自己去挨个检查每个 fd 有没有数据而是把所有要监听的 fd 交给内核。内核会帮我们监控所有 fd哪个 fd 有数据可读、可写或者发生异常就把哪个 fd 返回给用户。用户线程只需要处理这些已经就绪的 fd不会浪费任何时间在等待上。一句话总结单线程管理海量 IO 事件。1.3 三个 IO 复用函数的演进关系Linux 上的 IO 复用技术经历了三代演进每一代都解决了上一代的部分问题select1983年最老、低效→ poll1997年小幅优化→ epoll2002年Linux 2.6最终版、高效二、select 底层逻辑最原始的 IO 复用2.1 核心原理select 是最早出现的 IO 复用函数它的本质非常简单粗暴用户态把所有要监听的 fd 打包传给内核内核全程轮询遍历所有 fd找出其中就绪的再返回给用户态。完整的执行流程分为 5 步用户程序在用户态创建一个fd_set类型的变量这是一个位图数组每一位代表一个 fd 是否需要监听调用select()函数把整个fd_set从用户态拷贝到内核态内核在内核态遍历所有传入的 fd逐个检查是否有可读、可写或异常事件内核把就绪的 fd 对应的位标记为 1再把整个fd_set拷贝回用户态用户程序再次遍历整个fd_set找出哪些位被标记了然后处理对应的 fd2.2 底层致命缺点面试必背select 的设计从诞生之初就注定了它无法支撑高并发有四个无法解决的致命问题有硬编码的最大 fd 限制fd_set的大小由内核宏FD_SETSIZE定义默认是 1024。这意味着 select 最多只能同时监听 1024 个 fd。想要修改这个限制必须重新编译 Linux 内核几乎没有可行性。每次调用都要全量内存拷贝每次调用 select都要把整个fd_set从用户态拷贝到内核态调用结束后再拷贝回来。当 fd 数量很多时这个拷贝开销会非常大。两次全量遍历内核要遍历所有 fd 检查就绪状态用户态拿到结果后还要再遍历一次所有 fd 找出就绪的。当有 10000 个 fd 但只有 1 个就绪时9999 次遍历都是完全无效的。连接数越多性能越差。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 几乎一模一样用户程序在用户态填充一个struct pollfd数组每个元素包含要监听的 fd 和对应的事件调用poll()函数把整个数组从用户态拷贝到内核态内核遍历所有pollfd结构体检查每个 fd 是否有就绪事件内核把就绪事件写入每个结构体的revents字段再把整个数组拷贝回用户态用户程序遍历整个pollfd数组检查每个元素的revents字段处理就绪的 fd3.2 相比 select 的优化poll 只解决了 select 最明显的两个问题突破了 1024 最大 fd 限制由于使用了动态数组理论上可以监听任意数量的 fd只受限于系统内存。不需要每次重置监听集合用户设置的事件存在events字段内核返回的就绪事件存在revents字段两者分离。内核不会修改events字段所以不需要每次调用 poll 之前重新填充数组代码更简洁。支持更多的事件类型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 的使用分为三个步骤对应三个核心函数epoll_create(int size)创建一个 epoll 实例在内核中开辟一块独立的空间用来存放要监听的 fd 事件表。size参数现在已经没有实际意义只是为了兼容旧版本传任意大于 0 的数即可。epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)向内核事件表中增加、删除或修改一个 fd 及其对应的监听事件。这是一个非阻塞函数只是操作内核中的数据结构。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没有无效遍历支持水平触发和边缘触发两种模式灵活适配不同场景五、一张表总结底层本质差异核心精髓表格特性selectpollepoll核心机制全量轮询全量轮询事件驱动 回调最大 fd 数量1024硬编码无限制受内存限制无限制受内存限制内存拷贝每次调用全量拷贝每次调用全量拷贝fd 只需注册一次无重复拷贝内核遍历方式全量遍历所有 fd全量遍历所有 fd无需遍历就绪事件主动回调用户态遍历方式全量遍历所有 fd全量遍历所有 fd只遍历就绪 fd性能随连接数变化连接数越多性能越差连接数越多性能越差性能几乎不受连接数影响工作模式仅水平触发仅水平触发水平触发 边缘触发跨平台性全平台支持全平台支持Linux 独有六、面试满分总结直接背select 的缺点有 1024 个 fd 的硬编码限制每次调用都需要全量拷贝 fd 集合内核和用户态都需要全量遍历所有 fdfd_set会被内核修改每次调用都需要重新初始化。性能随连接数增加急剧下降。poll 的改进使用结构体数组替代位图突破了 1024 的 fd 数量限制将用户设置的事件和内核返回的就绪事件分离不需要每次重置监听集合。但核心的全量拷贝和全量遍历问题依然存在高并发下性能依然很差。epoll 的底层革新采用事件驱动机制内核维护常驻事件表fd 只需注册一次无需重复拷贝fd 就绪时通过回调函数主动加入就绪链表内核无需遍历epoll_wait只返回就绪 fd用户态无需无效遍历。性能极高支持百万级并发是 Linux 下高并发服务的首选方案。七、适用场景最终对比select老旧跨平台项目、连接数极少100的简单场景几乎淘汰poll中等连接数、对性能要求不高的嵌入式设备或简单服务epollLinux 服务器高并发场景Nginx、Redis、网关、后端网络服务的主流选择写在最后IO 复用是 Linux 网络编程的核心也是后端开发工程师必须掌握的基本功。很多人觉得 epoll 很神秘其实它的底层原理非常简单就是把 select/poll 那种 用户轮询 的低效模式改成了 内核事件通知 的高效模式。