长期以来，Linux 的高性能网络编程一直由 epoll
统治。然而，随着硬件性能的飞速增长（NVMe SSD, 100G
网卡），epoll
基于系统调用的开销和内存拷贝逐渐成为瓶颈。2019 年，Linux 5.1
内核引入了
io_uring，这不仅是一个新的系统调用，更是一套全新的异步
I/O 接口设计。
1. 为什么我们需要 io_uring？
在 io_uring 出现之前，Linux 的异步 I/O (AIO)
存在诸多限制：仅支持 Direct I/O，对 Buffered I/O
支持不佳，且 API 设计复杂。大多数高性能服务（如 Nginx,
Redis）依然选择 epoll。
但 epoll 本质上是 Reactor
模型（就绪通知）： 1. 告诉内核我对哪些 fd 感兴趣。
2. 内核告诉我哪些 fd 准备好了。 3.
用户态程序 发起
read/write
系统调用进行实际的数据读写。
这意味着每次读写依然需要一次系统调用，且数据需要在内核态和用户态之间拷贝。
io_uring 则是真正的 Proactor
模型（异步完成）： 1. 告诉内核我要读写哪些
fd，数据放在哪里。 2. 内核在后台完成读写。 3.
内核告诉我操作完成了。
2. 核心架构：双环形缓冲区 (Ring Buffer)
io_uring
的核心设计在于减少系统调用和内存拷贝。它通过在用户态和内核态之间共享两个环形缓冲区来实现这一点：
2.1 提交队列 (Submission Queue, SQ)
用户程序是生产者，内核是消费者。 用户将 I/O 请求（如 “从 fd 3 读取 1024 字节到 buffer A”）打包成 SQE (Submission Queue Entry)，放入 SQ 中。
2.2 完成队列 (Completion Queue, CQ)
内核是生产者，用户程序是消费者。 当 I/O 操作完成后，内核将结果（如 “成功读取 1024 字节”）打包成 CQE (Completion Queue Entry)，放入 CQ 中。
2.3 零系统调用 (Zero Syscall)
在最理想的模式下（IORING_SETUP_SQPOLL），内核会启动一个内核线程轮询
SQ。用户只需将请求写入
SQ，内核线程就会自动发现并处理，无需任何系统调用（io_uring_enter）。这对于高频
I/O 场景是巨大的性能提升。
3. 关键特性
3.1 统一的 I/O 接口
io_uring 不仅支持网络 Socket，还完美支持磁盘
I/O。这意味着我们可以用同一套机制处理网络并发和文件读写，彻底解决了
epoll 无法处理普通文件（总是就绪）的问题。
3.2 批处理能力
你可以一次性提交多个 SQE，然后一次系统调用通知内核处理。同样，你也可以一次性收割多个 CQE。
3.3 内存排序与屏障
由于 SQ 和 CQ
是用户态与内核态共享的内存区域，io_uring
巧妙地利用了内存屏障（Memory
Barriers）来保证数据的一致性，避免了昂贵的锁开销。
4. 总结
io_uring 代表了 Linux I/O
的未来。它不仅仅是性能的提升，更是编程模型的范式转移。从“轮询就绪”到“提交任务”，它让应用程序能够更专注于业务逻辑，将繁重的
I/O 搬运工作彻底交给内核。
在下一篇文章中，我们将详细对比 io_uring 与
epoll
的性能差异，并探讨它们各自的适用场景。