在 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？

  1. 遗留系统维护：代码库庞大，基于 Reactor 模式构建（如 Redis, Nginx 早期版本）。
  2. 连接数极多但活跃度低：epoll 在处理海量空闲连接时依然非常高效。
  3. 内核版本受限：io_uring 需要 Linux 5.1+ (推荐 5.10+)，很多老旧生产环境无法满足。

什么时候转向 io_uring？

  1. 极高性能要求：需要单机处理百万级 QPS，且 CPU 成为瓶颈。
  2. 混合 I/O 场景：既有网络 I/O 又有大量磁盘 I/O（如数据库、存储服务器）。io_uring 统一了这两者。
  3. 新项目开发：没有历史包袱，可以直接采用 Proactor 模式设计架构。

4. 总结

epoll 是一把锋利的瑞士军刀，轻便、通用，足以应付绝大多数场景。 io_uring 则是一台工业级挖掘机，为了吞吐量和效率而生，虽然驾驶它需要更高的技巧（更复杂的内存管理和异步逻辑），但在处理大规模 I/O 时，性能优势非常突出。

上一篇: 01-core-concepts.md - io_uring 核心原理 下一篇: 03-liburing-api.md - liburing 基础 API 详解

返回 io_uring 系列索引

同主题继续阅读

把当前热点继续串成多页阅读，而不是停在单篇消费。

2025-11-30 · io_uring / linux

io_uring 系列文章

探索 Linux 下一代高性能异步 I/O 接口 io_uring，从核心原理到性能对比，再到与现有网络库的集成。