不懂 io_uring ,别再说你懂 Linux 内核了

在 Linux 内核的世界里，异步 IO 始终是区分“入门”与“精通”的核心门槛，而 io_uring 的出现，彻底重塑了 Linux 高性能异步 IO 的游戏规则。如果你还停留在 select、poll、epoll 的认知层面，即便能熟练操作内核基础功能，也终究没触及当代 Linux 内核异步 IO 的核心精髓。它不是简单的 API 升级，而是内核层面的架构革新，是高性能服务器、存储引擎、网络框架的底层支撑，更是衡量一名开发者内核功底的“试金石”。

很多人自称“懂 Linux 内核”，却对 io_uring 一知半解，殊不知如今主流的高性能应用，几乎都在依赖 io_uring 突破 IO 瓶颈。放弃它，就等于放弃了对 Linux 内核高性能领域的话语权。接下来，我们将跳出表面 API 调用，深入内核源码，拆解 io_uring 的核心实现逻辑，从原理到实践，带你真正吃透这个能让你拉开差距的内核核心技术，彻底摆脱“伪内核学习者”的标签。

一、传统 I/O 模型回顾

面试题写作模版

在深入了解 io_uring 之前，我们先回顾传统 I/O 模型，剖析其在高并发、高性能场景下的瓶颈。Linux 系统中，I/O 是程序与磁盘、网络等外部设备进行数据交互的核心方式。随着技术发展与应用场景日趋复杂，Linux I/O 模型持续演进，从最初的阻塞 I/O 发展到如今高性能的 io_uring，每一次变革都显著提升了 I/O 性能与执行效率。

1.1 阻塞式 I/O（Blocking I/O）

阻塞式 I/O 是最基础、最容易理解的 I/O 模型，也是 Linux 下默认的 I/O 工作方式。当用户进程调用 read/recvfrom 等 I/O 系统调用时，会触发两个阶段的全程阻塞：如果内核缓冲区没有数据，进程会被挂起，直到数据到达内核缓冲区；数据到达后，内核将数据拷贝到用户缓冲区，拷贝完成后，进程才会被唤醒，系统调用返回。

举个例子，假如你去餐厅吃饭，点完菜后就只能坐在座位上干等着，什么也做不了，直到服务员把菜端上来。在这个过程中，你就像一个阻塞式 I/O 的进程，被阻塞在等待数据（上菜）的阶段，无法执行其他任务。阻塞式 I/O 的优点是实现简单，逻辑直观；缺点也很明显，效率极低，一个进程在阻塞期间无法做任何其他工作，只能处理一个 I/O 流，这在高并发场景下是无法满足需求的。比如一个简单的 Web 服务器，如果采用阻塞式 I/O，当有大量客户端请求时，服务器进程会被大量阻塞，导致响应速度极慢，甚至无法响应新的请求。

1.2 非阻塞式 I/O（Non - blocking I/O）

为了解决阻塞式 I/O 的 “进程挂起” 问题，非阻塞式 I/O 应运而生。它的核心思路是让 I/O 系统调用从不阻塞。用户进程需要先通过 fcntl 函数将目标文件描述符（比如 socket）设置为 O_NONBLOCK 非阻塞模式。之后每次调用 read/recvfrom 时，如果内核缓冲区没有数据，系统调用会立即返回错误码（EAGAIN/EWOULDBLOCK），不会阻塞进程；只有当内核缓冲区有数据时，才会阻塞进程，完成数据拷贝，然后返回结果。

还是以餐厅为例，这次你点完外卖打包，点完菜后可以在餐厅里自由走动，但需要每隔几分钟就去问服务员 “我的菜好了吗？” 大部分时候得到的回答都是 “还没好”。在这个场景中，你就像一个非阻塞式 I/O 的进程，不会被阻塞在等待数据的阶段，可以在轮询间隙处理其他任务。虽然非阻塞式 I/O 比阻塞式 I/O 灵活，进程在轮询间隙可以处理其他任务，但它的缺点也不容忽视。由于需要不断轮询检查数据是否就绪，会持续消耗 CPU 资源，描述符数量越多，CPU 开销越大。所以非阻塞式 I/O 适合连接数少、需要即时响应的场景，比如简单的客户端 socket 通信、小型工具的实时数据读取，而不适合高并发场景。

1.3 I/O 多路复用（I/O Multiplexing）

I/O 多路复用是高并发网络编程的核心模型，也是 Nginx、Redis、Memcached 等中间件的底层核心技术。它解决了非阻塞式 I/O 轮询的 CPU 浪费问题，实现了 “一个进程监控多个 I/O 流”。Linux 下提供了 3 种实现：select、poll、epoll 。

I/O 多路复用的核心是引入一个 “代理”—— 内核级的 I/O 监控函数（select/poll/epoll）。用户进程通过这个代理函数，同时监控多个文件描述符的状态。以 epoll 为例，进程调用 epoll_wait，传入需要监控的描述符列表；epoll_wait 会阻塞进程，直到任意一个描述符的数据就绪；然后 epoll_wait 返回就绪的描述符列表，进程只需要针对这些就绪的描述符，调用 I/O 函数完成数据拷贝。

三种实现各有特点，select 使用位图表示 FD 集合，默认最大 1024 个，每次调用需要复制 FD 集合到内核，返回后需要遍历所有 FD 找出就绪的；poll 使用 pollfd 结构体数组，无最大数量限制，避免了 select 的参数 - 值转换问题；epoll 则是 Linux 的高性能解决方案，它通过功能分离（将 “监控 FD” 和 “等待事件” 分开）、维护就绪列表（内核维护就绪 FD 列表，直接返回就绪的 FD）和事件回调（避免轮询检查，只有活跃的 socket 才会触发回调函数，将自身加入就绪列表）等机制，在高并发场景下表现出色，一个进程可以轻松处理数万甚至百万级别的连接，CPU 资源消耗极低，因此成为高并发网络服务的首选 。

二、初识 io_uring

面试题写作模版

2.1 什么是 io_uring？

io_uring 是 Linux 内核在 5.1 版本引入的高性能异步 I/O 框架 ，由 Jens Axboe 开发，旨在解决传统异步 I/O 模型（如 epoll 或者 POSIX AIO）在大规模 I/O 操作中效率不高的问题。它的出现是 Linux I/O 发展历程中的一次重大突破，为开发者提供了更高效、更强大的 I/O 处理方式。在 io_uring 诞生之前，虽然已经有多种 I/O 模型，但在面对高并发、大规模数据处理等场景时，都暴露出了各自的局限性，迫切需要一种新的 I/O 模型来满足日益增长的性能需求，io_uring 应运而生。

io_uring 的核心概念主要包括提交队列（SQ）、完成队列（CQ）、提交队列项（SQE）和完成队列项（CQE）：

• 提交队列（SQ，Submission Queue）：用于存放用户空间提交的 I/O 请求。用户将 I/O 请求填充到 SQ 中，并通知内核有新的请求需要处理。它是一个环形队列，用户通过操作队列的 tail 指针来写入新的请求 。
• 完成队列（CQ，Completion Queue）：用于存放已经完成的 I/O 请求结果。内核在处理完 I/O 请求后，会将结果填充到 CQ 中，并通知用户空间有请求已完成。同样是环形队列，用户通过操作队列的 head 指针来读取完成的结果 。
• 提交队列项（SQE，Submission Queue Entry）：表示一个具体的 I/O 请求，包含了操作类型（如 READ、WRITE、ACCEPT 等）、文件描述符、缓冲区地址、偏移量、数据长度等信息。用户通过填充 SQE 来描述 I/O 请求，并将其放入 SQ 队列 。例如：

