理解Linux的select、poll 和 epoll：从原理到应用场景

I/O 多路复用并不是什么新东西，select 早在 1983 年就出现了，poll 在 1997 年，epoll 是 2002 年的产物。面试题总爱问“多路复用多厉害？”其实它就是把轮询的锅甩给了操作系统，而操作系统不过是用 CPU 指令帮你完成事件监听罢了。厉害？能让程序员少操点心才算厉害！

1. select 的机制

select 是最早的多路复用技术，通过固定大小的 fd_set 来管理文件描述符：

1. 用户线程调用 select，将文件描述符加入 fd_set。
2. 内核遍历 fd_set，检查哪些文件描述符有事件。
3. 有事件发生时，标记 fd_set 并唤醒用户线程。

以下是 select 的详细工作流程图：

缺点：

• 文件描述符数量限制：fd_set 是固定大小（通常为 1024 个），限制了高并发场景。
• 效率低下：每次调用需要重构 fd_set，并且内核需要遍历所有文件描述符，性能开销大。

2. poll 的改进

poll 引入了动态数组，解决了 fd_set 固定大小的问题。每个文件描述符通过 pollfd 结构存储，支持任意数量的文件描述符。

缺点：

• 内核仍需轮询所有文件描述符，性能瓶颈依然存在。

3. epoll 的革命

epoll 通过事件驱动彻底改变了多路复用的性能：

1. 用户注册文件描述符到 epoll 实例，内核只在状态变化时通知用户线程。
2. 内核使用高效的红黑树和就绪队列，避免轮询开销。

优点：

• 性能不受文件描述符数量影响。
• 支持高效的动态管理和边缘触发。

4. 应用场景(举例)

4.1 Netty

• 使用的机制：Netty 是一个高性能的异步网络框架，在 Linux 中使用 epoll 实现 I/O 多路复用。
• 工作方式：
  • Netty 的 EpollEventLoop 使用 epoll 监听多个网络连接的状态，并通过事件驱动模型在事件就绪时通知线程池处理 I/O。
  • 在非 Linux 平台，Netty 会退回到 select 或 poll。

4.2 Redis

• 使用的机制：Redis 是一个单线程的高性能键值存储，使用 I/O 多路复用机制管理所有客户端连接。
• 默认机制：
  • 在 Linux 上使用 epoll，在其他平台上使用 select 或 poll。
• 工作方式：
  • Redis 通过 epoll_wait 获取就绪的客户端连接，避免阻塞在单个连接的 I/O 操作上，从而实现高并发处理能力。