企业官网建设流程全解析

CS-Notes：Socket 五大 I/O 模型与 select、poll、epoll 多路复用机制详解

【免费下载链接】CS-Notes:books: 技术面试必备基础知识、Leetcode、计算机操作系统、计算机网络、系统设计项目地址: https://gitcode.com/GitHub_Trending/cs/CS-Notes

本文基于 CS-Notes 仓库中的 notes/Socket.md 展开，系统讲解 Unix 套接字上的五种 I/O 模型（阻塞、非阻塞、I/O 复用、信号驱动、异步）各自的工作原理与 CPU 利用率差异，并深入剖析 select、poll、epoll 三个 I/O 多路复用系统调用的接口、参数、示例代码、LT/ET 工作模式及适用场景。读完后，你将能够说清同步与异步 I/O 的本质区别，理解 epoll 为什么能支撑海量长连接，并在不同平台与连接规模下正确选型。

一、输入操作的两个阶段与五大 I/O 模型

一个输入操作通常包括两个阶段：

• 等待数据准备好；
• 从内核向进程复制数据。

对于一个套接字上的输入操作，第一步通常涉及等待数据从网络中到达。当所等待数据到达时，它被复制到内核中的某个缓冲区；第二步就是把数据从内核缓冲区复制到应用进程缓冲区。

Unix 定义了五种 I/O 模型：

• 阻塞式 I/O（Blocking I/O）
• 非阻塞式 I/O（Non-Blocking I/O）
• I/O 复用（select 和 poll）
• 信号驱动式 I/O（SIGIO）
• 异步 I/O（AIO）

下文中以recvfrom()作为典型系统调用，它用于接收 Socket 传来的数据，并复制到应用进程的缓冲区 buf 中：

ssize_t recvfrom(int sockfd, void *buf, size_t len, int flags, struct sockaddr *src_addr, socklen_t *addrlen);

1. 阻塞式 I/O

应用进程被阻塞，直到数据从内核缓冲区复制到应用进程缓冲区中才返回。

应该注意到，在阻塞的过程中，其它应用进程还可以执行，因此阻塞不意味着整个操作系统都被阻塞。因为其它应用进程还可以执行，所以不消耗 CPU 时间，这种模型的 CPU 利用率会比较高。

阻塞式 I/O 是最直观的模型：一个线程处理一个连接。它的代价在于连接数与线程数的线性关系——这正是后文 I/O 复用要解决的问题。

2. 非阻塞式 I/O

应用进程执行系统调用之后，内核返回一个错误码，应用进程可以继续执行，但需要不断地执行系统调用来获知 I/O 是否完成，这种方式称为轮询（polling）。

由于 CPU 要处理更多的系统调用，因此这种模型的 CPU 利用率比较低。

非阻塞 I/O 把"等待数据就绪"阶段的阻塞消掉了，但代价是用密集的轮询换取了进程的可并发性。在连接数很多、且数据到达稀疏的场景下，纯轮询的开销会迅速放大。

3. I/O 复用

使用 select 或者 poll 等待数据，并且可以等待多个套接字中的任何一个变为可读。这一过程会被阻塞，当某一个套接字可读时返回，之后再使用 recvfrom 把数据从内核复制到进程中。

它可以让单个进程具有处理多个 I/O 事件的能力，又被称为 Event Driven I/O，即事件驱动 I/O。

如果一个 Web 服务器没有 I/O 复用，那么每一个 Socket 连接都需要创建一个线程去处理。如果同时有几万个连接，那么就需要创建相同数量的线程。相比于多进程和多线程技术，I/O 复用不需要进程线程创建和切换的开销，系统开销更小。

在 CS-Notes 的其他文档中也能看到这一模型的价值：notes/系统设计基础.md 指出，"使用 IO 多路复用等方式，系统在等待一个 IO 操作完成的这段时间内不需要被阻塞，可以去处理其它请求。通过将这个等待时间利用起来，使得 CPU 利用率大大提高"。这正是 I/O 复用成为高并发服务器基石的原因。

4. 信号驱动 I/O

应用进程使用 sigaction 系统调用，内核立即返回，应用进程可以继续执行，也就是说等待数据阶段应用进程是非阻塞的。内核在数据到达时向应用进程发送 SIGIO 信号，应用进程收到之后在信号处理程序中调用 recvfrom 将数据从内核复制到应用进程中。

相比于非阻塞式 I/O 的轮询方式，信号驱动 I/O 的 CPU 利用率更高——数据就绪由内核"推"给进程，进程不再需要反复"拉"。

