【Linux】高级IO

原创已于 2025-04-18 21:10:00 修改 · 885 阅读

19 ·

CC 4.0 BY-SA版权

文章标签：

#linux #运维 #服务器 #c++ #bash

于 2025-03-06 21:32:12 首次发布

Linux 专栏收录该内容

11 篇文章

订阅专栏

一、IO模型概念

1）五种 I/O 模型

在计算机系统中，I/O（输入/输出）是指计算机与外部设备（如磁盘、网络、键盘等）之间的交互过程。操作系统使用不同的 I/O 模型来实现应用程序与硬件设备之间的数据交换。根据应用程序与操作系统、设备之间的交互方式，I/O 模型可以分为五种主要类型：阻塞 I/O、非阻塞 I/O、I/O 多路复用、信号驱动 I/O 和 异步 I/O。

I/O的本质是等+拷贝

1. 阻塞 I/O（Blocking I/O）

定义：在阻塞 I/O 模型中，当应用程序发起 I/O 操作（如读取文件或从网络中接收数据）时，操作系统会一直等待直到操作完成，应用程序会被阻塞，直到操作完成并返回结果。
特点：
- 同步：应用程序发起的 I/O 操作会阻塞直到完成。
- 简单：编程模型简单，通常是默认的 I/O 模式。
- 效率低：如果 I/O 操作需要较长时间（如网络请求、磁盘读写），应用程序会被挂起，无法执行其他任务。
- 同步I/O
应用场景：
- 适用于简单的应用程序，其中 I/O 操作不会长时间阻塞应用程序。

2. 非阻塞 I/O（Non-blocking I/O）

定义：在非阻塞 I/O 模型中，当应用程序发起 I/O 操作时，操作系统不会阻塞应用程序，而是立即返回。如果操作无法完成（如读取数据时数据未准备好），它会返回一个错误代码或状态，应用程序可以继续做其他事情，稍后再尝试进行 I/O 操作。
特点：
- 非同步：应用程序不会被阻塞，I/O 操作立即返回。
- 效率较高：应用程序可以继续执行其他任务，不需要等待 I/O 完成。
- 编程复杂度高：需要手动检查 I/O 操作的状态，并决定何时再次尝试。
- 同步I/O
应用场景：
- 适用于需要高效并发处理的场景，如图形界面应用、实时系统和一些高性能服务器。

3. I/O 多路复用（I/O Multiplexing）

定义：I/O 多路复用模型允许单个线程同时处理多个 I/O 操作。通过调用特定的系统调用（如 select()、poll()、epoll()），应用程序可以等待多个 I/O 操作的完成，当其中一个或多个 I/O 操作完成时，操作系统会通知应用程序，应用程序可以继续处理数据。
特点：
- 异步：通过一个线程或进程处理多个 I/O 操作，减少了线程上下文切换。
- 高效：适用于需要同时处理大量并发连接的服务器应用，如 Web 服务器。
- 编程复杂：需要管理多个 I/O 操作，并处理事件通知。
- 同步I/O
应用场景：
- 高并发的网络服务器（如 Nginx、Redis），适用于需要同时处理大量客户端请求的应用程序。

4. 信号驱动 I/O（Signal-driven I/O）

定义：信号驱动 I/O 模型通过操作系统的信号机制来通知应用程序 I/O 操作的完成。应用程序通过注册信号处理程序，并在 I/O 操作完成时接收到一个信号，操作系统会异步通知应用程序 I/O 可以继续。
特点：
- 异步：应用程序在等待信号时不会阻塞，直到信号到达。
- 效率较高：避免了频繁的轮询，可以让应用程序在不进行忙等的情况下等待 I/O 完成。
- 编程复杂：需要处理信号、信号屏蔽等问题，容易导致复杂的异步编程。
- 同步I/O
应用场景：
- 多任务、实时系统和需要处理大量异步事件的应用。

5. 异步 I/O（Asynchronous I/O）

