1. io_uring 的诞生背景与核心设计

在 io_uring 出现之前，Linux 上做高性能网络编程的人长期面对一个尴尬的现实：内核其实早就提供了异步 I/O 接口，但真正能用的场景非常有限。理解 io_uring 为什么会被设计成今天这个样子，最好的入口不是直接看它的 API，而是先看清它要解决的那些老问题。

Linux AIO 的局限

Linux 原生 AIO（通常指 io_submit / io_getevents 这一套）在 2.6 内核时代就已引入，但它的适用范围窄得让人意外。最关键的几个限制是：

• 只对部分文件系统真正异步。在 ext4 等常见文件系统上，如果 I/O 没有命中缓存，io_submit 仍可能阻塞提交线程，所谓“异步”名不副实。真正能发挥作用的往往是 O_DIRECT 场景。
• 不支持网络 socket。这是网络编程最致命的短板——AIO 基本只面向文件，无法直接用于 TCP/UDP 收发。
• 每次提交都要系统调用。即使一次提交多个请求，也要陷入内核，请求数量一多，系统调用开销和上下文切换就成为瓶颈。
• 事件获取需要轮询或阻塞。io_getevents 要么阻塞等待，要么反复轮询，难以和事件循环自然融合。

于是实践中大家退回到 epoll + 非阻塞 I/O 的组合。epoll 解决了“哪些 fd 就绪”的问题，但读写本身仍然是同步的：应用要自己发起 read/write，要处理 EAGAIN，要为每个连接维护状态机。当连接数达到十万级、每连接又有多次小 I/O 时，系统调用次数和状态管理的复杂度都会急剧上升。

核心设计：共享环形缓冲区

io_uring 的根本思路，是把“提交请求”和“获取完成”这两件事从系统调用中解放出来，改成用户态与内核态共享内存中的两个环形队列。这就是它名字里 “ring” 的由来。

它由两个队列组成：

• SQ（Submission Queue，提交队列）：用户态把要做的 I/O 请求（SQE，Submission Queue Entry）写进这里，内核从中取出并执行。
• CQ（Completion Queue，完成队列）：内核把执行结果（CQE，Completion Queue Entry）写进这里，用户态从中读取。

关键在于，这两个队列的头部、尾部索引以及队列本身都位于一块由 mmap 映射的共享内存中。用户态写 SQ 的尾指针，内核读它；内核写 CQ 的尾指针，用户态读它。双方通过内存中的索引变化来感知对方进度，而不需要每次操作都陷入内核。

无锁设计与系统调用批处理

因为 SQ 和 CQ 各自只有一个生产者、一个消费者（SQ 是用户态生产、内核消费；CQ 是内核生产、用户态消费），所以可以用简单的原子索引操作实现无锁访问，避免了互斥锁带来的竞争和阻塞。这是 io_uring 在高并发下依然保持低开销的重要原因。

另一个关键设计是系统调用批处理。用户态可以一次性把多个 SQE 填入 SQ，然后只调用一次 io_uring_enter 通知内核“有 N 个新请求”。内核一次陷入就能处理一批请求，把原本 N 次系统调用的开销压缩成 1 次。更进一步，如果开启了 SQPOLL 模式，内核会有一个专门的线程持续轮询 SQ，用户态提交请求时甚至完全不需要系统调用。

下面这张图展示了 io_uring 的整体数据流与队列协作关系：

从“能用”到“好用”的设计取舍

把上面这些机制放在一起看，io_uring 的设计目标就很清楚了：它要同时解决 AIO 的“不异步、不支持网络、系统调用多”三个问题。共享环形缓冲区让提交和完成都不必每次都陷入内核；无锁的单生产单消费模型让高并发下的竞争降到最低；批处理让系统调用次数与请求数量解耦。

对网络编程而言，这意味着一个线程可以用统一的接口同时处理文件 I/O 和 socket 收发，用同一套 SQ/CQ 机制管理成千上万的并发操作，而不必再为每个连接维护复杂的非阻塞状态机。这正是后续章节要展开的编程模型基础。