Rust 异步 I/O：从 epoll 到 io_uring，底层机制与选型代价讲清楚

半杯拿铁

发布时间：2026-08-25| 3人浏览过

原创

前言

在 Linux 上做高并发网络服务时，线程模型往往先被上下文切换、内存占用和锁竞争拖住，Rust 异步 I/O 才开始显出价值。但它到底是靠什么提速，又为什么总会连着 Tokio、epoll 甚至 io_uring 一起出现？这篇文章按执行链路、代码实现和工程代价三部分拆开讲，帮你判断该把它当成默认方案，还是只在特定场景下启用。

在 Linux 上做高并发网络服务时，很多人都会先遇到同一个问题：线程模型写起来直观，但连接数一上来，CPU 时间和内存很快就被线程切换、栈空间和锁竞争吃掉。Rust 异步 I/O 常被当成性能答案，不过它并不是简单地“把阻塞改成非阻塞”，而是把编译器生成的状态机、运行时调度和内核事件机制组合到一起。理解 Future 怎么被编译、Tokio 怎么驱动任务，以及 epoll 与 io_uring 各自适合什么场景，才能判断该不该用、该用到什么程度。

线程模型为什么会先撞到天花板

在 Linux 上写高并发网络服务时，“每连接一线程”通常最先失效。连接数一旦过万，线程上下文切换和每个线程的栈内存开销都会迅速放大，系统资源会被非业务逻辑消耗掉。

把模型改成线程池，问题也不会自动消失。线程数量虽然受控了，但锁竞争、条件变量唤醒延迟，以及任务在多个工作线程之间来回调度，依然会限制吞吐量。

这也是 epoll 出现后长期成为 Linux 网络编程标配的原因。它把事件监听从“扫描所有连接”变成“只处理活跃连接”，系统调用复杂度从 O(N) 压到 O(活跃连接数)。但这里要分清一点：epoll 解决的是事件通知效率，不是数据读写本身的成本。应用拿到“可读/可写”通知后，仍然需要再调用 read/write 完成数据拷贝。

Rust 异步 I/O 则是在这个基础上继续往前走。它把 async/await 编译成状态机，让协程切换尽量发生在用户态，再由 Tokio 之类的运行时负责调度和事件驱动。这样做的核心价值，不只是语法更像同步代码，而是把高并发场景下最昂贵的线程切换成本，尽量替换成更轻的任务挂起与恢复。

Future 状态机如何接上事件循环

要理解 Rust 异步为什么能兼顾抽象能力和性能，关键就在于它不是在运行时解释 async 逻辑，而是在编译期直接把异步函数改写成显式状态机。

展示 Rust async 函数被编译成 Future 状态机，并由 Tokio 与内核事件机制驱动的流程信息图 — **Rust 异步任务的执行链路**用流程图串起 async fn、Future、poll、Tokio 与 Linux。

应用代码(async fn)
    ↓ 编译
状态机 Future
    ↓ poll()
Tokio 运行时
    ↓ 注册 fd
epoll/io_uring
    ↓
Linux 内核

这条链路里，应用代码不会直接“睡眠等待 I/O”，而是通过 poll 把执行权交给运行时。如果数据还没准备好，poll 返回 Pending，Tokio 就把当前任务挂起；等内核通过 epoll_wait 或其他后端通知事件已就绪，Tokio 再唤醒对应的 Waker，继续执行同一个 Future。真正读到数据后，才会返回 Poll::Ready。

async fn 是怎么编译成状态机的

编译器遇到 async fn 时，会把原函数体转换成一个实现了 Future trait 的匿名结构体。每一个 .await 都会成为一个状态切换点，相当于把函数拆成多段，等下一次 poll 时从断点继续往下跑。

也就是说，Rust 异步并不是“保存线程栈”，而是把原本在线程栈上的局部变量提升为状态机结构体的字段。只要这些变量要跨越 .await 存活，它们就必须被放进 Future 内部，等待下一轮恢复执行时继续使用。

这也是 Pin 变得重要的根本原因。状态机一旦持有跨 .await 的内部引用，就可能形成自引用关系；如果这个 Future 在内存中被移动，内部指针就会失效。Pin 的作用，就是保证这类对象在被固定后不再随意移动，维持状态机恢复执行时的内存安全前提。

从性能角度看，这种模式的优势在于：协程切换不需要像线程切换那样保存和恢复完整上下文，也不需要为每个任务额外准备一块独立栈空间。抽象层面是 async/await，落到机器执行层面接近手写状态机，因此常被称为“编译器驱动的并发”。

epoll 和 io_uring 到底差在哪

Tokio 在 Linux 上默认使用 epoll 作为 I/O Driver 后端。它的工作方式是“就绪通知”：内核负责告诉应用哪些文件描述符已经可读、可写，但真正的数据收发还是要由应用自己发起系统调用。

这意味着一次典型 I/O 路径里，应用至少会经历“等事件”加“做读写”两个阶段。原文中的表述很直接：每次 I/O 至少两次系统调用，即 epoll_wait 加上 read。