5. 异步 I/O

应用进程执行 aio_read 系统调用会立即返回，应用进程可以继续执行，不会被阻塞，内核会在所有操作完成之后向应用进程发送信号。

异步 I/O 与信号驱动 I/O 的区别在于：异步 I/O 的信号是通知应用进程 I/O 完成，而信号驱动 I/O 的信号是通知应用进程可以开始 I/O。

6. 五大 I/O 模型比较

• 同步 I/O：将数据从内核缓冲区复制到应用进程缓冲区的阶段（第二阶段），应用进程会阻塞。
• 异步 I/O：第二阶段应用进程不会阻塞。

同步 I/O 包括阻塞式 I/O、非阻塞式 I/O、I/O 复用和信号驱动 I/O，它们的主要区别在第一个阶段；其中非阻塞式 I/O、信号驱动 I/O 和异步 I/O 在第一阶段不会阻塞。

从表格可以看出，判断同步与异步的关键不在于第一阶段，而在于第二阶段的数据拷贝是否让应用进程阻塞。

二、I/O 多路复用：select、poll 与 epoll

select/poll/epoll 都是 I/O 多路复用的具体实现，select 出现的最早，之后是 poll，再是 epoll。

1. select

int select(int n, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);

select 允许应用程序监视一组文件描述符，等待一个或者多个描述符成为就绪状态，从而完成 I/O 操作。

• fd_set 使用数组实现，数组大小使用 FD_SETSIZE 定义，所以只能监听少于 FD_SETSIZE 数量的描述符。有三种类型的描述符集合：readset、writeset、exceptset，分别对应读、写、异常条件的描述符集合。
• timeout 为超时参数，调用 select 会一直阻塞直到有描述符的事件到达或者等待的时间超过 timeout。
• 成功调用返回结果大于 0，出错返回结果为 -1，超时返回结果为 0。

使用示例：

fd_set fd_in, fd_out; struct timeval tv; // Reset the sets FD_ZERO( &fd_in ); FD_ZERO( &fd_out ); // Monitor sock1 for input events FD_SET( sock1, &fd_in ); // Monitor sock2 for output events FD_SET( sock2, &fd_out ); // Find out which socket has the largest numeric value as select requires it int largest_sock = sock1 > sock2 ? sock1 : sock2; // Wait up to 10 seconds tv.tv_sec = 10; tv.tv_usec = 0; // Call the select int ret = select( largest_sock + 1, &fd_in, &fd_out, NULL, &tv ); // Check if select actually succeed if ( ret == -1 ) // report error and abort else if ( ret == 0 ) // timeout; no event detected else { if ( FD_ISSET( sock1, &fd_in ) ) // input event on sock1 if ( FD_ISSET( sock2, &fd_out ) ) // output event on sock2 }

几个细节值得注意：

• 第一个参数 n 是所有描述符集合中最大 fd 值加 1，因为内核是按[0, n)区间线性扫描位图的；
• select 返回后会修改 fd_set（只保留就绪的描述符），因此下一轮循环前必须重新FD_ZERO+FD_SET初始化集合，这也是后文"select 会修改描述符"说法的由来；
• 每次调用都需要把整个 fd 集合从用户态拷贝到内核态，这是 select/poll 在性能上的共同瓶颈。

2. poll

int poll(struct pollfd *fds, unsigned int nfds, int timeout);

poll 的功能与 select 类似，也是等待一组描述符中的一个成为就绪状态。poll 中的描述符是 pollfd 类型的数组，pollfd 的定义如下：

struct pollfd { int fd; /* file descriptor */ short events; /* requested events */ short revents; /* returned events */ };

使用示例：

// The structure for two events struct pollfd fds[2]; // Monitor sock1 for input fds[0].fd = sock1; fds[0].events = POLLIN; // Monitor sock2 for output fds[1].fd = sock2; fds[1].events = POLLOUT; // Wait 10 seconds int ret = poll( &fds, 2, 10000 ); // Check if poll actually succeed if ( ret == -1 ) // report error and abort else if ( ret == 0 ) // timeout; no event detected else { // If we detect the event, zero it out so we can reuse the structure if ( fds[0].revents & POLLIN ) fds[0].revents = 0; // input event on sock1 if ( fds[1].revents & POLLOUT ) fds[1].revents = 0; // output event on sock2 }

相比 select 的位图集合，pollfd 用显式的fd+events+revents三元组表达事件，revents返回后通常清零以便复用同一数组。

3. select 与 poll 的比较

