在经历了前六篇文章的深入学习后，你或许已经对
io_uring
的强大能力深信不疑。但优秀的工程师不应只看到技术的光鲜一面。本文将扮演”魔鬼代言人”的角色，严肃地讨论
io_uring
的代价与短板，以及在哪些真实场景下，老牌的
epoll 反而是更优的选择。
1. 快路径（Fast Path）与延迟的博弈
1.1 epoll 的快路径优势
epoll 的设计极其精简。当数据已经在内核
socket buffer 中就绪时，epoll_wait 返回后，一次
read 系统调用就能直接从 socket buffer
拷贝数据到用户空间。这个路径非常短，CPU cache
友好，延迟可以低至亚微秒级。
而 io_uring
即使在最优情况下，也需要经历完整的请求生命周期：
- 用户态写入 SQE 到共享内存
- 内核消费 SQE、解析操作类型
- 内核执行实际 I/O
- 内核写入 CQE 到共享内存
- 用户态消费 CQE
这条路径虽然避免了系统调用，但环形缓冲区的间接层引入了额外的内存访问和分支预测开销。
1.2 量化对比
在 低并发、Request-Response 模式下（如单连接的 Redis PING-PONG），基准测试数据显示：
| 模式 | P50 延迟 | P99 延迟 |
|---|---|---|
| epoll + read/write | ~1.2 μs | ~3.5 μs |
| io_uring (标准模式) | ~1.8 μs | ~4.2 μs |
| io_uring (SQPOLL) | ~1.1 μs | ~5.8 μs |
关键发现： - 标准模式的
io_uring 在低并发下比 epoll
慢约
50%，因为环形缓冲区操作的固定开销无法被批处理分摊。
- SQPOLL 模式的 P50 延迟最低，但 P99
尾延迟显著增大——内核轮询线程在 CPU
调度上引入了不确定性。
经验法则：当 I/O 深度 ≤ 1 且延迟敏感（如高频交易的信号通路）时，epoll 的快路径往往更优。
2. 内存占用的隐性成本
2.1 Ring Buffer 的固定开销
每个 io_uring
实例需要分配提交队列和完成队列的内存。以默认配置（队列深度
128）为例：
SQ Entries: 128 × 64 bytes = 8 KB
CQ Entries: 256 × 16 bytes = 4 KB
SQ Array: 128 × 4 bytes = 0.5 KB
内核内部结构 ≈ 12 KB
────────────────────────────────────
单个 io_uring 实例合计 ≈ 25 KB对比之下，一个 epoll
实例的内核开销仅为一个红黑树节点加少量元数据，每个被监控的
fd 约 160 字节。
2.2 海量连接场景的放大效应
考虑一个典型的长连接网关，管理 100K 连接，其中 99% 处于空闲状态：
| 方案 | 内存占用 |
|---|---|
| epoll (单实例 + 100K fd) | ~16 MB |
| io_uring (单实例, 深度 4096) | ~1.6 MB |
| io_uring (per-connection ring) | ~2.5 GB ❌ |
显然，如果错误地为每个连接创建独立的
ring（一种常见的新手误区），内存会爆炸。即使使用共享
ring，要高效管理 100K 连接的 user_data
上下文也远比 epoll 的 epoll_data
联合体复杂。
经验法则：对于海量空闲连接（如 WebSocket 长连接、IoT 设备管理），epoll 的轻量级就绪通知模型更加经济。
3. 编程复杂度与可维护性
3.1 状态管理的爆炸
epoll 的 Reactor
模式虽然需要回调，但状态管理相对直观——fd
就绪后，同步执行读写，逻辑是线性的。
io_uring 的 Proactor
模式要求开发者像管理一个异步状态机：每个操作都必须携带上下文（通过
user_data），完成事件可能以任意顺序到达，取消操作
(IORING_OP_ASYNC_CANCEL) 的语义也比
epoll_ctl(EPOLL_CTL_DEL) 复杂得多。
一个实际的对比：
// epoll: 错误处理简单直接
int n = read(fd, buf, sizeof(buf));
if (n < 0) {
if (errno == EAGAIN) return; // 等下次通知
perror("read");
close(fd);
}
// io_uring: 需要在 CQE 回调中处理异步错误
// 此时 fd 可能已经关闭，buffer 可能已经被复用
// 需要通过 user_data 恢复完整上下文
if (cqe->res == -ECANCELED) {
// 请求被取消，但 buffer 可能已被内核部分写入
// 需要额外的状态追踪来决定是否安全复用
}3.2 调试困难
当 io_uring 程序出现 bug 时，常规的
strace
几乎无用——大部分操作不经过系统调用。开发者必须依赖
bpftrace 和内核探针，这要求对 Linux
内核有相当深入的理解。
相比之下，strace -e read,write,epoll_wait
就能清晰地展示 epoll 程序的完整行为。
4. 生态成熟度与兼容性
4.1 内核版本碎片化
io_uring
的功能高度依赖内核版本，不同版本之间的特性差异巨大：
| 特性 | 最低内核版本 |
|---|---|
| 基础 io_uring | 5.1 |
| SQPOLL | 5.4 |
| Provided Buffers | 5.7 |
| Multishot Accept | 5.19 |
| Multishot Recv | 6.0 |
| Zero-Copy Tx | 6.0 |
| Zero-Copy Rx | 6.15 |
在企业级环境中，内核版本往往是 RHEL 8（基于 4.18）或
Ubuntu 20.04（5.4），许多高级特性根本不可用。而
epoll 从 2.5.44 起就稳定存在，几乎在所有生产
Linux 上都可用。
4.2 语言与框架支持
| 生态 | epoll 支持 | io_uring 支持 |
|---|---|---|
| C/C++ | libevent, libev, libuv | liburing, io_uring-go |
| Go | 原生 netpoll (完善) | 第三方库 (实验性) |
| Java | NIO (成熟) | JDK 21+ 实验支持 |
| Python | asyncio (成熟) | 第三方 (不完善) |
| Rust | mio, tokio (成熟) | tokio-uring, monoio (快速发展) |
epoll 的生态经过 20
年打磨，已经深入到几乎所有主流网络框架中。io_uring
虽然发展迅速，但在多数语言中仍处于早期阶段。
5. 安全顾虑：不可忽视的攻击面
正如第一篇所述，io_uring
绕过了传统的系统调用审计路径。这在安全敏感的环境中（金融、政府、医疗）可能是一个严重的问题。
事实上，Google 的 ChromeOS 和 Android
已经默认禁用
io_uring，原因是它显著增大了内核攻击面。Docker
和 Kubernetes 的默认 seccomp profile 同样限制了
io_uring 的使用。
在这些受限环境中，epoll 是唯一的选择。
6. 何时选择 epoll：决策框架
综合以上分析，我们可以提炼出一个实用的决策框架：
┌─────────────────────┐
│ 你的场景是什么？ │
└──────────┬──────────┘
│
┌──────────────┼──────────────┐
▼ ▼ ▼
高吞吐量 I/O 低延迟请求 海量空闲连接
(数据库/存储) (交易系统) (网关/推送)
│ │ │
▼ ▼ ▼
io_uring ✅ epoll ✅ epoll ✅
(快路径优) (内存高效)
│
▼
内核版本 ≥ 5.10?
│ │
Yes No
│ │
▼ ▼
io_uring epoll ✅
(兼容性)一句话总结
| 选 epoll | 选 io_uring |
|---|---|
| 延迟敏感，I/O 深度低 | 吞吐敏感，I/O 深度高 |
| 海量空闲连接 | 活跃连接密集 |
| 内核版本受限 | 内核 ≥ 5.10 |
| 安全合规要求严格 | 性能优先 |
| 团队经验偏传统 | 团队愿意投资新范式 |
7. 总结
技术选型没有银弹。io_uring 在高吞吐、混合
I/O、批量处理等场景下优势显著，但它并非没有代价：更高的内存开销、更陡的学习曲线、更复杂的调试、更窄的兼容性、以及潜在的安全风险。
理解一项技术的边界，比理解它的能力更重要。
当你下次面对技术选型时，不要因为 io_uring 更”新”就盲目选择它。回到问题本身：你的瓶颈到底在哪里？如果答案是”系统调用开销”和”I/O 吞吐量”，那么 io_uring 是你的利器；如果答案是”连接管理”和”延迟抖动”，那么久经考验的 epoll 可能才是正确答案。
上一篇: 06-libevent-support.md - Libevent 对 io_uring 的支持现状