定义：在异步 I/O 模型中，应用程序发起 I/O 操作后，操作系统会立即返回，应用程序可以继续执行其他任务。当 I/O 操作完成时，操作系统会通过回调函数或事件通知应用程序。应用程序无需等待 I/O 操作的完成。
特点：
- 完全异步：应用程序不会被阻塞，I/O 操作的完成通过回调机制通知应用程序。
- 高效：适用于需要高性能的应用程序，因为它允许程序继续执行并在 I/O 操作完成后处理结果。
- 编程复杂度较高：需要处理回调、事件循环等问题，可能导致回调地狱等问题。
应用场景：
- 适用于高性能、高并发的场景，尤其是需要大量并发连接并且 I/O 操作较长时间的情况，如数据库和大型网络应用。

2）IO模型对比

1.阻塞IO与非阻塞IO

阻塞 I/O 和 非阻塞 I/O 是计算机系统中两种常见的 I/O 模型，它们描述了应用程序如何与操作系统进行交互来执行 I/O 操作（如读取文件、网络通信等）。它们的主要区别在于应用程序是否会被阻塞，直到 I/O 操作完成。

阻塞IO：在阻塞 I/O 模型中，应用程序执行 I/O 操作时会被阻塞，直到该操作完成并返回结果。即应用程序发起一个 I/O 请求，操作系统会一直等待该请求完成，然后才会返回执行结果。此时应用程序会停止执行，无法进行其他操作。
非阻塞IO：在非阻塞 I/O 模型中，应用程序发起 I/O 请求时，操作系统不会阻塞应用程序的执行，而是立即返回。如果请求的 I/O 操作无法完成（例如数据尚未准备好），操作系统会返回一个错误，表示该操作无法立即完成。应用程序可以选择稍后再尝试该操作，而在此期间可以继续执行其他任务。

特性	阻塞 I/O	非阻塞 I/O
执行模型	应用程序被阻塞，直到 I/O 操作完成	应用程序不被阻塞，操作立即返回
效率	效率较低，无法同时处理其他任务	高效，能够并发执行多个任务
编程复杂度	简单，发起请求后等待结果	较复杂，需要管理 I/O 操作的状态
适用场景	适用于低并发，I/O操作较快的应用程序	适用于高并发，需要高响应速度的应用程序
应用程序执行	在等待 I/O 完成期间无法执行其他任务	可以在等待 I/O 完成时执行其他任务
开发难度	开发简单，容易实现	需要处理 I/O 操作的状态和重试
并发处理能力	无法高效处理大量并发请求	高效处理大量并发请求，适用于高并发应用

阻塞I/O与非阻塞I/O的本质是等+拷贝中等的方式不同

2. 同步IO与异步IO

同步 I/O 和 异步 I/O 是两种常见的 I/O 操作模型，分别适用于不同类型的应用场景。它们的主要区别在于 应用程序是否需要等待 I/O 操作完成，以及 I/O 操作的完成方式。

同步I/O：同步 I/O 模型中，应用程序发起 I/O 操作后，需要等待 I/O 操作完成才会继续执行其他操作。在 I/O 操作进行时，应用程序会被阻塞，直到 I/O 完成并返回结果。
异步I/O：异步 I/O 模型中，应用程序发起 I/O 操作后，不会等待 I/O 操作完成，而是可以继续执行其他任务。当 I/O 操作完成时，操作系统会通过回调机制、信号或事件通知应用程序，应用程序再处理结果。

特性	同步 I/O	异步 I/O
执行模型	应用程序发起 I/O 请求后阻塞，直到 I/O 完成	应用程序发起 I/O 请求后立即返回，可以继续执行其他任务
效率	当 I/O 操作执行时，应用程序被阻塞，效率较低	通过回调或事件机制，应用程序可以高效并发执行其他任务
编程复杂度	编程模型简单，开发者容易理解	编程复杂，需要处理回调、事件和状态管理
适用场景	小型应用、低并发的任务，I/O 操作比较快速	高并发、大规模网络通信、文件系统操作等
资源利用	只能处理一个 I/O 操作，其他操作需要等待	能够处理多个并发 I/O 操作，资源利用率高
阻塞/非阻塞	阻塞	非阻塞
响应时间	I/O 操作完成之前无法响应其他任务	可以通过事件通知或回调响应其他任务
复杂性	相对简单，适合单一操作	需要手动处理 I/O 完成的通知和回调机制

同步I/O与异步I/O的本质区别是有没有参与I/O，异步只是发起了I/O但是没有参与I/O。

3. 五种IO对比