io_uring 的设计思路则明显不同。它通过共享环形缓冲区让用户态和内核态交换请求与结果：应用把 I/O 操作提交到提交队列（SQ），内核完成后再把结果写入完成队列（CQ）。这种模型尽量绕开传统“每一步都要一次系统调用”的交互方式，把系统调用开销压得更低。

从理解上可以把二者概括为：

epoll 更像“先通知你可以做，再由你自己去做”。
io_uring 更像“先把要做的事交给内核，做完后直接告诉你结果”。

这也是为什么在高吞吐、短连接、I/O 非常密集的场景下，io_uring 往往更有吸引力。它减少的不只是等待时间，更是 I/O 路径上的内核切换成本。

实际代码怎么写：Tokio 与 io_uring 两种方式

理解模型之后，再看代码会更清楚：Rust 异步网络服务的主体并不复杂，复杂的是运行时和内核替你承担了多少底层工作。

Tokio 异步 TCP 服务

use tokio::net::{TcpListener, TcpStream};
use tokio::sync::Semaphore;
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use std::sync::Arc;
use std::time::Duration;
struct ServerConfig {
    max_connections: usize,
    read_buffer_size: usize,
    write_timeout: Duration,
}
async fn handle_connection(
    mut stream: TcpStream,
    config: Arc<ServerConfig>,
) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let mut buffer = vec![0u8; config.read_buffer_size];
    loop {
        let n = tokio::time::timeout(
            Duration::from_secs(30),
            stream.read(&mut buffer)
        ).await??;
        if n == 0 {
            break;
        }
        tokio::time::timeout(
            config.write_timeout,
            stream.write_all(&buffer[..n])
        ).await??;
    }
    Ok(())
}
async fn run_server(config: ServerConfig) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let listener = TcpListener::bind("0.0.0.0:8080").await?;
    let config = Arc::new(config);
    let semaphore = Arc::new(Semaphore::new(config.max_connections));
    println!("服务启动，最大并发连接: {}", config.max_connections);
    loop {
        let (stream, addr) = listener.accept().await?;
        let permit = semaphore.clone().acquire_owned().await?;
        let config = config.clone();
        tokio::spawn(async move {
            let _permit = permit;
            if let Err(e) = handle_connection(stream, config).await {
                eprintln!("连接 {} 处理异常: {}", addr, e);
            }
        });
    }
}
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let config = ServerConfig {
        max_connections: 10000,
        read_buffer_size: 8192,
        write_timeout: Duration::from_secs(10),
    };
    run_server(config).await
}

这段代码保留了典型的 Tokio 服务端结构：

监听地址是 0.0.0.0:8080。
最大并发连接数通过 Semaphore 控制为 10000。
读缓冲区大小是 8192 字节。
读取加了 Duration::from_secs(30) 超时保护。
写回超时使用配置项中的 Duration::from_secs(10)。

这里最值得注意的不是 tokio::spawn 本身，而是 Semaphore 的背压作用。每个新连接都要先拿到一个 permit，任务结束后 permit 自动释放。这比“无限接入然后等系统扛不住”更适合作为生产环境默认策略。

另一个工程上很实用的细节，是对 read 和 write_all 分别套上 tokio::time::timeout。在网络服务里，真正拖垮资源的往往不是高峰流量，而是长时间不释放的慢连接。超时机制本质上是在用时间约束换资源稳定性。

io_uring 后端示例

use tokio_uring::net::TcpListener;
use tokio_uring::buf::IoBufMut;
async fn handle_connection_uring(
    stream: tokio_uring::net::TcpStream,
) -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let buffer = vec![0u8; 8192];
    loop {
        let (n, buffer) = stream.read(buffer).await?;
        if n == 0 {
            break;
        }
        let (n, buffer) = stream.write_all(buffer[..n]).await?;
        drop(buffer);
    }
    Ok(())
}
#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    let listener = TcpListener::bind("0.0.0.0:8081").await?;
    println!("io_uring 服务启动");
    loop {
        let (stream, addr) = listener.accept().await?;
        tokio_uring::spawn(async move {
            if let Err(e) = handle_connection_uring(stream).await {
                eprintln!("连接 {} 处理异常: {}", addr, e);
            }
        });
    }
}

这段代码展示的是另一种思路：监听地址改为 0.0.0.0:8081，并使用 tokio_uring 来直接对接 io_uring 后端。

和 Tokio 常规异步 I/O 相比，这里最需要留意的是 buffer 的所有权模型。原文强调，io_uring 模式下 buffer 需要通过 IoBufMut 注册，因为内核要固定 buffer 地址，才能支持直接 DMA。也正因如此，read 和 write 完成时，会把 buffer 的所有权一并返回给调用方，而不是沿用传统 &mut [u8] 那套借用方式。

这类接口设计看上去比普通 Tokio 更“别扭”，但它反映的是底层机制差异：为了减少拷贝和调用开销，运行时必须更明确地管理内存位置与生命周期。对开发者来说，性能收益和心智负担通常是一起到来的。