Rust 异步运行时内幕：从 Future、Waker 到 Tokio 调度实战

为什么异步在 Rust 里是"零成本抽象"

在 C10k 乃至 C10M 时代，传统的"一连接一线程"模型会在上下文切换和内存占用上迅速崩塌。很多人初识 Rust 异步时，会下意识地把它和 JavaScript 的 Promise、Go 的 goroutine 类比——这是最大的认知误区。Rust 的异步是编译期零成本抽象：你不付出运行时的"默认税"，只有在真正需要时才为调度、唤醒付费。

这一切的起点，是一个只有几十行的 trait：

pub trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

注意 poll 的签名：&mut self 被 Pin 包裹，cx 携带唤醒器。它绝不阻塞——要么返回 Poll::Ready(value) 表示计算完成，要么返回 Poll::Pending 并把"我被唤醒后该通知谁"这个责任委托给 Waker。这种"非阻塞轮询"模型，是整个异步生态的基石，也是它和回调地狱、和抢占式协程的本质区别。

Future 不是"任务"，它只是一个状态机

async fn 在 Rust 里并不会真的"运行"任何东西，它只是返回一个实现了 Future 的匿名类型。编译器会把你的 async 块重写成一个状态机：每个 .await 点就是状态机的一个状态，局部变量被提升为状态机的字段。

async fn fetch_and_parse(url: &str) -> anyhow::Result<String> {
    let body = http_get(url).await?;   // 状态 1 -> 状态 2 的迁移
    let title = parse_title(&body)?;    // 同步部分，仍在状态机内
    Ok(title)
}

用 cargo expand（需 cargo install cargo-expand）可以直视这个状态机：编译器生成的结构体里，body 会作为字段存在，状态迁移由 match self.state 驱动。这意味着：异步函数没有独立调用栈，它的大小就是它捕获的局部变量大小，可以被安全地放进一个缓冲区、一个堆块、或跨线程搬运。

一个常见误解是"Future 一旦创建就会执行"。不会。Future 是惰性的，必须被某个运行时 poll 起来才会前进。这给测试带来巨大便利：你可以把一个 Future 直接 block_on 在单元测试里，无需启动整个 Tokio。

#[tokio::test]
async fn parse_works() {
    let r = fetch_and_parse("https://example.com").await;
    assert!(r.is_ok());
}

Waker：唤醒机制的灵魂

当 poll 返回 Pending 时，运行时怎么知道"何时再轮询一次"？答案是 Waker。Waker 内部是一个 RawWaker，指向具体运行时的唤醒实现（vtable：clone / wake / wake_by_ref / drop）。

use std::task::{RawWaker, RawWakerVTable, Waker};

unsafe fn clone(_: *const ()) -> RawWaker { RawWaker::new(std::ptr::null(), &VTABLE) }
unsafe fn wake(_: *const ()) { /* 把任务推回就绪队列 */ }
unsafe fn wake_by_ref(_: *const ()) { wake(std::ptr::null()) }
unsafe fn drop(_: *const ()) {}

static VTABLE: RawWakerVTable = RawWakerVTable::new(clone, wake, wake_by_ref, drop);

关键点在于：Waker 只负责"通知运行时某任务可能就绪"，不负责"立即执行"。这正是背压（back-pressure）能自然实现的原因——当 I/O 还没准备好，任务就安静地停在 Pending，不占 CPU。真正的驱动来自 reactor：Tokio 把文件描述符注册到 mio，后者基于 epoll/kqueue/iocp 监听内核事件，事件触发后调用对应 Waker 唤醒任务。

理解这一点，你就不会再疑惑"为什么我的 async 函数卡住不返回"——十有八九是某处没有把 cx.waker().wake_by_ref() 正确挂到事件源上，导致任务永远等不到唤醒。

Tokio 调度：一个多线程工作窃取运行时

Tokio 的多线程调度器（multi-thread scheduler）是工程上的精华。每个 worker 线程持有一个本地任务队列（LIFO slot + 双端队列），还有一个全局注入队列。新任务优先进入本地队列；本地队列空了，worker 会去偷其他线程队列另一端的任务（work-stealing），从而自动平衡负载。

调度循环伪代码逻辑如下：

loop {
    if let Some(task) = local_queue.pop() {
        task.poll();                 // 执行到 Pending 或完成
    } else if let Some(task) = global_queue.pop() {
        task.poll();
    } else {
        let stolen = steal_from_other_workers();
        if stolen.is_none() { park(); }   // 无任务则休眠，等 Waker 唤醒
    }
}