不同的I/O模型有不同的特点，适用于不同的应用场景。选择合适的I/O模型可以提高应用程序的效率和并发性能。

I/O模型	阻塞/非阻塞	应用场景	优点	缺点
阻塞 I/O	阻塞	简单的应用，低并发	简单易用，适用于低延迟操作	阻塞操作，效率低，无法并发处理多个任务
非阻塞 I/O	非阻塞	高性能服务器，实时应用，图形界面应用	不会阻塞，可以处理其他任务	编程复杂，需要手动管理 I/O 状态
I/O 多路复用	非阻塞	高并发网络应用（如Web服务器）	高效处理多个I/O请求，节省资源	编程复杂，管理多个连接和事件通知
信号驱动 I/O	异步	实时系统，处理大量异步事件的应用	异步执行，避免忙等，较高效	信号机制复杂，容易导致错误
异步 I/O	完全异步	高性能、大规模并发的系统	高效执行，减少等待时间，支持回调	编程复杂，需要处理回调，可能导致回调地狱

3）epoll工作模式

epoll 提供了两种主要的事件触发模式：水平触发（LT）和边缘触发（ET）。这两种模式的区别在于，事件触发的方式以及应用程序如何处理事件。这两种模式决定了 epoll 如何通知程序文件描述符发生的事件。

1. 水平触发（Level Triggered，LT）

水平触发是 epoll 的默认模式，行为和 select 或 poll 类似。在此模式下，epoll_wait() 会持续返回已准备好的文件描述符，直到事件被处理完成。换句话说，只要文件描述符上还有待处理的事件，epoll_wait() 就会一直返回该文件描述符。

特点：
- 在文件描述符的事件未处理完之前，epoll_wait() 会不断地返回该文件描述符。
- 程序可以多次读取数据或写入数据，只要文件描述符保持在事件状态中，epoll_wait() 会继续返回该文件描述符。
- 它是一个 基于事件的阻塞模型，只要没有事件发生，就会阻塞等待。
**举例：**假设一个套接字上有数据可读。在水平触发模式下，如果程序没有完全读取套接字中的所有数据，epoll_wait() 会继续返回该文件描述符，直到数据被完全读取为止。如果应用程序在中途处理不完全，epoll_wait() 会再次通知该文件描述符，直到事件状态被清除。
适用场景：
- 简单易用，适合大多数应用场景。
- 适用于希望在每次事件发生时都能够简单地处理该事件的程序。
优点：
- 易于使用，不需要额外的处理逻辑。
- 在事件未处理完的情况下，epoll_wait() 会持续通知应用程序，防止遗漏事件。
缺点：
- 可能会导致不必要的重复处理，尤其是当文件描述符上有大量数据时，epoll_wait() 会多次返回，可能带来性能问题。

2. 边缘触发（Edge Triggered，ET）

边缘触发是一种更高效的事件通知模式。在这种模式下，epoll_wait() 只会在文件描述符的状态发生变化时通知应用程序。例如，当文件描述符从不可读变为可读，或者从不可写变为可写时，epoll_wait() 会通知程序。这意味着一旦事件触发，应用程序需要在第一次通知时尽可能多地处理所有数据。

特点：
- 只会通知一次：当事件发生时，epoll_wait() 只会返回该文件描述符一次，直到文件描述符的状态发生变化。即使文件描述符依然处于事件状态，epoll_wait() 不会重复通知。
- 适用于 非阻塞模式，即程序通过 read 或 write 等系统调用不断获取数据，直到状态完全变化。
- 如果事件在通知后未完全处理，程序可能会漏掉后续的事件通知。
**举例：**假设一个套接字上有数据可读，在边缘触发模式下，如果程序没有完全读取数据（例如，只读取了一部分），epoll_wait() 将不会再通知程序该文件描述符。程序需要在第一次通知时尽可能读取所有数据，否则可能会错过后续的数据事件。
适用场景：
- 当文件描述符的状态变化较少时，epoll 会更加高效。
- 适用于 高性能要求 和 实时性要求高的应用，例如高并发服务器。
优点：
- 高效，减少了重复通知的开销，避免了不必要的事件处理。
- 能够处理高并发的 I/O 操作，节省资源。
缺点：
- 编程模型更加复杂，程序需要确保在事件触发时尽可能多地处理所有数据，避免丢失事件。
- 如果应用程序没有及时处理所有数据，可能会错过后续的事件通知。

