异步运行时原理

为什么 Future 需要运行时

前面反复强调:Future 是惰性的,不被 poll 就什么都不做.那么--谁来 poll 它?谁在 IO 就绪时把它重新唤醒?谁来管理成千上万个任务谁先谁后?

这些"驱动 Future 前进"的活儿,没有任何语言内建机制承担(回顾第 01 篇:Rust 故意不内建运行时).于是必须有一个外部组件来做,这就是异步运行时.Tokio 就是其中最主流的一个.

运行时的两半:执行器与反应器

把运行时拆开,核心是分工明确的两个部件:

反应器其实就是第 02 篇讲的"事件循环 + epoll"在运行时里的化身;执行器则是新角色,负责"该 poll 谁,什么时候 poll".waker 是连接这两半的桥梁.

waker:把"就绪"翻译成"重新调度"

第 03 篇说过:Future 返回 Pending 前,要把 Context 里的 waker 登记到它等待的事件源上.现在可以看清这条链的全貌了:

1. 执行器 poll 任务 A
        │
  2. A 发起读 socket,未就绪 → 把 A 的 waker 登记给反应器(epoll)
        │  返回 Pending
  3. 执行器把 A 搁置,转去 poll 其他就绪任务(不空等)
        │
        ⋮ (一段时间后,socket 数据到达)
        │
  4. 反应器的 epoll_wait 返回 → 调用 A 的 waker.wake()
        │
  5. wake() 把任务 A 重新放回执行器的就绪队列
        │
  6. 执行器再次 poll A → 这次读成功 → 继续推进

所以 waker.wake() 的本质动作是:把这个任务标记为"可以再 poll 了",塞回执行器的就绪队列. 它就是"IO 就绪"这个事件,翻译成"请重新调度该任务"这个动作的转换器.

最小心智模型:block_on

最简单的执行器只做一件事:反复 poll 一个 Future,直到它 Ready.这就是 block_on 的核心,伪代码如下(帮助理解,非真实实现):

fn block_on<F: Future>(mut fut: F) -> F::Output {
    loop {
        match fut.poll(cx) {
            Poll::Ready(val) => return val, // 完成,返回结果
            Poll::Pending => {
                // 没就绪:在此挂起线程,直到 waker 通知"可以再 poll 了"
                park_until_woken();
            }
        }
    }
}

真实的执行器要复杂得多(要同时管理海量任务,跨线程调度),但内核思想不变:poll → 没好就等 waker → 被唤醒再 poll.第 04 篇的 #[tokio::main],做的就是"创建运行时,然后 block_on async main".

和 Go runtime 的对照

现在可以把 Rust 运行时与 Go runtime 精确对齐了:

单线程还是多线程?

执行器可以只用一个线程跑事件循环(适合任务少,或想避免跨线程开销),也可以用一个线程池,把任务分散到多个线程上,配合工作窃取(work-stealing)调度.后者能同时利用多核,是服务器场景的默认选择.

这正呼应第 01 篇的结论:异步与多线程是叠加的--多线程执行器 + 海量异步任务.Tokio 默认就是多线程执行器.具体怎么配置,怎么 spawn 任务,下一篇正式上手.