功能方面：select 和 poll 的功能基本相同，不过在一些实现细节上有所不同：

• select 会修改描述符，而 poll 不会；
• select 的描述符类型使用数组实现，FD_SETSIZE 大小默认为 1024，因此默认只能监听少于 1024 个描述符。如果要监听更多描述符的话，需要修改 FD_SETSIZE 之后重新编译；而 poll 没有描述符数量的限制；
• poll 提供了更多的事件类型，并且对描述符的重复利用上比 select 高；
• 如果一个线程对某个描述符调用了 select 或者 poll，另一个线程关闭了该描述符，会导致调用结果不确定。

速度方面：select 和 poll 速度都比较慢，每次调用都需要将全部描述符从应用进程缓冲区复制到内核缓冲区。

可移植性方面：几乎所有的系统都支持 select，但是只有比较新的系统支持 poll。

4. epoll

int epoll_create(int size); int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event); int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout);

epoll_ctl() 用于向内核注册新的描述符或者是改变某个文件描述符的状态。已注册的描述符在内核中会被维护在一棵红黑树上，通过回调函数内核会将 I/O 准备好的描述符加入到一个链表中管理，进程调用 epoll_wait() 便可以得到事件完成的描述符。

从上面的描述可以看出，epoll 只需要将描述符从进程缓冲区向内核缓冲区拷贝一次，并且进程不需要通过轮询来获得事件完成的描述符。

epoll 仅适用于 Linux OS。

epoll 比 select 和 poll 更加灵活而且没有描述符数量限制。

epoll 对多线程编程更友好，一个线程调用了 epoll_wait() 另一个线程关闭了同一个描述符也不会产生像 select 和 poll 的不确定情况。

使用示例：

// Create the epoll descriptor. Only one is needed per app, and is used to monitor all sockets. // The function argument is ignored (it was not before, but now it is), so put your favorite number here int pollingfd = epoll_create( 0xCAFE ); if ( pollingfd < 0 ) // report error // Initialize the epoll structure in case more members are added in future struct epoll_event ev = { 0 }; // Associate the connection class instance with the event. You can associate anything // you want, epoll does not use this information. We store a connection class pointer, pConnection1 ev.data.ptr = pConnection1; // Monitor for input, and do not automatically rearm the descriptor after the event ev.events = EPOLLIN | EPOLLONESHOT; // Add the descriptor into the monitoring list. We can do it even if another thread is // waiting in epoll_wait - the descriptor will be properly added if ( epoll_ctl( epollfd, EPOLL_CTL_ADD, pConnection1->getSocket(), &ev ) != 0 ) // report error // Wait for up to 20 events (assuming we have added maybe 200 sockets before that it may happen) struct epoll_event pevents[ 20 ]; // Wait for 10 seconds, and retrieve less than 20 epoll_event and store them into epoll_event array int ready = epoll_wait( pollingfd, pevents, 20, 10000 ); // Check if epoll actually succeed if ( ret == -1 ) // report error and abort else if ( ret == 0 ) // timeout; no event detected else { // Check if any events detected for ( int i = 0; i < ready; i++ ) { if ( pevents[i].events & EPOLLIN ) { // Get back our connection pointer Connection * c = (Connection*) pevents[i].data.ptr; c->handleReadEvent(); } } }

（示例代码沿用原文写法，其中epollfd/ret为原文中的笔误形式，实际使用时应统一为上文的pollingfd与返回值变量ready。）

epoll 相比 select/poll 的关键优势可以归纳为三点：

1. 注册一次、长期有效：描述符通过 epoll_ctl 注册进内核红黑树后，epoll_wait 只返回就绪的描述符，无需每轮全量传递集合；
2. 就绪链表机制：内核通过回调把就绪描述符挂到就绪链表上，epoll_wait 的时间复杂度与就绪数量相关，而不是与注册总量线性相关；
3. ev.data反向指针：可以在事件上挂任意用户数据（如连接对象指针），epoll_wait 返回后直接拿回业务上下文，免去"fd 到连接"的映射查找。

5. 工作模式：LT 与 ET

epoll 的描述符事件有两种触发模式：LT（level trigger）和 ET（edge trigger）。

LT 模式（默认）：当 epoll_wait() 检测到描述符事件到达时，将此事件通知进程，进程可以不立即处理该事件，下次调用 epoll_wait() 会再次通知进程。LT 是默认的一种模式，并且同时支持 Blocking 和 No-Blocking。