二、IO接口

1）非阻塞IO

1. `fcntl`（文件控制）

fcntl（File Control）是一个用于操作文件描述符的系统调用，允许对文件描述符进行各种操作。它是 Unix-like 操作系统中非常重要的一个函数，提供了一些功能，如设置文件描述符的属性、修改文件状态、获取文件信息等。

fcntl()

int fcntl(int fd, int cmd, ... /* arg */ )
```
#include <fcntl.h>
int fd = open("example.txt", O_RDONLY);
int f1 = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, f1 | O_NONBLOCK);
```
- fd：文件描述符，是通过 open() 函数打开的文件或设备的文件描述符。
- cmd：操作的命令，决定要执行的操作。
  - F_GETFD：获取文件描述符的文件描述符标志（用于关闭文件描述符的标志）。
  - F_GETFL：获取文件描述符的状态标志（如 O_RDONLY, O_WRONLY, O_RDWR 等）。
  - F_SETFD：设置文件描述符的文件描述符标志。
  - F_SETFL：设置文件描述符的状态标志（如设置文件为非阻塞）。
  - F_SETOWN：设置文件所属进程或进程组的 ID，用于信号驱动 I/O。
  - F_GETLK：获取文件锁信息。
  - F_SETLK：设置文件锁。
  - F_SETLKW：设置文件锁，并在文件锁不可用时阻塞。
  - F_DUPFD：从给定的最小值开始查找未使用的文件描述符，并复制。
- arg：根据不同的命令，这个参数可以是值、结构体等。不同的命令要求传入不同类型的参数。
- 返回值（根据cmd参数选择的命令不同返回值不同）：
  - F_GETFD：成功返回文件描述符的标志值，例如 FD_CLOEXEC。失败时返回 -1，设置 errno。
  - F_GETFL：成功返回文件状态标志的值，例如 O_RDONLY、O_NONBLOCK。失败时返回 -1，设置 errno。
  - F_SETFD，F_SETFL，F_SETOWN：0 表示成功，-1 表示失败。
  - F_GETLK：成功时返回 0，结构体 struct flock 中填充当前锁的状态。
  - F_SETLK：成功时返回 0；如果文件已被锁定，返回 -1，errno 设置为 EACCES 或 EAGAIN。
  - F_SETLKW：成功时返回 0；失败返回 -1。
  - F_DUPFD：返回新的文件描述符。如果失败，返回 -1。

2）多路转接-select

1. `select`

select 是一个在 Unix 和 Linux 操作系统中用于实现 I/O 多路复用 的系统调用。它允许程序在单个线程中同时监视多个 I/O 通道，并在其中某些通道准备好进行读写操作时，通知程序进行相应的处理。这是一个非常有用的技术，尤其是在需要处理大量并发连接的网络应用中。

select()

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout)
```
#include <sys/select.h>

// 类型准备
fd_set readfds;
struct timeval timeout;

// 清空文件描述符集合
FD_ZERO(&readfds);
// 将文件描述符0加入集合。
FD_SET(0, &readfds);
// 阻塞最多5秒
timeout.tv_sec = 5;
timeout.tv_usec = 0;
ret = select(1, &readfds, NULL, NULL, &timeout);
```
- nfds：nfds 表示监视的文件描述符集合中最大文件描述符的值加1。也就是文件描述符的范围是 [0, nfds-1]。
  - 为什么要加1：select 需要检查的文件描述符的最大值，nfds 需要传入的是最大文件描述符值加1。也就是说，如果你监控的文件描述符是从 0 到 5，那么 nfds 应该设置为 6。
- readfds(输入输出型参数)：监视可读事件的文件描述符集合。select 会返回那些准备好进行读操作的文件描述符。
- writefds(输入输出型参数)：监视可写事件的文件描述符集合。select 会返回那些准备好进行写操作的文件描述符。
- exceptfds(输入输出型参数)：监视异常事件的文件描述符集合。select 会返回那些有异常的文件描述符（例如，连接重置）。
- timeout(输入输出型参数)：等待的时间。它是一个 struct timeval 结构体，表示最大等待时间，单位为秒和微秒。如果设为 NULL，select 将会一直阻塞直到有文件描述符准备好。
  - timeval = {5, 0}：阻塞最多 5 秒，超时后返回 0。
  - timeval = {0, 0}：非阻塞模式，立即返回（轮询）。
  - NULL：完全阻塞，直到有 fd 就绪。