Tokio 还做了两个关键优化：LIFO 槽保证"刚产出的子任务"优先在当前线程执行（提升缓存局部性），以及coop 预算（cooperative scheduling）：单个任务连续执行过久会被强制让出，防止一个长循环饿死整个线程。这就是为什么你即使写了 loop { yield_now().await; } 也不会卡死调度器——yield_now 正是主动交还执行权。

实战：并发抓取 N 个 URL

一个最能说明"异步省资源"的例子——并发抓取 100 个页面：

use tokio::task;
use reqwest::Client;

async fn crawl(urls: Vec<&str>) -> Vec<(String, usize)> {
    let client = Client::new();
    let mut handles = Vec::new();
    for url in urls {
        let client = client.clone();
        handles.push(task::spawn(async move {
            let body = client.get(url).send().await.unwrap().text().await.unwrap();
            (url.to_string(), body.len())
        }));
    }
    let mut out = Vec::new();
    for h in handles { out.push(h.await.unwrap()); }
    out
}

对比同步版本，同样 100 个请求：同步需要 100 个线程或串行等待 100 倍 RTT；Tokio 用约等价于一核的线程数（num_cpus）就可在毫秒级重叠所有网络等待。但注意——task::spawn 出来的任务是 Send 的（可跨线程），要求捕获的 Future 满足 Send。如果你在 async 块里持有了 Rc 或非 Send 的裸指针，编译器会直接拒绝编译，这恰恰是 Rust 把并发 bug 挡在编译期的体现。

选型的实战观点（避坑清单）

1. CPU 密集任务不要用 async。异步只为"等待"付费。把 fib(40) 塞进 async 函数只会阻塞整个 worker 线程。正确做法是 tokio::task::spawn_blocking 把它丢到专门的阻塞线程池。
2. .await 不要跨越锁。在持有 MutexGuard 时 .await，等于把锁带进了未知时长的挂起，极易死锁。tokio 的 Mutex 允许跨 .await 持有，但它本质是异步锁，竞争激烈时性能不如 std::sync::Mutex + 短临界区。
3. 理解 runtime 选择。#[tokio::main(flavor = "current_thread")] 适合命令行工具/测试（零跨线程开销）；flavor = "multi_thread" 才是服务端默认。误用 current_thread 跑 CPU 密集并发，等于退化成单线程。
4. 小心"异步传染"。一旦底层用了 async，调用链往往被迫全 async。新建库时若不确定，提供 block_on 友好的同步 API 更稳妥。

取消与 Drop 安全：Rust 异步独有的暗坑

tokio::spawn 返回的是 JoinHandle，对它执行 abort() 或让它离开作用域被 drop，任务不会"立刻停止"，而是被标记为取消。此时正在 await 的点会收到一个"取消信号"，状态机退出。drop 一个包含 async 资源的 Future 时，Rust 会按逆序销毁字段——这正是Drop 安全问题的来源：

async fn risky() {
    let mut guard = lock.lock().await;   // 异步锁已持有
    do_io().await;                        // 这里被取消 -> guard 才开始 drop
    guard.update();                       // 这一行可能永远不执行
}

如果 do_io().await 处被取消，guard 会正确 drop（tokio 的 MutexGuard 是取消安全的），所以上面的例子其实没问题；但换成自己手写的资源、或依赖"await 之后一定执行"的清理逻辑，就可能泄漏文件句柄、连接或锁。工程上的铁律是：不要假设 await 之后的代码一定会运行，所有必须释放的资源，要么用 RAII 守卫（离开作用域自动 drop），要么用 tokio::select! 显式处理取消分支：

tokio::select! {
    _ = do_work() => {}
    _ = shutdown_signal() => { cleanup(); }   // 显式处理取消/关闭
}

理解 Drop 安全，是把"能跑的异步代码"升级为"生产级可取消的异步代码"的分水岭。

结语

Rust 异步的门槛不在语法，而在心智模型：Future 是惰性状态机、poll 是非阻塞推进、Waker 是解耦唤醒、调度器用工作窃取自动负载均衡。当你不再把它当作"会自己跑的魔法"，而是当作"一套需要被 poll 的状态机 + 一个负责唤醒的运行时"，那些看似玄学的 hang、deadlock、Send 报错，都会变成可推理、可定位的确定性故障。

2026 年的现实是：Tokio 已稳坐服务端异步运行时王座，但 async-fn-in-trait、更轻量的 embassy（嵌入式/裸机异步）与 WASM 异步仍在拓宽边界。掌握运行时内幕，你才能在"该不该上异步"的工程判断上，给出而非盲从。