如何理解I/O多路复用

一、为什么要使用I/O多路复用

• 最基础的 TCP Socket 编程使用的是阻塞 I/O 模型:每次进行 I/O 操作（如读写数据），调用的线程会被阻塞，直到操作完成为止。在这种模型下，一个线程只能处理一个客户端的请求，也就是“一对一通信”。如果需要同时处理多个客户端连接，就必须为每个连接创建一个独立的线程或进程。当客户端数量很少时，这种方式是可行的。但如果有成千上万个客户端（如 C10K 问题，1万个并发客户端连接），线程/进程的调度和资源占用（如内存）会成为瓶颈。

• 在传统的多线程/多进程模型中：每个客户端连接对应一个独立的线程或进程。当有数据读写时，线程阻塞在对应的 Socket 上，直到数据准备好。但线程/进程上下文切换开销大，会造成性能下降，且每个线程/进程都有一定的内存开销（如栈内存、线程控制块等）。当客户端数增加到 1 万（C10K 问题）时，内存和调度开销变得不可接受。

因此，为了减少线程/进程的开销，同时在一个线程内处理多个客户端，出现了I/O 多路复用技术。

二、什么是I/O多路复用

核心思想：通过一个线程同时管理多个 Socket（文件描述符），在一个线程内同时检测多个连接的状态（如是否可读/可写），从而实现高效的并发处理。

在 Linux 中，常见的 I/O 多路复用技术包括 select、poll 和 epoll。

三、 select 和 poll 的工作原理

select 和 poll 是最早的 I/O 多路复用 API，但它们有明显的性能缺陷。

原理：

1. 用户态到内核态拷贝：

   • 程序需要将所有需要监控的 Socket 集合从用户态拷贝到内核态。

   • 例如，如果你有 10000 个客户端连接，你需要传递包含 10000 个 Socket 的集合到内核。

2. 内核轮询检测：

   • 内核会遍历整个 Socket 集合，检测每个 Socket 的状态（如是否可读/可写）。

   • 如果某些 Socket 有事件（如数据到达或可写），内核会设置对应的状态。

3. 内核态到用户态拷贝：

   • 内核将检测结果（整个 Socket 集合）拷贝回用户态，用户程序需要再次遍历整个集合，找到可用的 Socket。

缺点：

• 线性复杂度：

  • select 和 poll 使用的内部数据结构是线性结构，即每次需要检测所有 Socket 集合，时间复杂度为 O(n)。

  • 当 Socket 数量变大（如 1 万个客户端连接）时，遍历和拷贝的开销非常高。

• 数据拷贝开销：

  • 每次调用都需要将 Socket 集合从用户态拷贝到内核态，然后再从内核态拷贝回用户态。

四、epoll 的工作原理

epoll 是 Linux 提供的一种高效的 I/O 多路复用技术，它解决了 select 和 poll 的性能问题，专为高并发设计。

epoll 的改进：

1. 高效的红黑树管理：

   • epoll 在内核中使用红黑树存储待监控的 Socket 集合。

   • 优势：

     • 插入、删除、修改 Socket 的时间复杂度为 O(log n)。

     • 相比于 select/poll 每次都拷贝整个 Socket 集合，epoll 只需在第一次时添加到红黑树即可，无需重复拷贝，红黑树会一直维护这些描述符，直到显式地移除它们。

2. 事件驱动机制：

   • epoll 使用事件驱动机制，即内核会监听事件的发生。

   • 链表记录就绪事件：

     • 内核会将发生事件的 Socket（如有数据到达或可写的 Socket）加入到一个链表。

     • 应用程序只需要处理这个链表中的 Socket，无需遍历整个集合。

3. 只传递有事件的 Socket：

   • 在事件发生时，epoll 只将有事件的 Socket 信息返回给用户程序，而不是返回整个 Socket 集合。

   • 优势：减少了不必要的轮询和拷贝，极大提高了性能。

epoll支持两种事件触发模式，分别是边缘触发和水平触发：

水平触发（Level Triggered, LT）：

• 默认模式，和 select/poll 一样。

• 只要 Socket 上有数据，内核会一直通知程序，直到数据被完全处理。

边缘触发（Edge Triggered, ET）：

• 高效模式，仅在数据状态发生变化时（如从无到有数据）通知程序。

• 需要程序一次性处理完所有数据，否则可能导致事件丢失。

• 效率更高，但更难使用。

五、select、poll 和 epoll 的对比