- 返回值
  - > 0：就绪的 fd 总数（跨所有集合）。
  - 0：超时且无 fd 就绪。
  - -1：出错（如被信号中断）。
- fd_set ：位图，用来表示文件描述符集合。每一位代表一个文件描述符是否在集合中。例如，fd_set 用于 select 来检查文件描述符是否准备好。
  - FD_ZERO(fd_set \*set)：清空文件描述符集合。
  - FD_SET(int fd, fd_set \*set)：将文件描述符 fd 加入集合。
  - FD_CLR(int fd, fd_set \*set)：从集合中删除文件描述符 fd。
  - FD_ISSET(int fd, fd_set \*set)：检查文件描述符 fd 是否在集合中。
- struct timeval：表示 select 等待的最长时间。如果时间到达而没有任何文件描述符准备好，select 会返回 0。
```
struct timeval {
    long tv_sec;  // 秒数
    long tv_usec; // 微秒数
};
```
缺点：
- 每次调用都要手动设置fd集合，使用不方便。
- 文件描述符限制：select 的文件描述符数量是有限的，通常为 1024（受操作系统限制）。在处理大量并发连接时，这个限制会成为瓶颈。
- 性能问题：每次调用 select 都需要检查整个文件描述符集合，输入输出型参数比较多，数据拷贝的频率比较高，如果文件描述符很多，效率会较低。
- 每次都要对关心的fd进行时间重置。

3）多路转接-poll

1. `poll`

poll 是与 select 相似的一个系统调用，旨在实现 I/O 多路复用。它允许一个程序监视多个文件描述符（如套接字、文件等），并在其中某些文件描述符准备好进行读写操作时，通知应用程序进行相应的处理。与 select 类似，poll 可以帮助程序避免阻塞，并实现高效的 I/O 操作。

struct pollfd
```
struct pollfd {
    int fd;          // 文件描述符
    short events;    // 感兴趣的事件
    short revents;   // 返回的事件
};
```
- fd：要监视的文件描述符，通常是一个套接字或文件。
- events：表示感兴趣的事件。可以是以下几种之一或组合：
  - POLLIN：文件描述符可以读。
  - POLLOUT：文件描述符可以写。
  - POLLERR：文件描述符发生错误。
  - POLLHUP：文件描述符被挂起。
  - POLLNVAL：文件描述符无效。
- revents：表示 poll 返回的事件。与 events 类似，revents 是 poll 在返回时会填充的字段，表示文件描述符上发生的事件。
poll()

int poll(struct pollfd *fds, nfds_t nfds, int timeout)
- fds：是一个 struct pollfd 类型的数组，每个 pollfd 结构表示一个需要监视的文件描述符及其感兴趣的事件。
- nfds：表示 fds 数组的大小，即需要监视的文件描述符的数量。
- timeout：表示等待的最长时间，单位为毫秒。如果 timeout 为 -1，poll 会一直阻塞，直到至少一个文件描述符准备好。如果 timeout 为 0，表示非阻塞模式，不会阻塞，立即返回。
- 返回值：
  - > 0：表示有准备好的文件描述符，返回准备好的文件描述符的数量。
  - = 0：表示超时，没有文件描述符准备好。
  - < 0：表示发生错误，通常是由于传入参数不合法，或者操作系统内部出现异常。
缺点
- 线性扫描性能问题：遍历所有文件描述符，处理效率低。
- 不自动移除无效描述符：需要程序手动管理无效文件描述符。
- 拷贝开销高：每次调用时都要将文件描述符集合从用户态拷贝到内核态。
- 事件触发无持久性：每次调用都需重新设置关注的事件。
- 不适合大规模并发：在高并发场景下性能不如 epoll 等现代机制。
- 缺乏回调机制：无法直接与用户代码挂钩，事件处理复杂。

4）多路转接之epoll

epoll 是 Linux 提供的一种 高效的 I/O 多路复用 模型。与传统的 select 和 poll 模型相比，epoll 提供了更好的性能，特别是在处理大量并发连接时。它的工作原理和事件通知机制使其成为一种非常适合高并发、高效能应用的方案。

