一站式讲清IO多路复用(轻松愉悦版)-平芜编程栈

文章目录

引言
Select：早期的探索
Poll：Select 的链表版
Epoll：Linux 的杀手锏
Java和Go有什么需要了解的小知识？
总结

引言

作为一个 Java 和 Go 后端开发者，深刻理解 IO 多路复用是掌握高性能网络编程（如 Netty）的基石。

简单来说，IO 多路复用是一种允许单个线程同时监视多个文件描述符（FD, File Descriptor）的技术。一旦某个 FD 就绪（读/写就绪），内核会通知应用程序进行处理。

如果没有它，处理 10,000 个并发连接可能需要 10,000 个线程（资源消耗巨大）或者使用非阻塞 IO 轮询（空转烧 CPU）。

下面我将从底层原理对比select、poll和epoll进行说明。

Select：早期的探索

select是最早期的 IO 多路复用实现。

工作原理：
1. 用户进程将需要监视的fd_set（一个位图 bitmap）拷贝到内核空间。
2. 内核遍历一遍所有的 socket，如果有数据，就标记为可读/可写。
3. 内核将fd_set拷贝回用户空间。
4. 用户进程再次遍历fd_set，找到被标记的 socket 进行处理。
缺点：
- 性能开销大：每次调用都要把 FD 集合在用户态和内核态之间拷贝；内核和用户态都需要遍历整个 FD 集合（时间复杂度O ( n ) O(n)O(n)）。
- 连接数限制：默认限制为1024个连接（由FD_SETSIZE宏定义，虽然可以改，但效率会急剧下降）。

总的原因就是每次调用都需要拷贝fd_set，而且需要进行线性循环。来个形象的比喻就是服务员需要挨个问客人你点好单了吗，不用想都是效率十分低下。

这张图展示了select低效的原因：每次调用都需要在用户态和内核态之间拷贝整个文件描述符集合 (fd_set)，并且内核和用户程序都需要进行 O(n) 的线性遍历。

Poll：Select 的链表版

poll和select本质区别不大。

工作原理：
- 它使用pollfd结构体的链表（或数组）而不是 bitmap 来传递 FD。
改进点：
- 没有最大连接数限制（受限于系统内存和文件描述符限制）。
缺点：
- 性能依然是瓶颈：它和select一样，内核需要线性遍历所有 FD 来检查状态，用户态也需要遍历所有 FD 来查找谁就绪了。随着连接数增加，性能线性下降

最大的性能瓶颈并没有解决，所以这个我们并不需要太了解。

Epoll：Linux 的杀手锏

epoll是为了解决 C10K 问题而生的，它是目前 Linux 下高性能网络编程的核心。

核心设计（三个函数）：
1. epoll_create：在内核创建一个 epoll 对象（内部结构是一棵红黑树和一个双向链表）。
2. epoll_ctl：向红黑树中添加、删除或修改感兴趣的 FD。这也是O ( log ⁡ n ) O(\log n)O(logn)的效率，比线性扫描快得多。
3. epoll_wait：等待事件。
工作原理（Callback 机制）：
- epoll不再轮询。它为每个 FD 注册一个回调函数。
- 当网卡接收到数据，中断程序会调用回调函数，将该 FD 添加到就绪链表（Ready List）中。
- epoll_wait实际上只是在检查这个就绪链表是否为空。
- 用户进程只需要处理就绪链表中的 FD，不需要遍历所有连接。
优点：
- 效率极高：时间复杂度为O ( 1 ) O(1)O(1)（严格来说是O ( k ) O(k)O(k)，k 为活跃连接数）。性能不会随总连接数增加而下降，只与“活跃”连接数有关。
- 内存拷贝少：使用了 mmap（内存映射）技术或高效的内存管理，减少了复制开销（注：现代实现主要是避免了像 select 那样每次调用都重复传入整个 FD 集合）。
两种触发模式：
- LT (Level Triggered - 水平触发)：默认模式。只要缓冲区还有数据，内核就会一直通知你。
- ET (Edge Triggered - 边缘触发)：高速模式。只有数据状态发生变化（从无到有）时通知一次。如果你不读完，内核不会再通知，这要求程序必须一次性把数据读完。Go 和 Nginx 使用的是 ET 模式的变种或思想来追求极致性能。

不好理解？来个比喻：服务员再也不用去挨个问是否点好单，而是由大堂经理将需要订单的顾客名单给服务员去通知后厨

这张图展示了epoll高效的原因：它使用红黑树来管理所有的文件描述符（只需注册一次），并采用事件驱动的机制。当网络设备有数据到达时，通过回调函数直接将就绪的 FD 加入到“就绪链表”中，应用程序只需要处理这个链表即可，无需遍历所有连接

Java和Go有什么需要了解的小知识？

作为后端开发，了解这些对你理解语言底层至关重要：

Java (NIO / Netty):
- Java 的java.nio.channels.Selector是一个抽象层。
- 在 Linux 上，JDK 会自动映射到底层的epoll。
- Netty的核心 EventLoop 也就是在一个线程中不断轮询这个Selector（即epoll_wait），实现了高性能的 Reactor 模型。
Go (Goroutine & Netpoller):
- Go 的网络编程看起来是同步阻塞的（比如conn.Read()），但底层完全是异步非阻塞的。
- Go Runtime 包含了一个Netpoller（网络轮询器）。
- 在 Linux 下，Netpoller 封装了epoll。当你调用conn.Read()且没有数据时，Go 调度器会将该 Goroutine 挂起（Gopark），并将 FD 注册到epoll中。
- 当epoll通知数据就绪，Go 调度器再唤醒该 Goroutine。

这就是 Go 高并发的核心秘密：用同步的代码逻辑，享受了 epoll 的异步性能。

总结

这就是全部内容，下面是一个小结表格。

特性	Select	Poll	Epoll
底层数据结构	Bitmap (数组)	链表 / 数组	红黑树(存储FD) +双向链表(存储就绪FD)
时间复杂度	O ( n ) O(n)O(n)	O ( n ) O(n)O(n)	O ( 1 ) O(1)O(1)(与活跃数有关)
最大连接数	1024 (默认)	无限制	无限制 (受系统内存限制)
IO效率	随连接数增加而显著下降	随连接数增加而显著下降	不随总连接数线性下降
数据拷贝	每次调用都需要拷贝全部 FD	每次调用都需要拷贝全部 FD	FD 仅在注册时拷贝一次