ET 模式：和 LT 模式不同的是，通知之后进程必须立即处理事件，下次再调用 epoll_wait() 时不会再得到事件到达的通知。很大程度上减少了 epoll 事件被重复触发的次数，因此效率要比 LT 模式高。ET 只支持 No-Blocking，以避免由于一个文件句柄的阻塞读/阻塞写操作把处理多个文件描述符的任务饿死。

实践含义：使用 ET 时，读事件通知后应循环读直到返回 EAGAIN，写操作同理；若图省事或需要与阻塞 fd 混用，选择默认的 LT 即可。

6. 应用场景

很容易产生一种错觉认为只要用 epoll 就可以了，select 和 poll 都已经过时了，其实它们都有各自的使用场景。

select 应用场景：select 的 timeout 参数精度为微秒，而 poll 和 epoll 为毫秒，因此 select 更加适用于实时性要求比较高的场景，比如核反应堆的控制。select 可移植性更好，几乎被所有主流平台所支持。

poll 应用场景：poll 没有最大描述符数量的限制，如果平台支持并且对实时性要求不高，应该使用 poll 而不是 select。

epoll 应用场景：

• 只需要运行在 Linux 平台上，有大量的描述符需要同时轮询，并且这些连接最好是长连接；
• 需要同时监控小于 1000 个描述符，就没有必要使用 epoll，因为这个应用场景下并不能体现 epoll 的优势；
• 需要监控的描述符状态变化多，而且都是非常短暂的，也没有必要使用 epoll。因为 epoll 中的所有描述符都存储在内核中，造成每次需要对描述符的状态改变都需要通过 epoll_ctl() 进行系统调用，频繁系统调用降低效率。并且 epoll 的描述符存储在内核，不容易调试。

三、CS-Notes 仓库中的呼应：I/O 复用的其他技术形态

notes/Socket.md 讲的是 Unix/Linux 内核层面的 I/O 复用，而 CS-Notes 仓库中还有几处与它相互印证的内容，可以作为延伸阅读。

Java NIO 的选择器（Selector）

notes/Java IO.md 的"NIO"章节用 Java 语言重新实现了同一套 I/O 复用模型：Channel（通道）+ Buffer（缓冲区）+ Selector（选择器）。其事件循环模式与 select/poll/epoll 的单线程事件驱动模型一一对应：

while (true) { int num = selector.select(); Set<SelectionKey> keys = selector.selectedKeys(); Iterator<SelectionKey> keyIterator = keys.iterator(); while (keyIterator.hasNext()) { SelectionKey key = keyIterator.next(); if (key.isAcceptable()) { // ... } else if (key.isReadable()) { // ... } keyIterator.remove(); } }

值得注意的是，Java NIO 要求通道必须配置为非阻塞模式（ssChannel.configureBlocking(false)），否则使用选择器就没有任何意义——这与前文"epoll 的 ET 模式只支持 No-Blocking"的原理完全一致：多路复用的前提正是单个事件不会被阻塞住整个事件循环。文档还强调"只有套接字 Channel 才能配置为非阻塞，而 FileChannel 不能，为 FileChannel 配置非阻塞也没有意义"，这体现了不同 fd 类型的语义差异。

对比来看：C 语言直接使用 select/poll/epoll 系统调用，而 Java NIO 通过 Selector API 屏蔽了底层多路复用实现，注册事件时用SelectionKey.OP_READ | SelectionKey.OP_WRITE这样的位域组合，与 pollfd 的events位图是同一思想。

Redis 的 Reactor 事件处理器

notes/Redis.md 提到："Redis 基于 Reactor 模式开发了自己的网络事件处理器，使用 I/O 多路复用程序来同时监听多个套接字，并将到达的事件传送给文件事件分派器，分派器会根据套接字产生的事件类型调用相应的事件处理器。"

这正是本文"事件驱动 I/O"在工程上的典型落地：单线程 + I/O 多路复用 + 事件分派器，构成了 Redis 高吞吐网络层的骨架。

参考资料

• Stevens W R, Fenner B, Rudoff A M. UNIX Network Programming. Addison-Wesley Professional, 2004.
• Linux man pages: select(2)、poll(2)、epoll_ctl(2)、epoll_wait(2)。
• CS-Notes 仓库相关文档：notes/Socket.md、notes/Java IO.md、notes/Redis.md、notes/系统设计基础.md。

【免费下载链接】CS-Notes:books: 技术面试必备基础知识、Leetcode、计算机操作系统、计算机网络、系统设计项目地址: https://gitcode.com/GitHub_Trending/cs/CS-Notes