#incldue <sys/epoll.h>

1. `epoll_create()`

epoll_create() 用于创建一个 epoll 实例，返回一个文件描述符，该文件描述符代表 epoll 实例。该文件描述符是后续操作的核心。

epoll_create()：

int epoll_create(int size)
- size：size 是一个建议的参数，实际大小不再起作用。
- 返回值：返回 epoll 实例的文件描述符。

2. `epoll_wait()`

epoll_wait() 用于等待和获取发生的事件。如果指定了超时时间，它将阻塞，直到一个文件描述符上的事件发生，或者超时。

epoll_data_t

epoll_data_t 是 epoll_event 结构体中的一部分。在事件触发时，epoll_data_t 会保存与文件描述符相关的用户数据，便于在事件处理时使用。
```
typedef union epoll_data {
    void *ptr;        // 指针类型
    int fd;           // 文件描述符
    uint32_t u32;     // 无符号 32 位整数
    uint64_t u64;     // 无符号 64 位整数
}epoll_data_t;
```
- ptr：指向任意类型数据的指针，通常用于存储与该文件描述符相关的结构体或对象。
- fd：文件描述符，通常用来直接存储文件描述符的值。
- u32：无符号 32 位整数，通常用于存储与文件描述符相关的状态或标志。
- u64：无符号 64 位整数，通常用于存储较大的数据（如时间戳等）。
struct epcoll event

epoll_event 结构体用于表示文件描述符及其感兴趣的事件。
```
struct epoll_event {
    uint32_t events;    // 事件类型，如 EPOLLIN, EPOLLOUT 等
    epoll_data_t data;  // 用户自定义数据，通常是文件描述符
};
```
- events：表示该文件描述符的感兴趣事件。
  - EPOLLIN：可读
  - EPOLLOUT：可写
  - EPOLLERR：错误
- data：用于存储用户自定义数据，通常是文件描述符。这样可以方便地在事件触发时区分不同的文件描述符。
epoll_wait()

int epoll_wait(int epfd, struct epoll_event *events, int maxevents, int timeout)
- epfd：epoll_create 返回的文件描述符。
- events(输出型参数)：返回准备好的文件描述符及其事件。
- maxevents(输出型参数)：最多返回的事件数量。
- timeout：等待事件的超时时间，单位为毫秒。如果为 -1，表示一直阻塞直到事件发生。如果为 0，表示非阻塞。
- 返回值：
  - > 0：返回准备好的文件描述符的数量，表示有事件发生，可以进行相应的处理。
  - = 0：表示超时，没有文件描述符准备好。
  - < 0：表示出错，通常是参数错误。

3. `epoll_ctl`

epoll_ctl() 用于控制 epoll 实例的行为，可以添加、删除或修改要监控的文件描述符及其事件。

epoll_ctl()

int epoll_ctl(int epfd, int op, int fd, struct epoll_event *event)
- epfd：由 epoll_create 返回的文件描述符。
- op：操作类型。可以是：
  - EPOLL_CTL_ADD：添加文件描述符到 epoll 实例中。
  - EPOLL_CTL_MOD：修改文件描述符的事件。
  - EPOLL_CTL_DEL：删除文件描述符。
- fd：要监控的文件描述符。
- event：文件描述符的事件，表示该文件描述符的感兴趣事件（如可读、可写等）。

epoll的优势

高效的事件通知机制：
使用事件驱动模型，无需线性扫描文件描述符集合，仅处理发生事件的文件描述符。

自动管理文件描述符：
无效的文件描述符会自动从 epoll 中移除，无需程序手动维护。

持久的事件监听：
支持水平触发（level-triggered）和边沿触发（edge-triggered），无需每次重新设置事件。

减少用户态与内核态切换：
文件描述符集合通过内核维护，避免每次调用时的拷贝开销。

支持大量文件描述符：
基于红黑树和事件队列管理文件描述符，性能在高并发场景下表现优异。

更灵活的接口：
提供 epoll_ctl 和 epoll_wait 等接口，可以动态添加、删除和修改事件，灵活性高。

适用于高并发场景：
能够处理百万级别的连接，特别适合大型网络服务器或 I/O 密集型应用。