struct io_uring_sqe {    __u8 opcode;       // 操作类型，如 READ, WRITE, ACCEPT…    __u8 flags;    __u16 ioprio;    __s32 fd;    __u64 offset;    __u64 addr;        // 用户缓冲区地址    __u32 len;    __u64 user_data;   // 用户自定义数据（回调、标识等）};

• 完成队列项（CQE，Completion Queue Entry）：表示一个 I/O 请求的完成结果，包含返回值（成功时为字节数，失败时为 -errno）、用户自定义数据等信息。用户从 CQ 队列中读取 CQE 来获取 I/O 请求的执行结果 。其数据结构如下：

struct io_uring_cqe {    __u64 user_data; // 与 SQE 中设置的一致    __s32 res;       // 返回值：成功时为字节数，失败时为 -errno    __u32 flags;};

SQ 和 CQ 通过内存映射（mmap）的方式映射到用户空间，使得用户态和内核态可以直接访问，避免了频繁的系统调用和数据拷贝。用户是 SQ 的生产者，内核是消费者；内核是 CQ 的生产者，用户是消费者 。

io_uring 提供了两种主要的工作模式：SQPoll（Submission Queue Polling）和 SQePoll（Submission Queue Event Polling），这两种模式分别针对不同的使用场景进行了优化。SQPoll 模式通过轮询提交队列来检测是否有新的 I/O 请求需要处理，这种机制适用于对延迟敏感的应用场景，如实时数据处理或交互式应用程序。由于 SQPoll 模式无需依赖中断机制，因此能够有效减少中断处理带来的开销，从而降低系统延迟。然而，这种模式的缺点在于高负载情况下可能导致 CPU 占用率升高，影响整体系统性能。

相比之下，SQePoll 模式则通过事件驱动的方式实现 I/O 请求的处理。在这种模式下，内核会在提交队列中有新请求时触发事件通知，从而避免不必要的轮询开销。SQePoll 模式特别适合于高吞吐量场景，如大规模数据处理或批量任务执行，因为它能够在保持高性能的同时降低 CPU 资源的消耗。实验数据显示，在相同的硬件条件下，SQePoll 模式的平均延迟比 SQPoll 模式低约 20%，而吞吐量则提升了近 30%。这两种模式的灵活切换为用户提供了更大的选择空间，同时也体现了 io_uring 设计上的高度适应性。

2.2 io_uring 的设计原理

io_uring 的设计目标是打破传统异步 I/O 模型的性能束缚，通过一系列创新设计，实现高效的 I/O 处理。它的设计理念主要体现在以下几个方面：

1. 系统调用开销大：在传统 I/O 模型中，每次 I/O 操作都需要进行系统调用，从用户态切换到内核态。以一个简单的文件读取操作为例，使用 read 系统调用时，用户程序调用 read 函数，这实际上是 glibc 提供的封装，最终通过软中断（如 int 0x80 或 syscall 指令）主动陷入内核，CPU 从用户态（ring 3）切到内核态（ring 0） ，切换栈、保存上下文、查表执行对应内核函数（如 sys_read）。在高并发场景下，频繁的系统调用会消耗大量的 CPU 资源。而 io_uring 通过共享内存环形队列（ring buffer），用户态和内核态可以直接在共享内存中进行数据交互，减少了系统调用的次数，从而降低了上下文切换的开销。比如在一个高并发的文件服务器中，使用传统 I/O 模型时，大量的文件读取请求会导致频繁的系统调用，而 io_uring 可以将多个 I/O 请求批量提交，减少系统调用次数，提高效率。
2. 数据拷贝次数多：传统 I/O 在数据传输过程中，数据往往需要在用户空间和内核空间之间多次拷贝。以从磁盘读取数据到用户程序为例，数据先从磁盘复制到内核缓冲区，再从内核缓冲区复制到用户缓冲区。而 io_uring 通过共享内存机制，用户态和内核态共享提交队列（SQ）和完成队列（CQ），避免了不必要的数据拷贝。当用户态提交 I/O 请求时，直接将请求参数写入共享内存中的 SQ，内核态从 SQ 中获取请求并执行，执行完成后将结果写入 CQ，用户态从 CQ 中读取结果，整个过程大大减少了数据拷贝次数。
3. 异步处理能力有限：传统的非阻塞 I/O 和 I/O 多路复用虽然在一定程度上实现了异步处理，但它们的异步程度还不够彻底。例如 epoll，它只是一种事件通知机制，当事件就绪后，还需要应用程序主动进行 I/O 操作，仍然需要应用程序主动轮询或等待事件通知，无法充分发挥硬件的性能。而 io_uring 实现了真正意义上的异步 I/O，应用程序提交 I/O 请求后可以立即返回，继续执行其他任务，内核在后台完成 I/O 操作后通过完成队列通知应用程序，充分发挥了硬件的性能，提高了系统的并发处理能力。

2.3 io_uring 设计思路

(1)解决“系统调用开销大”的问题？

针对这个问题，考虑是否每次都需要系统调用。如果能将多次系统调用中的逻辑放到有限次数中来，就能将消耗降为常数时间复杂度。

(2)解决“拷贝开销大”的问题？

之所以在提交和完成事件中存在大量的内存拷贝，是因为应用程序和内核之间的通信需要拷贝数据，所以为了避免这个问题，需要重新考量应用与内核间的通信方式。我们发现，两者通信，不是必须要拷贝，通过现有技术，可以让应用与内核共享内存。

要实现核外与内核的零拷贝，最佳方式就是实现一块内存映射区域，两者共享一段内存，核外往这段内存写数据，然后通知内核使用这段内存数据，或者内核填写这段数据，核外使用这部分数据。因此，需要一对共享的 ring buffer 用于应用程序和内核之间的通信。

• 一块用于核外传递数据给内核，一块是内核传递数据给核外，一方只读，一方只写。
• 提交队列 SQ(submission queue)中，应用是 IO 提交的生产者，内核是消费者。
• 完成队列 CQ(completion queue)中，内核是 IO 完成的生产者，应用是消费者。
• 内核控制 SQ ring 的 head 和 CQ ring 的 tail，应用程序控制 SQ ring 的 tail 和 CQ ring 的 head

(3)解决“API 不友好”的问题？

问题在于需要多个系统调用才能完成，考虑是否可以把多个系统调用合而为一。有时候，将多个类似的函数合并并通过参数区分不同的行为是更好的选择，而有时候可能需要将复杂的函数分解为更简单的部分来进行重构。

如果发现函数中的某一部分代码可以独立出来成为一个单独的函数，可以先进行这样的提炼，然后再考虑是否需要进一步使用参数化方法重构。

2.4 io_uring 的优势分析

io_uring 相较于传统 I/O 机制在性能方面的提升主要体现在延迟降低和吞吐量提高两个方面。根据相关实验数据，io_uring 在处理小文件随机读写操作时的平均延迟较传统异步 I/O 机制降低了约 40%，而在顺序读写场景中，其吞吐量提升了超过 50%。这一显著性能提升得益于 io_uring 的核心设计特性，包括提交队列与完成队列的无锁实现、硬件加速的支持以及批量处理能力的优化。这些特性共同作用，使得 io_uring 能够更高效地利用系统资源，同时减少不必要的上下文切换和系统调用开销。

此外，io_uring 在多核环境下的表现尤为突出。通过将提交队列和完成队列映射到不同的 CPU 核心，io_uring 能够充分利用现代多核处理器的并行计算能力，从而进一步提高整体性能。例如，在一项针对高性能计算场景的测试中，io_uring 在 16 核处理器上的吞吐量比单核环境下提升了近 4 倍，而延迟仅增加了不到 10%。这种优异的扩展性使得 io_uring 成为处理大规模并发 I/O 请求的理想选择。

除了性能提升外，io_uring 在减少系统资源消耗方面也展现出显著优势。传统 I/O 机制在处理高并发请求时往往会导致 CPU 占用率和内存使用量的急剧增加，而 io_uring 通过优化其内部数据结构和操作逻辑，有效缓解了这一问题。例如，提交队列和完成队列的环形缓冲区设计避免了频繁的内存分配与释放操作，从而显著降低了内存碎片化现象的发生概率。此外，io_uring 的事件驱动机制在处理大量 I/O 请求时能够减少不必要的上下文切换，进而降低 CPU 占用率。

研究表明，在高并发网络服务场景中，使用 io_uring 的 Web 服务器在处理相同数量的并发连接时，CPU 占用率较传统异步 I/O 机制降低了约 25%，而内存使用量则减少了近 15%。这种资源消耗的优化不仅延长了系统的稳定运行时间，还为其他关键任务释放了更多的计算资源，从而提升了整体系统的利用率。这些优势使得 io_uring 在资源受限的环境中尤为适用，如嵌入式系统或边缘计算设备。

三、io_uring 核心原理

面试题写作模版

3.1 共享环形队列

io_uring 通过共享内存构建了提交队列（SQ）和完成队列（CQ），这是其实现高效 I/O 的基础。在传统 I/O 模型中，用户态与内核态之间的通信往往需要进行多次数据拷贝，这不仅增加了数据传输的时间，还消耗了大量的系统资源。而 io_uring 的共享环形队列机制打破了这一困境 。

当应用程序需要进行 I/O 操作时，它将 I/O 请求封装成提交队列条目（SQE），并将其写入 SQ。由于 SQ 是通过共享内存与内核态相连，内核可以直接从 SQ 中读取请求，无需进行数据拷贝。同样，当内核完成 I/O 操作后，会将结果封装成完成队列条目（CQE），写入 CQ。应用程序也可以直接从 CQ 中读取完成事件，获取 I/O 操作的结果 。

以一个简单的文件读取操作为例，假设我们使用 io_uring 读取一个文件：

#include <liburing.h>#include <fcntl.h>#include <unistd.h>#include <stdio.h>#include <string.h>#define BUFFER_SIZE 4096intmain(){    struct io_uring ring;    char buffer[BUFFER_SIZE];    struct io_uring_sqe *sqe;    struct io_uring_cqe *cqe;    int fd, ret;    // 初始化 io_uring    ret = io_uring_queue_init(8, &ring, 0);    if (ret < 0) {        perror("io_uring_queue_init");        return 1;    }    // 打开文件    fd = open("example.txt", O_RDONLY);    if (fd < 0) {        perror("open");        io_uring_queue_exit(&ring);        return 1;    }    // 获取一个 SQE 并准备 read 操作    sqe = io_uring_get_sqe(&ring);    io_uring_prep_read(sqe, fd, buffer, sizeof(buffer), 0);    // 提交请求    ret = io_uring_submit(&ring);    if (ret < 0) {        perror("io_uring_submit");        close(fd);        io_uring_queue_exit(&ring);        return 1;    }    // 等待完成并获取 CQE    ret = io_uring_wait_cqe(&ring, &cqe);    if (ret < 0) {        perror("io_uring_wait_cqe");        close(fd);        io_uring_queue_exit(&ring);        return 1;    }    // 检查是否成功    if (cqe->res >= 0) {        printf("Read %d bytes: %.*s\n", cqe->res, (int)cqe->res, buffer);    } else {        printf("Read failed, errno = %d\n", -cqe->res);    }    // 标记 CQE 已处理    io_uring_cqe_seen(&ring, cqe);    // 释放资源    close(fd);    io_uring_queue_exit(&ring);    return 0;}

在这个例子中，应用程序通过 io_uring_get_sqe 获取一个 SQE，然后使用 io_uring_prep_read 准备一个读取操作，并将其写入 SQ。内核从 SQ 中读取请求并执行文件读取操作，完成后将结果写入 CQ。应用程序通过 io_uring_wait_cqe 从 CQ 中获取完成事件，从而得知读取操作的结果 。这种共享环形队列的设计，使得用户态与内核态之间的通信更加高效，避免了数据的多次拷贝，大大提高了 I/O 操作的效率 。

3.2 批量处理能力

io_uring 支持单次系统调用提交多个 I/O 请求，并一次性收割多个完成事件，这一特性极大地减少了上下文切换的开销，提升了系统的整体性能 。

在高并发场景下，传统 I/O 模型需要频繁地进行系统调用，每次系统调用都伴随着用户态与内核态之间的上下文切换，这会消耗大量的时间和系统资源。而 io_uring 允许应用程序将多个 I/O 请求一次性写入 SQ，然后通过一次系统调用（io_uring_enter）通知内核处理。内核在完成这些 I/O 操作后，会将多个完成事件一次性写入 CQ，应用程序也可以一次性从 CQ 中获取这些完成事件 。

例如，在一个需要处理大量文件读取请求的场景中，使用 io_uring 可以这样实现：

#include <liburing.h>#include <fcntl.h>#include <unistd.h>#include <stdio.h>#include <string.h>#define BUFFER_SIZE 4096#define REQUESTS_NUM 10intmain(){    struct io_uring ring;    char buffers[REQUESTS_NUM][BUFFER_SIZE];    struct io_uring_sqe *sqe;    struct io_uring_cqe *cqe;    int fds[REQUESTS_NUM];    int i, ret;    // 初始化 io_uring    ret = io_uring_queue_init(REQUESTS_NUM, &ring, 0);    if (ret < 0) {        perror("io_uring_queue_init");        return 1;    }    // 打开多个文件    for (i = 0; i < REQUESTS_NUM; i++) {        char filename[32];        snprintf(filename, sizeof(filename), "file%d.txt", i);        fds[i] = open(filename, O_RDONLY);        if (fds[i] < 0) {            perror("open");            for (int j = 0; j < i; j++) {                close(fds[j]);            }            io_uring_queue_exit(&ring);            return 1;        }    }    // 提交多个读取请求    for (i = 0; i < REQUESTS_NUM; i++) {        sqe = io_uring_get_sqe(&ring);        io_uring_prep_read(sqe, fds[i], buffers[i], sizeof(buffers[i]), 0);    }    // 提交请求    ret = io_uring_submit(&ring);    if (ret < 0) {        perror("io_uring_submit");        for (i = 0; i < REQUESTS_NUM; i++) {            close(fds[i]);        }        io_uring_queue_exit(&ring);        return 1;    }    // 等待并获取所有完成事件    for (i = 0; i < REQUESTS_NUM; i++) {        ret = io_uring_wait_cqe(&ring, &cqe);        if (ret < 0) {            perror("io_uring_wait_cqe");            for (int j = 0; j < REQUESTS_NUM; j++) {                close(fds[j]);            }            io_uring_queue_exit(&ring);            return 1;        }        // 检查是否成功        if (cqe->res >= 0) {            printf("Read from file%d.txt: %d bytes\n", i, cqe->res);        } else {            printf("Read from file%d.txt failed, errno = %d\n", i, -cqe->res);        }        // 标记 CQE 已处理        io_uring_cqe_seen(&ring, cqe);    }    // 释放资源    for (i = 0; i < REQUESTS_NUM; i++) {        close(fds[i]);    }    io_uring_queue_exit(&ring);    return 0;}

在这段代码中，应用程序一次性打开了 10 个文件，并将 10 个读取请求一次性提交给内核。内核处理完这些请求后，应用程序再一次性从 CQ 中获取 10 个完成事件，处理读取结果。这种批量处理的方式，相比传统的逐个处理 I/O 请求的方式，大大减少了上下文切换的次数，提高了处理效率 。

3.3 内核轮询机制

io_uring 提供了 SQ Polling 模式，在这种模式下，内核会主动轮询 SQ，无需应用程序显式地调用系统调用通知内核处理 I/O 请求。这一机制进一步消除了系统调用的延迟，提高了 I/O 操作的响应速度 。

在传统 I/O 模型中，应用程序需要通过系统调用（如 select、poll、epoll 等）来通知内核有 I/O 事件发生，内核在接收到通知后才会进行处理。而在 io_uring 的 SQ Polling 模式下，内核会在后台持续轮询 SQ，一旦发现有新的 I/O 请求，就立即进行处理。这样，当应用程序将 I/O 请求写入 SQ 后，内核可以第一时间获取并处理，避免了因等待系统调用而产生的延迟 。例如，在一个对实时性要求较高的网络应用中，使用 SQ Polling 模式可以显著提升性能。

假设我们有一个简单的 TCP 服务器，使用 io_uring 和 SQ Polling 模式来处理客户端连接和数据收发：

#include <liburing.h>#include <sys/socket.h>#include <arpa/inet.h>#include <unistd.h>#include <stdio.h>#include <string.h>#define QUEUE_DEPTH 128#define BUFFER_SIZE 1024// 定义事件类型#define EVENT_ACCEPT 0#define EVENT_READ 1#define EVENT_WRITE 2// 定义连接信息结构体struct conn_info {    int fd;    int event;};// 设置接受连接事件intset_event_accept(struct io_uring *ring, int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags){    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);    struct conn_info accept_info = {.fd = sockfd, .event = EVENT_ACCEPT};    io_uring_prep_accept(sqe, sockfd, (struct sockaddr*)addr, addrlen, flags);    memcpy(&sqe->user_data, &accept_info, sizeof(struct conn_info));    return 0;}// 设置读取事件intset_event_recv(struct io_uring *ring, int sockfd, char *buffer, size_t len, int flags){    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);    struct conn_info recv_info = {.fd = sockfd, .event = EVENT_READ};    io_uring_prep_recv(sqe, sockfd, buffer, len, 0);    memcpy(&sqe->user_data, &recv_info, sizeof(struct conn_info));    return 0;}// 设置写入事件intset_event_send(struct io_uring *ring, int sockfd, char *buffer, size_t len, int flags){    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);    struct conn_info send_info = {.fd = sockfd, .event = EVENT_WRITE};    io_uring_prep_send(sqe, sockfd, buffer, len, 0);    memcpy(&sqe->user_data, &send_info, sizeof(struct conn_info));    return 0;}intmain(){    struct io_uring ring;    struct io_uring_params params;    memset(&params, 0, sizeof(params));    params.flags |= IORING_SETUP_SQPOLL; // 启用 SQ Polling 模式    // 初始化 io_uring    if (io_uring_queue_init_params(QUEUE_DEPTH, &ring, &params) < 0) {        perror("io_uring_queue_init_params");        return 1;    }    // 创建监听 socket    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);    if (listen_fd < 0) {        perror("socket");        io_uring_queue_exit(&ring);        return 1;    }    struct sockaddr_in server_addr;    memset(&server_addr, 0, sizeof(server_addr));    server_addr.sin_family = AF_INET;    server_addr.sin_addr.s_addr = htonl(INADDR_ANY);    server_addr.sin_port = htons(8888);    // 绑定 socket    if (bind(listen_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {        perror("bind");        close(listen_fd);        io_uring_queue_exit(&ring);        return 1;    }    // 监听 socket    if (listen(listen_fd, 10) < 0) {        perror("listen");        close(listen_fd);        io_uring_queue_exit(&ring);        return 1;    }    // 设置接受连接事件    struct sockaddr_in client_addr;    socklen_t client_addr_len = sizeof(client_addr);    set_event_accept(&ring, listen_fd, (struct sockaddr*)&client_addr, &client_addr_len, 0);    while (1) {        // 提交请求（在 SQ Polling 模式下，这一步可以省略，内核会自动轮询 SQ）        io_uring_submit(&ring);        struct io_uring_cqe *cqe;        // 等待完成事件        if (io_uring_wait_cqe(&ring, &cqe) < 0) {            perror("io_uring_wait_cqe");            continue;        }        struct conn_info result;        memcpy(&result, &cqe->user_data, sizeof(struct conn_info));        if (result.event == EVENT_ACCEPT) {            int client_fd = cqe->res;            printf("Accepted client: %d\n", client_fd);            char buffer[BUFFER_SIZE];            // 设置读取事件            set_event_recv(&ring, client_fd, buffer, sizeof(buffer), 0);        } else if (result.event == EVENT_READ) {            int client_fd = result.fd;            int ret = cqe->res;            if (ret > 0) {                char buffer[BUFFER_SIZE];                memcpy(buffer, &cqe->res, ret);                printf("Received from client %d: %.*s\n", client_fd, ret, buffer);                // 设置写入事件，回显数据                set_event_send(&ring, client_fd, buffer, ret, 0);            } else if (ret == 0) {                // 连接关闭                close(result.fd);                printf("Client %d disconnected\n", client_fd);            } else {                perror("read");                close(result.fd);            }        } else if (result.event == EVENT_WRITE) {            int client_fd = result.fd;            int ret = cqe->res;            printf("Sent to client %d: %d bytes\n", client_fd, ret);            char buffer[BUFFER_SIZE];            // 设置读取事件            set_event_recv(&ring, client_fd, buffer, sizeof(buffer), 0);        }        // 标记 CQE 已处理        io_uring_cqe_seen(&ring, cqe);    }    // 释放资源    close(listen_fd);    io_uring_queue_exit(&ring);    return 0;}

在这个例子中，通过在初始化 io_uring 时设置 IORING_SETUP_SQPOLL 标志启用了 SQ Polling 模式。内核会自动轮询 SQ，处理新的连接请求和数据收发请求，使得服务器能够更快速地响应客户端的操作，提升了实时性和性能 。

3.4 灵活通知机制

io_uring 支持多种通知模式，包括事件驱动和轮询模式，这使得它能够适应不同应用场景的需求。在事件驱动模式下，io_uring 可以与传统的事件通知机制（如 epoll）相结合，应用程序可以通过 epoll 等待 io_uring 的完成队列（CQ）上的事件，当有 I/O 操作完成时，epoll 会通知应用程序。这种模式适用于那些已经基于 epoll 构建的应用程序，它们可以逐步引入 io_uring，而无需对整体架构进行大规模的改动 。

例如，假设有一个基于 epoll 的 Web 服务器，想要引入 io_uring 来提升 I/O 性能，可以这样实现：

#include <liburing.h>#include <sys/epoll.h>#include <sys/socket.h>#include <arpa/inet.h>#include <unistd.h>#include <stdio.h>#include <string.h>#define QUEUE_DEPTH 128#define BUFFER_SIZE 1024#define EPOLL_SIZE 1024// 定义事件类型#define EVENT_ACCEPT 0#define EVENT_READ 1#define EVENT_WRITE 2// 定义连接信息结构体struct conn_info {    int fd;    int event;};// 设置接受连接事件intset_event_accept(struct io_uring *ring, int sockfd, struct sockaddr *addr, socklen_t *addrlen, int flags){    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);    struct conn_info accept_info = {.fd = sockfd, .event = EVENT_ACCEPT};    io_uring_prep_accept(sqe, sockfd, (struct sockaddr*)addr, addrlen, flags);    memcpy(&sqe->user_data, &accept_info, sizeof(struct conn_info));    return 0;}// 设置读取事件intset_event_recv(struct io_uring *ring, int sockfd, char *buffer, size_t len, int flags){    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);    struct conn_info recv_info = {.fd = sockfd, .event = EVENT_READ};    io_uring_prep_recv(sqe, sockfd, buffer, len, 0);    memcpy(&sqe->user_data, &recv_info, sizeof(struct conn_info));    return 0;}// 设置写入事件intset_event_send(struct io_uring *ring, int sockfd, char *buffer, size_t len, int flags){    struct io_uring_sqe *sqe = io_uring_get_sqe(ring);    struct conn_info send_info = {.fd = sockfd, .event = EVENT_WRITE};    io_uring_prep_send(sqe, sockfd, buffer, len, 0);    memcpy(&sqe->user_data, &send_info, sizeof(struct conn_info));    return 0;}intmain(){    struct io_uring ring;    struct io_uring_params params;    memset(&params, 0, sizeof(params));    // 可根据需求启用 SQ Polling 模式    // params.flags |= IORING_SETUP_SQPOLL;    // 初始化 io_uring    if (io_uring_queue_init_params(QUEUE_DEPTH, &ring, &params) < 0) {        perror("io_uring_queue_init_params");        return 1;    }    // 创建 epoll 实例    int epoll_fd = epoll_create1(0);    if (epoll_fd < 0) {        perror("epoll_create1");        io_uring_queue_exit(&ring);        return 1;    }    // 创建监听 socket    int listen_fd = socket(AF_INET, SOCK_STREAM, 0);    if (listen_fd < 0) {        perror("socket");        close(epoll_fd);        io_uring_queue_exit(&ring);        return 1;    }    struct sockaddr_in server_addr;    memset(&server_addr, 0, sizeof(server_addr));    server_addr.sin_family = AF_INET;    server_addr.sin_addr.s_addr = htonl(INADDR_ANY);    server_addr.sin_port = htons(8888);    // 绑定 socket    if (bind(listen_fd, (struct sockaddr*)&server_addr, sizeof(server_addr)) < 0) {        perror("bind");        close(listen_fd);        close(epoll_fd);        io_uring_queue_exit(&ring);        return 1;    }    // 监听 socket    if (listen(listen_fd, 10) < 0) {        perror("listen");        close(listen_fd);        close(epoll_fd);        io_uring_queue_exit(&ring);        return 1;    }    // 将监听 socket 添加到 epoll    struct epoll_event ev;    ev.events = EPOLLIN;    ev.data.fd = listen_fd;    if (epoll_ctl(epoll_fd, EPOLL_CTL_ADD, listen_fd, &ev) < 0) {        perror("epoll_ctl");        close(listen_fd);        close(epoll_fd);        io_uring_queue_exit(&ring);        return 1;    }    // 设置接受连接事件    struct sockaddr_in client_addr;    socklen_t client_addr_len = sizeof(client_addr);    set_event_accept(&ring, listen_fd, (struct sockaddr*)&client_addr, &client_addr_len, 0);    struct epoll_event events[EPOLL_SIZE];    while (1) {        // 等待 epoll 事件        int nfds = epoll_wait(epoll_fd, events, EPOLL_SIZE, -1);        if (nfds < 0) {            perror("epoll_wait");            continue;        }        for (int i = 0; i < nfds; i++) {            if (events[i].data.fd == listen_fd) {                // 有新连接，重新设置接受连接事件                set_event_accept(&ring, listen_fd, (struct sockaddr*)&client_addr, &client_addr_len, 0);                io_uring_submit(&ring);            } else {                // 处理 io_uring 完成事件                struct io_uring_cqe *cqe;                if (io_uring_peek_cqe(&ring, &cqe) == 0) {                    struct conn_info result;                    memcpy(&result, &cqe->user_data, sizeof(struct conn_info));                    // 处理读写事件逻辑（同前文）                    io_uring_cqe_seen(&ring, cqe);                }            }        }    }    // 释放资源    close(listen_fd);    close(epoll_fd);    io_uring_queue_exit(&ring);    return 0;}

其中，entries 参数指定了提交队列（SQ）和完成队列（CQ）的大小，通常建议设置为 2 的幂次方，以提高内存访问效率。ring 参数是一个指向 struct io_uring 结构体的指针，用于存储 io_uring 的相关信息。flags 参数则用于设置一些特殊标志，例如 IORING_SETUP_SQPOLL 标志用于启用内核轮询模式 。

下面是一个简单的初始化示例：

#include <liburing.h>#include <stdio.h>intmain(){    struct io_uring ring;    int ret = io_uring_queue_init(128, &ring, IORING_SETUP_SQPOLL);    if (ret < 0) {        perror("io_uring_queue_init");        return 1;    }    // 后续操作...    io_uring_queue_exit(&ring);    return 0;}

在这个示例中，我们创建了一个大小为 128 的 io_uring 实例，并启用了内核轮询模式 。初始化完成后，io_uring 的提交队列和完成队列就已经准备好接收和处理 I/O 请求了 。

3.5 多线程环境下的 io_uring

在多线程环境下使用 io_uring 时，虽然它能带来高性能的 I/O 处理能力，但也面临一些挑战，其中最主要的就是线程安全问题。由于多个线程可能同时访问和操作共享的 io_uring 实例（包括提交队列 SQ 和完成队列 CQ），如果不加控制，就会出现竞态条件，导致数据不一致或程序崩溃。

比如，多个线程同时向 SQ 队列中提交 I/O 请求时，可能会出现请求顺序混乱、覆盖等问题；在从 CQ 队列中获取完成结果时，也可能出现多个线程同时读取同一个结果项的情况。为了解决这些问题，可以采用多种同步机制。互斥锁是一种常用的方法，在多线程环境下，对 io_uring 实例的访问进行加锁保护。当一个线程要向 SQ 队列提交请求或从 CQ 队列获取结果时，先获取互斥锁，操作完成后再释放锁，这样可以保证同一时刻只有一个线程能够访问 io_uring 实例 。

以 C 语言代码为例，使用 POSIX 线程库的互斥锁来保护 io_uring 操作：

#include <pthread.h>#include <liburing.h>// 定义互斥锁pthread_mutex_t io_uring_mutex;// 定义 io_uring 实例struct io_uring ring;// 线程函数void* thread_func(void* arg){    // 加锁    pthread_mutex_lock(&io_uring_mutex);    // 向 io_uring 提交请求或获取结果等操作    struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);    if (!sqe) {        // 处理错误    }    // 填充请求参数等    io_uring_prep_read(sqe, fd, buf, BUF_SIZE, 0);    int ret = io_uring_submit(&ring);    if (ret < 0) {        // 处理错误    }    // 解锁    pthread_mutex_unlock(&io_uring_mutex);    return NULL;}intmain(){    // 初始化互斥锁    pthread_mutex_init(&io_uring_mutex, NULL);    // 初始化 io_uring 实例    int ret = io_uring_queue_init(QUEUE_DEPTH, &ring, 0);    if (ret < 0) {        // 处理错误    }    pthread_t tid1, tid2;    // 创建线程    pthread_create(&tid1, NULL, thread_func, NULL);    pthread_create(&tid2, NULL, thread_func, NULL);    // 等待线程结束    pthread_join(tid1, NULL);    pthread_join(tid2, NULL);    // 销毁互斥锁    pthread_mutex_destroy(&io_uring_mutex);    // 释放 io_uring 实例    io_uring_queue_exit(&ring);    return 0;}

无锁队列也是一种可选方案，无锁队列使用原子操作和内存屏障等技术来实现线程安全的队列操作，避免了传统锁机制带来的性能开销，在高并发场景下具有更好的性能表现。一些高性能的网络库中，就会使用无锁队列来管理 I/O 请求，结合 io_uring 可以进一步提升网络 I/O 的处理能力。在实际应用中，需要根据具体的场景和需求选择合适的同步机制，以充分发挥 io_uring 在多线程环境下的优势。

四、io_uring 工作流程

面试题写作模版

io_uring 的高效运作依赖于一套清晰的异步 I/O 处理流程，核心围绕提交队列（SQ）与完成队列（CQ）的协同工作，贯穿应用程序与内核的交互全链路。整个流程可分为四个关键阶段：初始化阶段、请求提交阶段、内核处理阶段、结果处理阶段，各阶段环环相扣，最大限度减少开销，提升 I/O 效率。

4.1 初始化阶段

在使用 io_uring 进行任何 I/O 操作前，需先完成初始化工作，核心是创建并配置 io_uring 实例，建立用户态与内核态共享的环形队列。这一步通过 io_uring_queue_init 或 io_uring_queue_init_params 函数实现，前者适用于基础配置，后者支持更精细的参数定制（如启用 SQ Polling 模式）。

初始化过程中，内核会为 io_uring 分配共享内存区域，用于存储 SQ、CQ 及相关元数据。SQ 和 CQ 的大小由初始化参数指定，通常建议设置为 2 的幂次方，以优化内存访问效率。同时，内核会初始化队列的索引指针（如 SQ 尾指针、CQ 头指针），为后续请求提交与结果回收做好准备。

对于需要特殊配置的场景，可通过 struct io_uring_params 结构体设置标志位。例如，IORING_SETUP_SQPOLL 启用内核轮询模式，IORING_SETUP_IOPOLL 启用 I/O 轮询模式（适用于 NVMe 等高速存储设备）。初始化完成后，应用程序与内核即可通过共享队列实现无拷贝通信，无需频繁触发系统调用来传递请求或结果。

#include <liburing.h>#include <stdio.h>intmain() {    struct io_uring ring;    struct io_uring_params params;    memset(&params, 0, sizeof(params));    // 启用 SQ Polling 模式，同时设置轮询线程优先级    params.flags |= IORING_SETUP_SQPOLL;    params.sq_thread_priority = 10; // 数值越小优先级越高    // 初始化 io_uring，队列深度为 128    int ret = io_uring_queue_init_params(128, &ring, &params);    if (ret < 0) {        perror("io_uring_queue_init_params");        return 1;    }    // 业务逻辑处理...    // 资源清理    io_uring_queue_exit(&ring);    return 0;}

4.2 请求 I/O 提交

请求提交是应用程序向内核发起 I/O 操作的核心步骤，需经过“获取 SQE→配置请求参数→提交请求”三步，支持单请求提交或批量提交，批量提交可大幅减少系统调用次数，降低上下文切换开销。

1. 获取空闲 SQE：应用程序通过 io_uring_get_sqe 函数从 SQ 中获取一个空闲的提交队列条目（SQE）。该函数会检查 SQ 是否有可用空间，若队列已满则返回 NULL，因此实际开发中需做好空队列判断，避免请求丢失。SQE 是描述 I/O 请求的核心结构体，包含操作类型、文件描述符、缓冲区地址、长度、偏移量及用户数据等字段。
2. 配置 SQE 参数：根据具体 I/O 操作类型，调用对应的封装函数配置 SQE。例如，文件读取用 io_uring_prep_read，文件写入用 io_uring_prep_write，网络接收用 io_uring_prep_recv，接受连接用 io_uring_prep_accept 等。同时，可通过 sqe->user_data 字段设置自定义标识（如请求 ID、关联数据指针），方便后续匹配请求与结果。
3. 批量提交请求：配置完成的 SQE 会被写入 SQ，应用程序通过 io_uring_submit 函数将 SQ 中的所有待处理请求批量提交给内核。该函数返回实际提交的请求数量，若启用 SQ Polling 模式，内核会主动轮询 SQ 新请求，无需显式调用此函数，进一步减少系统调用开销。

批量提交场景下，应用程序可循环获取并配置多个 SQE，再一次性提交，相比逐个提交请求，能将系统调用次数从 N 次减少到 1 次，在高并发场景下性能提升显著。

#include <liburing.h>#include <fcntl.h>#include <unistd.h>#include <stdio.h>#include <string.h>#define BUFFER_SIZE 4096#define BATCH_NUM 8intmain(){    struct io_uring ring;    int ret = io_uring_queue_init(BATCH_NUM, &ring, 0);    if (ret < 0) {        perror("io_uring_queue_init");        return 1;    }    // 打开 8 个文件，批量提交读取请求    int fds[BATCH_NUM];    char buffers[BATCH_NUM][BUFFER_SIZE];    for (int i = 0; i < BATCH_NUM; i++) {        char filename[32];        snprintf(filename, sizeof(filename), "file%d.txt", i);        fds[i] = open(filename, O_RDONLY);        if (fds[i] < 0) {            perror("open");            // 出错时清理已打开的文件描述符            for (int j = 0; j < i; j++) close(fds[j]);            io_uring_queue_exit(&ring);            return 1;        }        // 获取 SQE 并配置读取请求        struct io_uring_sqe *sqe = io_uring_get_sqe(&ring);        io_uring_prep_read(sqe, fds[i], buffers[i], BUFFER_SIZE, 0);        // 存入文件索引作为用户数据，用于后续匹配结果        sqe->user_data = i;    }    // 批量提交 8 个读取请求    ret = io_uring_submit(&ring);    if (ret < 0) {        perror("io_uring_submit");        for (int i = 0; i < BATCH_NUM; i++) close(fds[i]);        io_uring_queue_exit(&ring);        return 1;    }    printf("Successfully submitted %d requests\n", ret);    // 后续结果处理...    return 0;}

4.3 内核处理阶段

内核在收到应用程序提交的 I/O 请求后，进入异步处理流程，全程无需阻塞应用程序，实现“发起即返回”的异步特性。内核处理逻辑围绕 SQ 的消费与 CQ 的生成展开，具体分为三步：

1. 消费 SQ 请求：内核通过轮询 SQ 的尾指针（由应用程序更新），感知新提交的请求。对于普通模式，内核在应用程序调用 io_uring_submit 后触发处理；对于 SQ Polling 模式，内核会启动专门的线程持续轮询 SQ，一旦发现新请求立即处理，延迟更低。内核会按顺序读取 SQ 中的 SQE，解析操作类型、文件描述符、缓冲区等参数，验证请求合法性（如权限、缓冲区地址有效性）。
2. 异步执行 I/O 操作：内核根据 SQE 配置的参数，异步执行对应的 I/O 操作。例如，文件 I/O 会通过页缓存或直接 I/O（O_DIRECT）与存储设备交互，网络 I/O 则通过套接字缓冲区与网卡交互。在此过程中，内核会释放当前处理上下文，不阻塞应用程序，同时持续监控 I/O 操作进度，待硬件或底层驱动完成操作后，触发回调逻辑。
3. 生成 CQE 并写入 CQ：I/O 操作完成后，内核会生成一个完成队列条目（CQE），记录操作结果。CQE 中的 res 字段表示操作状态：大于等于 0 表示成功，值为实际传输的字节数；小于 0 表示失败，绝对值为错误码。同时，内核会将 SQE 中的 user_data 原样复制到 CQE 中，方便应用程序关联请求与结果。最后，内核更新 CQ 的尾指针，通知应用程序有完成事件待处理。

值得注意的是，内核处理请求时会保证 SQ 与 CQ 的顺序无关性——请求提交顺序与完成顺序可能不一致，应用程序需通过 user_data 字段匹配请求与结果，而非依赖队列顺序。

4.4 处理完成事件

应用程序通过从完成队列（CQ）中获取完成队列条目（CQE）来处理 I/O 操作的完成事件，主要包括以下步骤：

（1）获取 CQE：应用程序可以使用 io_uring_wait_cqe 函数阻塞等待完成事件，直到有 CQE 可用，函数原型为：

intio_uring_wait_cqe(struct io_uring *ring, struct io_uring_cqe **cqe);

ring 参数指向 io_uring 实例，cqe 是一个指针的指针，用于返回获取到的 CQE 。也可以使用 io_uring_peek_cqe 函数非阻塞地检查是否有完成事件，函数原型为：

intio_uring_peek_cqe(struct io_uring *ring, struct io_uring_cqe **cqe);

如果有可用的 CQE，函数返回 0，并将 cqe 指向该 CQE；如果没有可用的 CQE，函数返回 - 1 。

（2）处理结果：获取到 CQE 后，应用程序可以根据 CQE 中的 res 字段判断 I/O 操作是否成功。如果 res 大于等于 0，表示操作成功，res 的值即为实际传输的字节数；如果 res 小于 0，表示操作失败，-res 的值为错误码，可以通过 strerror 函数将错误码转换为错误信息 。同时，应用程序可以通过 CQE 中的 user_data 字段获取提交请求时设置的用户数据，以便进行相应的处理 。

（3）标记 CQE 已消费：在处理完 CQE 后，应用程序需要调用 io_uring_cqe_seen 函数标记该 CQE 已被消费，以便内核可以回收相关资源并继续处理后续的完成事件，函数原型为：

voidio_uring_cqe_seen(struct io_uring *ring, struct io_uring_cqe *cqe);

ring 参数指向 io_uring 实例，cqe 是已处理的 CQE 。

下面是一个处理完成事件的示例：

#include <liburing.h>#include <stdio.h>#include <string.h>intmain(){    struct io_uring ring;    // 初始化 io_uring（省略）    struct io_uring_cqe *cqe;    int ret = io_uring_wait_cqe(&ring, &cqe);    if (ret < 0) {        perror("io_uring_wait_cqe");        return 1;    }    if (cqe->res >= 0) {        printf("Operation succeeded, transferred %d bytes\n", cqe->res);    } else {        printf("Operation failed, errno = %d\n", -cqe->res);    }    // 标记 CQE 已处理    io_uring_cqe_seen(&ring, cqe);    return 0;}

在这个示例中，我们使用 io_uring_wait_cqe 等待完成事件，获取 CQE 后检查操作结果，并标记 CQE 已被处理 。通过以上四个阶段的协同工作，io_uring 实现了高效的异步 I/O 处理流程，大大提升了系统在高并发场景下的 I/O 性能 。

五、io_uring 与 epoll 对比

面试题写作模版

epoll 作为 I/O 多路复用技术的典型代表，在高并发场景中曾大放异彩，是很多高性能网络服务的基石。但 io_uring 的出现，给传统的 epoll 带来了新的挑战和对比。

5.1 系统调用次数差异

在 epoll 模型中，每次 I/O 操作都需要多次系统调用 。以网络通信为例，当有新的连接到来时，需要先调用 epoll_wait () 等待事件发生，然后在事件处理函数中调用 accept () 接受连接，之后进行数据读写时又要分别调用 read () 和 write () 等系统调用 。在一个处理大量并发连接的服务器中，每一次新连接的到来和数据的读写都伴随着多次系统调用，这些系统调用的开销在高并发场景下会累积起来，严重影响系统性能 。

而 io_uring 通过提交队列和完成队列的设计，极大地减少了系统调用次数 。用户态将 I/O 请求封装成 SQE 放入提交队列后，只需一次 io_uring_enter () 调用通知内核处理，内核处理完成后将结果放入完成队列，用户态再通过一次调用从完成队列获取结果 。在处理大量 I/O 请求时，io_uring 的这种方式大大减少了系统调用的开销，就像减少了在不同房间之间穿梭的次数，节省了时间和精力 。

5.2 异步处理能力对比

epoll 虽然提供了一定的异步处理能力，通过边缘触发（ET）模式可以减少不必要的事件通知，但本质上还是基于事件就绪通知 。这意味着应用程序需要不断地轮询或等待事件就绪，在事件处理过程中仍然可能会出现阻塞 。在处理大量并发连接时，即使使用 ET 模式，当有大量连接同时有数据可读或可写时，应用程序在处理这些事件时可能会因为某些复杂的业务逻辑而阻塞，影响其他连接的处理 。

io_uring 则实现了真正的异步 I/O，应用程序提交 I/O 请求后无需等待操作完成，内核会在后台处理这些请求，完成后通过完成队列通知应用程序 。这使得应用程序可以在 I/O 操作执行期间继续执行其他任务，大大提高了系统的并发处理能力 。在一个需要同时处理大量文件读写和网络通信的服务器中，io_uring 可以让应用程序在提交 I/O 请求后，立即处理其他请求，而不需要等待文件读写或网络通信完成，提高了系统的整体效率 。

5.3 操作支持范围

epoll 主要用于监视文件描述符的事件，如可读、可写等，对于一些复杂的系统调用，如 open ()、fsync () 等，虽然可以通过一些间接的方式实现，但操作较为繁琐 。在处理文件系统相关的操作时，epoll 需要结合其他机制来实现对文件的异步操作，不够直接和高效 。

io_uring 则对各种系统调用提供了全面的支持，无论是文件读写、网络通信，还是文件系统操作，都可以通过 io_uring 进行高效的异步处理 。它可以直接将 open ()、fsync () 等系统调用封装成 SQE 提交到提交队列，实现真正的异步操作 。在一个需要频繁进行文件打开、读写和同步操作的应用程序中，io_uring 可以简化代码逻辑，提高操作效率 。

六、io_uring 性能优化之道

面试题写作模版

6.1 合理设置队列深度

队列深度是 io_uring 中的一个重要参数，它决定了提交队列（SQ）和完成队列（CQ）的大小。合理设置队列深度对于 io_uring 的性能至关重要。如果队列深度设置得过小，当有大量 I/O 请求时，队列可能会很快被填满，导致新的请求无法及时提交，从而影响系统的并发处理能力；如果队列深度设置得过大，虽然可以容纳更多的 I/O 请求，但会占用更多的内存资源，并且在处理完成队列项（CQE）时，可能会增加查找和处理的时间 。

在实际场景中，需要根据系统的负载情况、硬件资源以及 I/O 请求的特点来合理设置队列深度。对于高并发的 Web 服务器，由于需要处理大量的并发连接和 I/O 请求，可以适当增大队列深度，以充分利用系统的资源。例如，在一个拥有多个 CPU 核心和大量内存的服务器上，可以将队列深度设置为 1024 或更高。而对于一些对内存资源比较敏感的嵌入式系统，或者 I/O 请求量相对较小的应用场景，则可以将队列深度设置得较小，如 64 或 128 。

6.2 巧用 SQPOLL 模式

SQPOLL 模式是 io_uring 提供的一种高性能模式，它通过内核线程轮询提交队列，实现了零系统调用开销路径，从而大大提高了 I/O 操作的效率。在传统的 I/O 模型中，每次 I/O 操作都需要进行系统调用，从用户态切换到内核态，这会带来一定的开销。而在 SQPOLL 模式下，内核会创建一个专门的线程来轮询提交队列，当有新的 I/O 请求时，直接由内核线程处理，避免了用户态和内核态之间的频繁切换 。

SQPOLL 模式适用于那些需要处理大量 I/O 请求，并且对响应时间要求较高的场景。在高并发的数据库应用中，大量的读写操作需要快速响应，使用 SQPOLL 模式可以显著提高数据库的性能。要启用 SQPOLL 模式，需要在初始化 io_uring 时设置 IORING_SETUP_SQPOLL 标志位，还可以通过 sq_thread_idle 参数设置内核线程的空闲超时时间，通过 sq_thread_cpu 参数将内核线程绑定到指定的 CPU 核心 ，以进一步优化性能。

6.3 缓冲区管理策略

缓冲区管理是 io_uring 性能优化的另一个重要方面。在 io_uring 中，通过缓冲区预注册，可以避免内核重复拷贝数据，提高数据传输的效率。在传统的 I/O 操作中，数据往往需要在用户空间和内核空间之间多次拷贝，这不仅增加了数据传输的时间，也消耗了系统资源。而 io_uring 通过预注册缓冲区，使得内核可以直接访问用户空间的缓冲区，减少了数据拷贝的次数 。

为了充分发挥缓冲区预注册的优势，需要合理管理缓冲区的大小和数量。缓冲区的大小应该根据实际的 I/O 需求来确定，过大或过小都可能影响性能。如果缓冲区过大，会浪费内存资源；如果缓冲区过小，可能需要频繁地进行缓冲区的分配和释放，增加系统开销。要注意减少内存碎片的产生，可以采用内存池等技术来管理缓冲区的分配和释放 。

6.4 多线程与 io_uring 的协同

在多线程环境下，io_uring 的无锁批量提交机制可以完美适配多线程 / 协程调度器，充分发挥多线程的优势。多个线程可以同时向 io_uring 提交 I/O 请求，而无需担心锁竞争的问题，从而提高了多线程环境下的 I/O 性能。

在多线程使用 io_uring 时，也有一些注意事项和最佳实践。不同线程提交的 I/O 请求之间可能存在依赖关系，需要合理地进行同步和协调。要注意线程安全问题，避免多个线程同时访问和修改同一个 io_uring 实例的资源。为了提高性能，可以将不同类型的 I/O 请求分配到不同的线程中处理，实现线程的分工协作 。

七、io_uring 应用案例及实战

面试题写作模版

7.1io_uring 应用案例

（1）高性能网络服务

在高性能网络服务领域，io_uring 的应用为提升并发处理能力和响应速度带来了显著效果。以著名的 Nginx Web 服务器为例，在引入 io_uring 之前，Nginx 主要依赖 epoll 来处理大量并发连接。随着互联网业务的飞速发展，用户对 Web 服务的响应速度和并发处理能力提出了更高的要求，epoll 在高并发场景下逐渐暴露出性能瓶颈，如上下文切换开销大、事件处理延迟等问题。

为了突破这些限制，Nginx 从 1.19.0 版本开始引入对 io_uring 的支持。通过使用 io_uring，Nginx 能够利用其共享环形队列和批量处理能力，减少系统调用次数和上下文切换开销。在实际测试中，当并发连接数达到 10000 时，使用 io_uring 的 Nginx 服务器吞吐量相比使用 epoll 提升了约 30%，平均响应时间降低了约 20%。这使得 Nginx 能够更高效地处理大量并发请求，为用户提供更快速、稳定的 Web 服务体验 。

再看 API 网关领域，Kong 作为一款广泛使用的开源 API 网关，也在不断探索 io_uring 的应用。API 网关需要在短时间内处理大量的 API 请求，并进行路由、鉴权、限流等操作，对性能要求极高。Kong 通过集成 io_uring，实现了对网络 I/O 的高效处理。在一个包含多个微服务的分布式系统中，使用 io_uring 后的 Kong API 网关能够在高并发情况下，将请求的平均处理时间缩短 15% 以上，有效提升了整个微服务架构的性能和稳定性 。

（2）数据库系统

在数据库系统中，io_uring 的应用也为优化数据读写性能、提高事务处理效率带来了新的突破。以 Limbo 数据库为例，这是一个正在开发中的、进程内 OLTP（在线事务处理）数据库管理系统，兼容 SQLite。Limbo 的核心代码使用 Rust 编写，充分利用了 Rust 在内存安全、并发处理和性能优化方面的优势，同时通过 io_uring 技术实现了高效的异步 I/O 操作 。

在传统的数据库系统中，数据的读写操作往往需要频繁地进行系统调用和数据拷贝，这在高并发事务处理场景下会成为性能瓶颈。Limbo 通过 io_uring，将数据读写请求以异步方式提交到内核，内核在完成操作后将结果异步返回，大大减少了 I/O 操作的等待时间。在一个模拟的高并发事务处理场景中，Limbo 使用 io_uring 后，事务处理的吞吐量相比传统 I/O 方式提升了约 40%，平均事务响应时间降低了约 35% 。这使得 Limbo 在处理大量并发事务时，能够快速响应用户请求，提高数据库的整体性能和可用性 。

（3）大规模文件处理

在文件存储和数据备份等大规模文件处理场景中，io_uring 同样展现出了强大的加速能力。例如，在一个企业级的文件存储系统中，每天需要处理海量的文件读写操作。传统的文件处理方式在面对如此大规模的 I/O 请求时，往往会出现性能瓶颈，导致文件读写速度缓慢，影响业务的正常运行 。

wcp 是一个实验性的开源项目，旨在重新实现类似于标准的 cp 文件复制工具，它利用 io_uring 实现异步 I/O 操作，大幅提升文件复制速度，其速度可以比标准的 cp 命令快高达 70%。该项目通过 io_uring 允许用户进程通过内存中的环形缓冲区异步执行系统调用，从而避免了传统系统调用的开销，同时还使用了大量的 CPU 资源，尽可能地分配内存，以实现最快的复制速度 。在数据备份场景中，使用基于 io_uring 开发的备份工具，能够将备份时间缩短近一半，大大提高了数据备份的效率和及时性 。

7.2io_uring 使用示例（C 语言）

下面是一个完整的 C 语言代码示例，展示如何使用 io_uring 进行文件读取操作：

#include <stdio.h>#include <stdlib.h>#include <fcntl.h>#include <string.h>#include <unistd.h>#include <sys/ioctl.h>#include <linux/io_uring.h>intmain(){    struct io_uring ring;    struct io_uring_sqe *sqe;    struct io_uring_cqe *cqe;    int fd, ret;    // 打开文件    fd = open("example.txt", O_RDONLY);    if (fd < 0) {        perror("Failed to open file");        return 1;    }    // 初始化 io_uring，参数 8 表示队列深度，可以根据实际需求调整，0 表示使用默认设置    io_uring_queue_init(8, &ring, 0);    // 获取一个提交队列条目    sqe = io_uring_get_sqe(&ring);    if (!sqe) {        fprintf(stderr, "Could not get sqe\n");        return 1;    }    // 准备异步读操作，malloc 分配 1024 字节的缓冲区用于存储读取的数据，偏移量为 0 表示从文件开头读取    char *buf = malloc(1024);    io_uring_prep_read(sqe, fd, buf, 1024, 0);    // 提交请求    io_uring_submit(&ring);    // 等待完成    ret = io_uring_wait_cqe(&ring, &cqe);    if (ret < 0) {        perror("io_uring_wait_cqe");        return 1;    }    // 检查结果，cqe->res 大于 0 表示成功读取的字节数，小于 0 表示错误码    if (cqe->res < 0) {        fprintf(stderr, "Async read failed: %s\n", strerror(-cqe->res));        return 1;    } else {        printf("Read %d bytes: %s\n", cqe->res, buf);    }    // 释放资源，标记完成队列项已处理，避免重复处理，关闭 io_uring 队列，关闭文件描述符，释放分配的内存    io_uring_cqe_seen(&ring, cqe);    io_uring_queue_exit(&ring);    close(fd);    free(buf);    return 0;}

1. 文件打开：使用 open 函数打开名为 example.txt 的文件，以只读模式打开，如果打开失败，打印错误信息并返回。
2. io_uring 初始化：通过 io_uring_queue_init 函数初始化 io_uring 结构，设置队列深度为 8 ，这里的队列深度决定了可以同时提交的 I/O 请求数量，一般根据系统资源和实际并发需求来设置，较大的队列深度可以处理更多的并发请求，但也会占用更多的内存。
3. 获取提交队列条目：调用 io_uring_get_sqe 获取一个提交队列条目（SQE），用于构建 I/O 请求。
4. 准备读操作：使用 io_uring_prep_read 函数准备一个异步读操作，指定要读取的文件描述符 fd，读取数据存放的缓冲区 buf，读取的字节数 1024 ，以及文件偏移量 0 。
5. 提交请求：通过 io_uring_submit 函数将构建好的 I/O 请求提交到内核。
6. 等待完成：调用 io_uring_wait_cqe 函数阻塞等待 I/O 操作完成，获取完成队列项（CQE）。
7. 结果处理：检查 CQE 中的结果，如果 cqe->res 小于 0，表示读取失败，打印错误信息；如果大于 0，表示成功读取，打印读取的字节数和数据。
8. 资源释放：使用 io_uring_cqe_seen 标记完成队列项已处理，避免重复处理；通过 io_uring_queue_exit 关闭 io_uring 队列；使用 close 关闭文件描述符；使用 free 释放分配的内存。

7.3 使用 io_uring 的挑战与应对策略

尽管 io_uring 在提升 I/O 性能方面表现出色，但在实际应用中，开发者仍需面对一些挑战，并采取相应的应对策略。

（1）编程复杂度：io_uring 的异步操作和全新接口给开发者带来了一定的编程挑战。由于其异步特性，开发者需要更加关注任务的执行顺序和并发控制，以避免出现竞态条件和数据不一致的问题。与传统 I/O 模型相比，io_uring 的接口设计更为底层和复杂，需要开发者深入理解其工作原理和机制才能熟练运用 。例如，在使用 io_uring 进行文件读写时，开发者需要手动管理提交队列和完成队列，确保请求的正确提交和结果的及时处理。在处理大量并发请求时，这种管理工作变得更加繁琐，容易出错 。

为了应对这一挑战，开发者可以参考官方文档和示例代码，深入学习 io_uring 的工作原理和接口使用方法。同时，一些开源项目如 liburing 提供了更高级的封装，简化了 io_uring 的使用。例如，liburing 的 io_uring_queue_init 函数可以方便地初始化 io_uring 实例，io_uring_get_sqe 函数用于获取提交队列条目，io_uring_submit 函数用于提交 I/O 请求等 。通过使用这些封装函数，开发者可以减少底层细节的处理，降低编程难度 。

（2）兼容性问题：io_uring 是 Linux 内核 5.1 版本引入的特性，这意味着在旧版本内核中无法使用。此外，不同的 Linux 发行版对 io_uring 的支持程度也可能存在差异，某些硬件环境也可能对 io_uring 的性能产生影响 。为了解决兼容性问题，开发者在选择使用 io_uring 时，首先要确保目标系统的内核版本支持 io_uring，至少为 5.1 及以上版本。对于一些不支持 io_uring 的旧系统，可以考虑升级内核版本。在不同的 Linux 发行版中，io_uring 的支持情况可能有所不同，开发者需要查阅相关发行版的文档，了解其对 io_uring 的支持程度和配置方法 。

例如，在 Ubuntu 系统中，可以通过安装 linux-generic-hwe-20.04 或 linux-server-hwe-20.04 等内核更新包来获得 io_uring 支持 。同时，在一些特定的硬件环境下，如老旧的存储设备或网络设备，io_uring 的性能可能无法充分发挥，此时需要对硬件进行升级或优化，以确保 io_uring 能够正常工作并达到预期的性能效果 。

（3）错误处理：在 io_uring 的异步操作中，错误处理至关重要。由于 I/O 请求是异步提交和处理的，错误可能在请求提交后的任意时刻发生，而且错误信息通常在完成队列（CQ）中返回，这增加了错误处理的难度 。例如，在进行文件读取操作时，如果文件不存在或权限不足，io_uring 会在完成队列条目中返回相应的错误码。开发者需要及时从 CQ 中获取这些错误信息，并进行相应的处理，否则可能导致程序出现异常行为 。

为了做好错误处理，开发者应在提交 I/O 请求时，为每个请求设置唯一的标识符（如 user_data 字段），以便在处理完成事件时能够准确地识别对应的请求。在从 CQ 中获取完成队列条目（CQE）后，要仔细检查 cqe->res 字段的值，判断 I/O 操作是否成功。如果 cqe->res 小于 0，表示操作失败，此时应根据-cqe->res 获取错误码，并通过 strerror 函数将错误码转换为可读的错误信息，以便进行针对性的处理 。同时，建议开发者在程序中建立完善的错误日志机制，记录错误信息，便于后续排查和调试 。