在 Linux 高性能网络编程领域，epoll 统治了近
20 年。然而，io_uring
的横空出世打破了这一局面。本文将从原理、性能和适用场景三个维度，深度对比这两代
I/O 神器。
1. 架构模型对比
| 特性 | epoll | io_uring |
|---|---|---|
| 模型 | Reactor (就绪通知) | Proactor (异步完成) |
| 工作流 | 1. 等待 fd 就绪 2. 发起 read/write 系统调用 |
1. 提交 read/write 请求 2. 等待完成通知 |
| 系统调用 | 频繁 (epoll_wait,
read, write) |
极少 (批处理
io_uring_enter 或 0 syscall) |
| 数据拷贝 | 需要 (内核 -> 用户 buffer) | 零拷贝 (支持
IORING_OP_SPLICE 等) |
| 磁盘 I/O | 不支持 (普通文件总是就绪) | 完美支持 (真正的异步磁盘 I/O) |
核心差异：谁在干活？
- epoll: 内核只负责通知。搬运数据（读写内存）的工作由用户线程在收到通知后亲自完成。
- io_uring: 用户只负责下单。搬运数据的工作由内核在后台默默完成，用户线程只负责收货。
2. 性能开销分析
2.1 系统调用 (Syscall)
这是 epoll
最大的痛点。在高并发场景下，每秒百万级的请求意味着百万级的
read/write
系统调用。每次系统调用都涉及上下文切换（Context Switch）和
CPU 模式切换，开销不容小觑。
io_uring 通过 SQ/CQ
环形队列 和 批处理
解决了这个问题。在 SQPOLL
模式下，用户态甚至可以做到 0 系统调用 发送
I/O 请求。
2.2 内存拷贝
epoll 模式下，数据通常需要从网卡 -> 内核
socket buffer -> 用户 buffer。 io_uring
支持注册缓冲区
(IORING_REGISTER_BUFFERS)，允许内核直接锁定用户态内存，减少内核内部的映射开销。
2.3 漏洞缓解 (Spectre/Meltdown)
现代 CPU
为了修复推测执行漏洞，增加了系统调用的开销。这对依赖频繁系统调用的
epoll 打击比 io_uring 更大。
3. 适用场景指南
什么时候坚持用 epoll？
- 遗留系统维护：代码库庞大，基于 Reactor 模式构建（如 Redis, Nginx 早期版本）。
- 连接数极多但活跃度低：
epoll在处理海量空闲连接时依然非常高效。 - 内核版本受限：
io_uring需要 Linux 5.1+ (推荐 5.10+)，很多老旧生产环境无法满足。
什么时候转向 io_uring？
- 极高性能要求：需要单机处理百万级 QPS，且 CPU 成为瓶颈。
- 混合 I/O 场景：既有网络 I/O
又有大量磁盘
I/O（如数据库、存储服务器）。
io_uring统一了这两者。 - 新项目开发：没有历史包袱，可以直接采用 Proactor 模式设计架构。
4. 总结
epoll
是一把锋利的瑞士军刀，轻便、通用，足以应付绝大多数场景。
io_uring
则是一台工业级挖掘机，为了吞吐量和效率而生，虽然驾驶它需要更高的技巧（更复杂的内存管理和异步逻辑），但在处理大规模
I/O 时，它的威力是碾压级的。