Async on Orangex-position0的技术博客

Tokio Runtime 架构剖析：一个 Task 的诞生与旅程

Mon, 13 Jul 2026 10:00:00 +0800

前言

最近在学习 Rust 时，发现其异步虽然和 JavaScript 的异步模型有相似之处，但 Rust 只提供了异步语法和 Future 抽象，而没有内置运行时，因此需要依赖异步运行时（runtime）来驱动 async 程序运行。

而 Rust 中最流行的异步运行时就是 Tokio。那么今天就来解析一下 Tokio Runtime 的架构，看看它是如何驱动成千上万个异步任务的。

背景 & 问题

Rust 中的 async fn 是惰性的——它编译成一个 Future 状态机，没人 poll 它就永远不执行。那么一个自然的问题来了：

当你写下 #[tokio::main] 并 spawn 成千上万个 task，这些 task 到底是谁在 poll？多核怎么分配？等 IO 时线程为什么没卡死？

要回答这个问题，就得了解 Tokio Runtime 内部，看清它的运作机制，而不是停留在"会用 tokio::spawn“的层面。

如果你想知道这些机制从零怎么造出来，可以看我写的《手写 Rust Async Model》系列；而这一篇反过来——看生产级的 Tokio 是怎么把那些原理工程化的。

能学到什么

Tokio Runtime 的四大组件（Task / Scheduler / Queue / Reactor）各自的角色
混合队列、work-stealing、Park/Unpark 这几套机制如何协作
一条 task 从 spawn 到完成的完整旅程

一段再普通不过的代码

use std::time::Duration;

#[tokio::main]
async fn main() {
 let mut handles = vec![];
 for i in 1..=3 {
 handles.push(tokio::spawn(async move {
 // 每个 task 睡不同的时间后返回编号
 tokio::time::sleep(Duration::from_millis(500 * i as u64)).await;
 i
 }));
 }

 for h in handles {
 println!("done: {}", h.await.unwrap());
 }
}

3 个 task 并发 sleep，代码非常简单，底层却是 tokio runtime 的一套精密协作。下面我们用四个问题把它逐层拆开。

方案：用四个问题拆开 Runtime

先看一张全景图，建立整体印象，再逐个问题深入：

Worker 之间互相 steal，没有中心调度器
Reactor 在底部桥接 OS，事件就绪时唤醒对应 task

Q1：async fn 编译成了 Future，谁来 poll 它？

先明确一个前提：async fn 编译成一个状态机 Future，不主动 poll 就不会执行。Tokio 的回答是 Worker 线程 + Executor。

multi_thread runtime 启动时，会 spawn 一个 worker 线程池，默认数量 = CPU 核心数
每个 worker 线程跑一个调度循环：取 task → poll → 处理结果 → 再取
这个循环，就是 Executor 的本质

#[tokio::main] 宏会把 async fn main 展开成大致这样的同步 main，一次性搭起整套基础设施：

fn main() {
 // 构建一个多线程 runtime：启动 worker 线程池 + Reactor
 let runtime = tokio::runtime::Builder::new_multi_thread()
 .enable_all()
 .build()
 .unwrap();

 // 在 runtime 上阻塞地驱动 async main 这个 Future
 runtime.block_on(async_main());
}

这一步建立了 N 个 worker 线程、各自的 Local Queue、共享的 Global Queue、以及 Reactor，后续所有 task 都在这个环境里跑。

它本质上就是一个 poll 循环（如果你手写过最简 Executor，会立刻认出这个结构），只是从单线程升级成了线程池：

最简版： 一个线程 + 一个就绪队列 + 一个 poll 循环
Tokio： N 个线程 + 每线程一个 Local Queue + work-stealing

Q2：Tokio Runtime 中为什么能并发上万个 Task?

关键概念：Task = 绿色线程。

当一个 Future 被 runtime 接管，它会被封装成一个 Task，内部包含：

Future 状态机本体
Waker（唤醒机制）
调度所需的元数据

它不是 OS 线程，而是用户态的轻量执行单元，结构本身约 64 bytes 级别。这带来一个关键模型：

M:N 模型 —— M 个 task 复用 N 个 worker 线程（N 通常 = 核心数）

对比一下开销：

单位	栈 / 占用	1 万个的开销
OS 线程	默认 MB 级栈	约 10 GB，不可行
Task	约 64 bytes 级	约几百 KB，轻松

但有个常被误解的点要澄清：task 的"并行"上限 = worker 线程数 N。所谓"并发上万个”，是上万个 task 在 N 个线程上分时复用，而不是真的同时跑上万个。并发（concurrent）≠ 并行（parallel）。

Q3：Tokio 是如何压榨 CPU 多核性能的？

这是 Tokio 性能设计的核心：混合队列模型（Hybrid Queue）。

队列	归属	特点
Local Queue	每个 worker 独享	所属 worker 无锁访问、cache 友好、ring buffer（约 256 slot）
Global Queue	全 runtime 共享	需要加锁，用于跨 worker 分发与负载均衡

为什么这么设计？ 假设把所有 task 都丢进一个全局队列，那么每次取任务、放任务都要抢同一把锁，N 个线程会陷入经典的锁竞争瓶颈。

Tokio 的做法是让"快路径"绕开锁：

task 优先进入当前 worker 的 Local Queue，取/放都无需互斥锁
Local Queue 基于 ring buffer，队列头部常驻 CPU L1 Cache，取下一个 task 极快
只有需要跨 worker 分发的 task（比如 spawn 时不在 worker 上下文里，或 Local Queue 已满溢出）才进 Global Queue

于是 worker 取任务的优先级链是：

flowchart
 A[获取任务优先级] --> B{Local Queue是否有任务?}
 B -- 有 --> C[从Local Queue取任务执行]
 B -- 无 --> D{Global Queue是否有任务?}
 D -- 有 --> E[从Global Queue取任务执行]
 D -- 无 --> F[执行Work Stealing]
 F --> G[从其他繁忙线程窃取任务]

绝大多数情况下，worker 都在走第 1 步这条无锁快路径。

Q4：某个 worker 空了，怎么办？

Tokio 用到了 Work Stealing（工作窃取） 来解决各 Worker 负载均衡的问题。这是一种并行任务调度算法（Scheduling Algorithm），在其他语言也有类似实现。（比如 Java 的 ForkJoinPool；Go 的 GMP Scheduler 等）

它在 Tokio 里的运作机制：

触发时机：当前 worker 的 Local Queue 和 Global Queue 都没有可执行任务
执行逻辑：随机选一个其他 worker，从它的 Local Queue 窃取大约一半的任务，搬回自己的 Local Queue 继续执行
效果：忙的 worker 被偷、闲的 worker 有活干，负载自动均衡

这套机制的好处是没有中心调度器——不像 master-slave 那样有个分发瓶颈，每个 worker 既干活又互相协调。

Q5：task 在等 IO / sleep，worker 线程为什么没卡死？

这是 Reactor 登场的地方，也是事件驱动模型真正发挥价值的环节。

Reactor 是连接异步任务和OS的桥梁，负责监听和管理异步 I/O 事件。

当某个 task 的 Future 返回 Pending（比如 sleep 时间没到、socket 没数据），流程是这样的：

1. Future 把自己的 Waker 注册到 Reactor
2. worker 不阻塞，立刻去取下一个 task 继续跑
3. Reactor 基于 mio，底层是 OS 事件机制
 - Linux：epoll
 - macOS / BSD：kqueue
 - Windows：IOCP
4. OS 通知"事件就绪" → Reactor 找到对应的 Waker，并调用 wake() 方法唤醒 task
5. task 被重新标记为 Runnable，放回队列
6. 某个 worker 取到它，再次 poll

而 worker 在"实在没任务可做、也偷不到任务"时才会 Park（挂起），被 wake 时 Unpark 恢复。这个 Park / Unpark 循环 让线程既不空转烧 CPU，也不会死锁阻塞。

实现步骤：一条 task 的完整旅程

把上面五个问题串联起来，一个 Tokio Task 的完整生命周期如下图：

flowchart TD
 subgraph 初始化与任务创建
 A[生成Future → 封装为Task]
 end
 subgraph 入队调度
 B[混合队列入队：
本地优先，满则全局]
 end
 subgraph 执行/IO挂起
 C[执行Future；
IO阻塞时Reactor挂起Task]
 end
 subgraph IO唤醒恢复
 D[IO就绪，Waker唤醒
重新入队]
 end
 E[任务执行完毕]

 A --> B
 B --> C
 C -- IO等待 --> D
 D --> C
 C -- 无阻塞完成 --> E

下面按生命周期展开，对照开头那段并发 sleep 代码，看看 3 个 task 到底经历了什么。

创建与入队

循环里每调用一次 tokio::spawn：

tokio::spawn(async move {
 tokio::time::sleep(...).await;
 i
});

runtime 把这个 Future 封装成一个 Task（约 64 bytes 的绿色线程），优先放入当前 worker 的 Local Queue（满了则溢出到 Global Queue）。从此它有了被调度的资格。

执行与挂起

某个 worker 从 Local Queue 取出 Task，开始 poll：

第一次 poll 时，sleep 时间没到
Future 把自己的 Waker 注册到 runtime：socket 等 IO 经 mio 挂到 epoll / kqueue / IOCP；sleep 这类定时器则注册到 runtime 内部的 timer
Future 返回 Pending
worker 不等待，立刻去取下一个 task

这就是为什么 3 个 task 能"并发"——它们在 sleep 期间并不占用 worker，worker 一直在处理别的就绪 task。

唤醒与完成

事件就绪后，对应的 Waker 被触发：IO 由 OS 经 epoll / kqueue / IOCP 通知 Reactor；定时器由 runtime 内部 timer 到期触发。Waker.wake() 会把 task 标记为 Runnable、放回队列，必要时 unpark 一个休眠的 worker。

被唤醒的 task 再次被 worker 取出、poll。这次 sleep 已到期，Future 推进到 Ready，返回编号 i，Task 完成被回收。

最终 h.await 拿到返回值，打印 done: 1 / 2 / 3。整个过程中，worker 线程数始终是 N 个，却"同时"推进了 3 个甚至更多 task。

示例 & 踩坑

踩坑 1：在 async 里写阻塞调用，拖垮整个 worker

这是新手最容易踩、也最隐蔽的坑：

async fn bad_task() {
 // 错误：直接在 async 里阻塞
 // 这会卡死当前 worker 线程，导致该线程上的其它 task 全部跟着卡住
 std::thread::sleep(std::time::Duration::from_secs(1));
}

为什么严重？因为 worker 线程数有限（通常 = 核心数）。一个 task 把 worker 阻塞住，这个 worker 上的 Local Queue 里所有 task 都得排队等它。如果几个 task 同时这么干，整个 runtime 的吞吐会直接塌掉——这正是 Q5 里 Reactor 要极力避免的场景。

正确做法是用 spawn_blocking，把阻塞操作丢到独立的阻塞线程池：

async fn good_task() {
 // 正确：阻塞操作交给专门的阻塞线程池，不占用 worker
 tokio::task::spawn_blocking(|| {
 std::thread::sleep(std::time::Duration::from_secs(1));
 })
 .await
 .unwrap();
}

spawn_blocking 的线程池和 worker 线程池是分开的，专门用来吸收阻塞调用，不参与 work-stealing 的快路径。

踩坑 2：选错 runtime flavor

#[tokio::main] 默认是 multi_thread（worker 池 + work-stealing）。也可以显式选单线程：

// 单线程 runtime：只有一个 worker，没有 work-stealing
#[tokio::main(flavor = "current_thread")]
async fn main() { /* ... */ }

选型建议：

场景	选择	原因
CPU 密集 + 高并发 IO（大多数服务端）	`multi_thread`	用满多核，work-stealing 自动均衡
简单 CLI、嵌入式、单核环境	`current_thread`	无线程切换开销，体积更小
纯 IO 绑定、低并发	`current_thread`	够用，省资源

记住：current_thread 下没有 Q4 的 work-stealing，所有 task 都在一个线程上分时复用。

边界情况：Local Queue 会满

Local Queue 容量有限（约 256 个 slot）。当某个 worker 在极短时间内 spawn 大量 task，超出容量时，溢出的 task 会被推入 Global Queue，等待其他 worker 通过优先级链的第 2 步取走。这是混合队列模型自带的"泄压阀"，不会因为本地队列满而丢任务。

总结

📦Tokio Runtime 核心组件

组件	核心说明
Task	轻量级任务单元，仅占用 64 Bytes，是最小可调度工作载体
Queue	采用本地队列 + 全局队列 + 任务窃取的混合调度队列模型
Scheduler/Executor	负责任务分发、调度与实际执行，管理线程任务流转
Reactor	基于 Mio 实现的 IO 事件驱动层，维护线程阻塞（Park）与唤醒（Unpark）循环

一些相关概念

Task = 绿色线程：约 64 bytes 的用户态执行单元，M:N 模型让上万个 task 复用 N 个 worker 线程
混合队列：Local Queue（无锁快路径）+ Global Queue（跨 worker 分发），让多核协作不退化为锁竞争
Work Stealing：worker 空了就随机偷别人"一半"的任务，无中心调度器也能负载均衡
Reactor + Park/Unpark：task 等 IO 时不占线程，OS 事件就绪再唤醒，线程空了才挂起

原理 → 工业实现

Tokio 的每一处工程化设计，本质上都是对 Rust 的异步运行时基础框架在生产环境下的回答：

基础原理	Tokio 的工业实现
Future（状态机）	Task（绿色线程，封装 Future + Waker）
单线程 poll 循环	Worker 线程池 + 混合队列
就绪队列	Local Queue（无锁）+ Global Queue
负载均衡	Work Stealing
Reactor（事件监听）	基于 mio 的 epoll / kqueue / IOCP 事件循环

想从零理解这些原理的来龙去脉，推荐看我的《手写 Rust Async Model》系列——这一篇正是那套原理在生产运行时里的落点。

References

How Rust engineered the perfect async runtime - Youtube
Tokio 官方教程 —— 从使用角度系统学习 Tokio
Tokio 源码 —— tokio/src/runtime/ 下能看到 worker、queue、scheduler 的真实实现
《手写 Rust Async Model》系列 —— 本文所有概念"从零造出来"的版本

手写 Rust Async Model（六）：与 Tokio 相比

Sun, 26 Apr 2026 15:00:00 +0800

背景 & 问题：我们做到了哪一步？

前面的五章，我们从零开始手写了一个简化版的 Rust 异步运行时：

Future Trait：定义了异步任务的标准协议
Reactor-Executor 模型：实现了事件驱动的任务调度
组合器：实现了 JoinAll、Then、Select 三种并发控制模式
Pin：解决了自引用结构的内存安全问题
async/await：揭示了编译器语法糖的本质

但我们的实现只是一个教学级别的最小可行版本。与生产级运行时 Tokio 相比，还有很大的差距。这一章我们逐项对比，看清差距，也明确学习方向。

方案：逐项对比

我们从 Future Trait、Executor、Waker 三个维度，对比手写版与 Tokio 的差异。

Future Trait 对比

// ===== 手写的版本 =====
pub trait MyFuture {
 type Output;
 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output>;
}

// ===== 标准库版本 =====
pub trait Future {
 type Output;
 fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}

差异	我们的 MyFuture	std::future::Future
self 类型	`&mut self`	`Pin<&mut Self>`
通知参数	`waker: &Waker`	`cx: &mut Context<'_>`
返回类型	`PollState<T>`	`Poll<T>`
状态枚举	`Ready(T)` / `Pending`	`Ready(T)` / `Pending`

两个关键差异：

Pin<&mut Self>：保证自引用结构在 poll 过程中不会被 move（第四章讲过）
Context<'_>：提供扩展性。多一层包装后，如果未来需要在 poll 中传递额外信息（如调度器优先级、任务元数据），只需在 Context 中添加新方法即可，不用改 poll 的签名

Executor 对比

我们的手写版相当于 MVP 版 Executor——能跑，但功能最少。Tokio 在我们基础上增加了大量生产级能力：

能力	我们的 Executor	tokio
线程模型	单线程或固定线程	多线程 + work-stealing
I/O 后端	epoll（通过 mio）	epoll + io_uring（可选）
定时器	不支持	Timer Wheel 实现
任务取消	不支持	`JoinHandle::abort()`
优雅关闭	不支持	优雅等待所有任务完成
信号处理	不支持	Unix 信号 / Windows 事件
文件 I/O	不支持	基于 blocking 线程池的异步文件操作

几个值得关注的点：

work-stealing：我们的 Executor 任务绑定在创建它的线程上，不能跨线程迁移。Tokio 使用工作窃取算法——空闲线程可以从忙碌线程"偷"任务，实现负载均衡
io_uring：Linux 5.1+ 提供的全新异步 I/O 接口，相比 epoll 有更好的性能，Tokio 已支持
Timer Wheel：高效定时器数据结构，支持大量定时任务的插入和过期检查，时间复杂度为 O(1)
任务取消：我们的实现中，Future 一旦启动就只能等它完成。Tokio 支持通过 JoinHandle::abort() 主动取消任务

Waker 对比

差异	我们的 Waker	Tokio 的 Waker
唤醒方式	`thread::unpark`	原子计数 + unpark
跨线程	支持（Thread handle）	支持（原子操作）
性能	每次唤醒都需要获取锁	无锁设计
实现复杂度	简单直接	实现复杂

我们的 Waker 用 Arc<Mutex<VecDeque>> 存储就绪队列，每次 wake() 都需要获取锁。Tokio 的 Waker 使用原子计数实现无锁唤醒，在高并发场景下性能优势明显——但实现复杂度也高得多。

示例 & 踩坑

我们实现了什么

虽然与 Tokio 差距很大，但我们的手写版本覆盖了异步运行时的核心概念：

Future（状态机）
 → PollState（状态枚举）
 → Waker（通知机制）
 → Reactor（事件监听）
 → Executor（任务调度）
 → 组合器（并发控制）
 → Pin（内存安全）
 → async/await（语法糖）

理解了这些概念，再看 Tokio 的源码或文档就不会觉得陌生。Tokio 的每一个模块都可以对应到我们手写的某个组件：

tokio::runtime::Runtime → 我们的 Executor
tokio::net → 我们的 Reactor（但用 mio/io_uring 替代了 thread::sleep）
std::future::Future → 我们的 MyFuture
std::task::Waker → 我们的 Waker
futures::join! → 我们的 JoinAll
futures::select! → 我们的 Select

下一步学习方向

如果你想继续深入 Rust 异步编程，以下资源值得一读：

Tokio 官方教程 — 从零开始学习 Tokio，涵盖异步文件 I/O、网络编程、通道、信号处理等实用主题
Rust Async Book — Rust 官方异步编程书籍，深入讲解 Future、async/await、Pin、Waker 等核心概念
std::future::Future 文档 — 标准库 Future trait 的官方文档，包含完整的 API 说明和示例

总结

经过六章的循序渐进，我们从阻塞式编程的问题出发，一步步手写了 Rust 异步运行时的核心组件：

章节	内容	核心收获
一	Future 结构	Future 是被动状态机，`poll()` 驱动前进
二	Reactor-Executor	事件驱动取代盲目轮询，Waker 连接事件与调度
三	并发调度	JoinAll/Then/Select 三种组合器模式
四	Pin	禁止 move 保护自引用结构
五	async/await	编译器生成的状态机语法糖
六	与 Tokio 对比	看清教学版与生产级的差距

手写的目的不是造轮子，而是理解轮子的构造原理。当你理解了每一层抽象为什么存在、解决了什么问题之后，再使用 Tokio 这样的生产级框架时，就能做到知其然也知其所以然。

手写 Rust Async Model（五）：async/await 揭秘

Sun, 26 Apr 2026 14:00:00 +0800

背景 & 问题：async/await 到底做了什么？

前面四章我们手写了 Future Trait、Reactor-Executor 模型、组合器和 Pin。但日常使用 Rust 异步时，我们几乎从不手写 poll()——只需要 async 和 await 两个关键字：

async fn do_something() -> String {
 some_async_op().await;
 another_async_op().await;
 "done".to_string()
}

这两个关键字到底做了什么？编译器在背后生成了什么代码？

答案：async/await 是语法糖，编译器会将它转换为一个状态机。这一章我们手写一个状态机，然后与 async/await 版本对比，彻底搞清楚它的本质。

方案：手写状态机 vs async/await

我们要实现的功能很简单：等待 100ms，打印一条消息，再等待 100ms，再打印一条消息，然后返回一个字符串。两步异步操作，对应两个 .await 点。

分别用两种方式实现：

手写状态机：手动定义枚举状态和 poll() 逻辑
async/await：用语法糖写出等价逻辑

对比两者的行为，揭示编译器做了什么。

实现步骤

第一步：定义基础 Future（SimpleDelay）

两种版本都需要一个简单的延迟 Future 作为基础：

/// 一个简单的延迟 Future
struct SimpleDelay {
 when: Instant,
}

impl SimpleDelay {
 fn new(ms: u64) -> Self {
 Self {
 when: Instant::now() + Duration::from_millis(ms),
 }
 }
}

impl Future for SimpleDelay {
 type Output = ();

 fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> {
 if Instant::now() >= self.when {
 Poll::Ready(())
 } else {
 Poll::Pending
 }
 }
}

第二步：手写多步状态机

手动定义一个四状态的状态机，模拟编译器生成的代码：

/// 手写的多步状态机（模拟 async fn 编译结果）
struct HandWrittenFuture {
 state: HandWrittenState,
}

enum HandWrittenState {
 /// 初始状态，还没开始
 Start,
 /// 等待第一个延迟
 WaitFirst(SimpleDelay),
 /// 等待第二个延迟
 WaitSecond(SimpleDelay),
 /// 已完成
 Done,
}

四个状态对应异步函数的执行阶段：

Start：函数体开始执行
WaitFirst：第一个 .await 点，等待 SimpleDelay::new(100)
WaitSecond：第二个 .await 点，等待 SimpleDelay::new(100)
Done：函数执行完毕

poll() 实现：

impl Future for HandWrittenFuture {
 type Output = String;

 fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
 let this = unsafe { self.get_unchecked_mut() };

 loop {
 match &mut this.state {
 HandWrittenState::Start => {
 println!("[手写版] 开始");
 this.state = HandWrittenState::WaitFirst(SimpleDelay::new(100));
 }
 HandWrittenState::WaitFirst(delay) => {
 match Pin::new(delay).poll(cx) {
 Poll::Pending => return Poll::Pending,
 Poll::Ready(()) => {
 println!("[手写版] 第一步完成");
 this.state = HandWrittenState::WaitSecond(SimpleDelay::new(100));
 }
 }
 }
 HandWrittenState::WaitSecond(delay) => {
 match Pin::new(delay).poll(cx) {
 Poll::Pending => return Poll::Pending,
 Poll::Ready(()) => {
 println!("[手写版] 第二步完成");
 this.state = HandWrittenState::Done;
 return Poll::Ready("完成".to_string());
 }
 }
 }
 HandWrittenState::Done => panic!("Future polled after completion"),
 }
 }
 }
}

注意 loop + match 的设计模式：

立即推进：loop 让无等待的状态转换（如 Start → WaitFirst）一气呵成，避免不必要的 Pending 返回
按需暂停：子 Future 未就绪时返回 Pending，控制权交还 Executor，下次 poll 从当前状态继续
状态内嵌：枚举变体直接存储子 Future 实例（如 WaitFirst(SimpleDelay)），状态在 poll 之间自然保留

第三步：async/await 版本

同样的逻辑，用 async/await 写出：

/// 同样的逻辑，用 async/await 写出
async fn async_version() -> String {
 println!("[async版] 开始");

 SimpleDelay::new(100).await;
 println!("[async版] 第一步完成");

 SimpleDelay::new(100).await;
 println!("[async版] 第二步完成");

 "完成".to_string()
}

就这么简单。编译器在背后做了什么？

分析 async fn 函数体，识别所有 .await 点
为每个 .await 点生成一个枚举变体（状态）
生成状态机结构体和 poll() 方法

async/await 本质就是语法糖，让你用同步风格的代码写出异步逻辑，降低开发者的心智负担。

示例 & 踩坑

两个版本逐行对比

手写状态机	async/await 版本	说明
`HandWrittenState::Start`	`async fn async_version()` 的函数体开始	第一个状态
`println!("[手写版] 开始")`	`println!("[async版] 开始")`	初始状态下的同步代码
`WaitFirst(SimpleDelay::new(100))`	`SimpleDelay::new(100).await`	创建子 Future 并开始等待
`HandWrittenState::WaitFirst(delay)`	第一个 `.await` 点	暂停点
`Pin::new(delay).poll(cx)` 返回 `Pending`	`.await` 让出控制权	子 Future 未完成
`Pin::new(delay).poll(cx)` 返回 `Ready(())`	`.await` 恢复执行	子 Future 完成
`WaitSecond(SimpleDelay::new(100))`	`SimpleDelay::new(100).await`	第二个暂停点
`return Poll::Ready("完成")`	`"完成".to_string()`	函数返回

.await 的本质

.await 在编译后的代码中做了三件事：

调用子 Future 的 poll()
若返回 Ready(val)，将值提取出来，继续执行后续代码
若返回 Pending，保存当前状态机的一切状态，将控制权交还给 Executor

注意：.await 是一个非阻塞等待，它不会让当前线程停下来。它更像一个检查点——“子 Future 好了吗？好了就继续，没好就暂停”。

运行两种版本

fn main() {
 println!("=== 手写状态机版 ===");
 let start = Instant::now();
 let result = mini_block_on(HandWrittenFuture::new());
 println!("结果: {}，耗时: {:?}\n", result, start.elapsed());

 println!("=== async/await 版 ===");
 let start = Instant::now();
 let result = mini_block_on(async_version());
 println!("结果: {}，耗时: {:?}\n", result, start.elapsed());

 println!("两种写法的行为完全一致！");
}

最小 Executor

为了运行这两个 Future，需要一个最小化的 Executor：

/// 创建一个 no-op Waker（仅用于演示，不会真正唤醒）
fn noop_waker() -> Waker {
 fn noop_clone(_: *const ()) -> RawWaker {
 noop_raw_waker()
 }
 fn noop(_: *const ()) {}

 fn noop_raw_waker() -> RawWaker {
 RawWaker::new(std::ptr::null(), &VTABLE)
 }

 static VTABLE: RawWakerVTable = RawWakerVTable::new(noop_clone, noop, noop, noop);

 unsafe { Waker::from_raw(noop_raw_waker()) }
}

/// 最小化 block_on（busy poll，仅用于演示）
fn mini_block_on<F: Future>(future: F) -> F::Output {
 let mut future = Box::pin(future);
 let waker = noop_waker();
 let mut cx = Context::from_waker(&waker);

 loop {
 match future.as_mut().poll(&mut cx) {
 Poll::Ready(val) => return val,
 Poll::Pending => thread::sleep(Duration::from_millis(10)),
 }
 }
}

注意：这个 mini_block_on 使用了 busy polling，仅用于演示。生产环境请使用第二章的事件驱动版本。

本章完整代码

use std::future::Future;
use std::pin::Pin;
use std::task::{Context, Poll, RawWaker, RawWakerVTable, Waker};
use std::thread;
use std::time::{Duration, Instant};

// ================== 手写状态机版本 ==================

/// 一个简单的延迟 Future
struct SimpleDelay {
 when: Instant,
}

impl SimpleDelay {
 fn new(ms: u64) -> Self {
 Self {
 when: Instant::now() + Duration::from_millis(ms),
 }
 }
}

impl Future for SimpleDelay {
 type Output = ();

 fn poll(self: Pin<&mut Self>, _cx: &mut Context<'_>) -> Poll<Self::Output> {
 if Instant::now() >= self.when {
 Poll::Ready(())
 } else {
 Poll::Pending
 }
 }
}

/// 手写的多步状态机（模拟 async fn 编译结果）
struct HandWrittenFuture {
 state: HandWrittenState,
}

enum HandWrittenState {
 Start,
 WaitFirst(SimpleDelay),
 WaitSecond(SimpleDelay),
 Done,
}

impl HandWrittenFuture {
 fn new() -> Self {
 Self {
 state: HandWrittenState::Start,
 }
 }
}

impl Future for HandWrittenFuture {
 type Output = String;

 fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
 let this = unsafe { self.get_unchecked_mut() };

 loop {
 match &mut this.state {
 HandWrittenState::Start => {
 println!("[手写版] 开始");
 this.state = HandWrittenState::WaitFirst(SimpleDelay::new(100));
 }
 HandWrittenState::WaitFirst(delay) => {
 match Pin::new(delay).poll(cx) {
 Poll::Pending => return Poll::Pending,
 Poll::Ready(()) => {
 println!("[手写版] 第一步完成");
 this.state = HandWrittenState::WaitSecond(SimpleDelay::new(100));
 }
 }
 }
 HandWrittenState::WaitSecond(delay) => {
 match Pin::new(delay).poll(cx) {
 Poll::Pending => return Poll::Pending,
 Poll::Ready(()) => {
 println!("[手写版] 第二步完成");
 this.state = HandWrittenState::Done;
 return Poll::Ready("完成".to_string());
 }
 }
 }
 HandWrittenState::Done => panic!("Future polled after completion"),
 }
 }
 }
}

// ================== async/await 版本 ==================

/// 同样的逻辑，用 async/await 写出
async fn async_version() -> String {
 println!("[async版] 开始");

 SimpleDelay::new(100).await;
 println!("[async版] 第一步完成");

 SimpleDelay::new(100).await;
 println!("[async版] 第二步完成");

 "完成".to_string()
}

// ================== 最小 Executor ==================

fn noop_waker() -> Waker {
 fn noop_clone(_: *const ()) -> RawWaker {
 noop_raw_waker()
 }
 fn noop(_: *const ()) {}

 fn noop_raw_waker() -> RawWaker {
 RawWaker::new(std::ptr::null(), &VTABLE)
 }

 static VTABLE: RawWakerVTable = RawWakerVTable::new(noop_clone, noop, noop, noop);

 unsafe { Waker::from_raw(noop_raw_waker()) }
}

fn mini_block_on<F: Future>(future: F) -> F::Output {
 let mut future = Box::pin(future);
 let waker = noop_waker();
 let mut cx = Context::from_waker(&waker);

 loop {
 match future.as_mut().poll(&mut cx) {
 Poll::Ready(val) => return val,
 Poll::Pending => thread::sleep(Duration::from_millis(10)),
 }
 }
}

// ================== main ==================

fn main() {
 println!("=== 手写状态机版 ===");
 let start = Instant::now();
 let result = mini_block_on(HandWrittenFuture::new());
 println!("结果: {}，耗时: {:?}\n", result, start.elapsed());

 println!("=== async/await 版 ===");
 let start = Instant::now();
 let result = mini_block_on(async_version());
 println!("结果: {}，耗时: {:?}\n", result, start.elapsed());

 println!("两种写法的行为完全一致！");
}

总结

这一章我们通过手写状态机和 async/await 版本的对比，揭示了语法糖背后的真相：

async fn 编译后生成一个状态机结构体，每个 .await 点对应一个枚举变体
.await 本质是调用子 Future 的 poll()，Ready 则继续，Pending 则暂停并保存状态
loop + match 是编译器生成的 poll() 方法的标准模式
async/await 就是语法糖——它让你用同步风格写出异步代码，但编译器做了所有繁重的状态机管理工作

到这里，我们已经从最底层的 Future Trait 一直走到了 async/await 语法糖。最后一章，我们将把手写的模型与生产级运行时 Tokio 做一个全面对比，看看还差多远。

手写 Rust Async Model（四）：自引用和 Pin

Sun, 26 Apr 2026 13:00:00 +0800

背景 & 问题：async 为何需要 Pin？

前面三章我们手写了 Future 和相应的运行时，但有一个关键的安全问题一直没提——async fn 编译后的 Future，本质是一个"状态机结构体"，而这个状态机可能形成自引用结构。

什么是自引用结构？就是结构体内部的某个字段引用了自身的另一个字段：

旧地址 A
 ├── a (值: 42)
 └── b → 指向 a 的地址

move 后变成新地址 B
 ├── a (值: 42) ← 数据被拷贝到了新位置
 └── b → 仍指向旧地址 A.a ❌ 悬垂指针！

在 Rust 中，大多数类型可以在内存中自由移动（move）。但自引用结构一旦被 move，内部指针就会失效，变成悬垂指针——这是内存安全的灾难。

async fn 编译后的状态机就可能出现这种情况：某个 .await 点暂停后，局部变量的引用可能被保存在结构体字段中，形成自引用。如果 Future 被 move，这些引用就失效了。

解决方案：使用 Pin 固定内存地址，禁止 move。

方案：PhantomPinned + Pin

Rust 的解决方案分两步：

PhantomPinned：标记类型为 !Unpin，告诉编译器"这个类型不能安全移动"
Pin<T>：一个包装器，保证被包装的值在内存中不会被移动

PhantomPinned 和 !Unpin

PhantomPinned 是标准库提供的零大小标记类型，它唯一的作用是让包含它的类型自动变成 !Unpin：

use std::marker::PhantomPinned;

struct MaybeSelfRef {
 a: usize,
 b: Option<NonNull<usize>>, // b 可能指向 a（自引用！）
 _pin: PhantomPinned, // 让这个类型变成 !Unpin
}

!Unpin 是一个 marker trait 的否定形式，含义是"这个类型不能安全地被 Pin 解引用"。一旦结构体包含 PhantomPinned，编译器就会阻止你用安全代码将它的值从 Pin 中取出。

实现步骤

第一步：复现自引用问题

先用一段代码直观展示自引用结构被 move 后会发生什么：

use std::marker::PhantomPinned;
use std::ptr::NonNull;

#[derive(Debug)]
struct MaybeSelfRef {
 a: usize,
 // b 可能指向 a 的地址（自引用！）
 b: Option<NonNull<usize>>,
 _pin: PhantomPinned,
}

impl MaybeSelfRef {
 fn new(value: usize) -> Self {
 Self {
 a: value,
 b: None,
 _pin: PhantomPinned,
 }
 }
}

fn main() {
 let mut x = MaybeSelfRef::new(42);
 let mut y = MaybeSelfRef::new(99);

 // 建立 x 的自引用：b 指向 a
 unsafe {
 let a_ptr = NonNull::new_unchecked(&mut x.a as *mut usize);
 x.b = Some(a_ptr);
 }

 println!("建立自引用前:");
 println!(" x.a = {}, 通过 x.b 读取的值 = {}", x.a,
 unsafe { x.b.unwrap().as_ref() });

 // 危险！swap 交换了 x 和 y 的内存内容
 std::mem::swap(&mut x, &mut y);

 println!("\nswap 后:");
 println!(" x.a = {}, 通过 x.b 读取的值 = {}", x.a,
 unsafe { x.b.unwrap().as_ref() });
 println!(" x.b 指向的值 ({}) ≠ x.a ({}) — 悬垂指针！",
 unsafe { *x.b.unwrap().as_ref() }, x.a);
}

运行结果：

建立自引用前:
 x.a = 42, 通过 x.b 读取的值 = 42

swap 后:
 x.a = 42, 通过 x.b 读取的值 = 99
 x.b 指向的值 (99) ≠ x.a (42) — 悬垂指针！

std::mem::swap 把 x 和 y 的内存内容互换了。x 的 a 被换成了原来的 42，但 b 仍然指向原来的地址——而那个地址现在存的是 y 的数据。自引用被破坏了。

第二步：用 Pin 解决问题

Pin<T> 是一个包装器，它保证被包装的值不会被 move。最常见的方式是 Box::pin()，将值固定在堆上：

use std::pin::Pin;

fn main() {
 // Box::pin 将值固定在堆上，之后无法被移动
 let mut pinned = Box::pin(MaybeSelfRef::new(42));

 // 建立自引用
 pinned.as_mut().init();

 println!("建立自引用后:");
 println!(" a = {}", pinned.a);

 // 通过 b 修改 a
 pinned.as_mut().set_a_via_b(100);

 println!(" 通过 b 修改后 a = {}", pinned.a);
 println!(" ✅ 自引用仍然有效！");

 // 试图移动会编译失败：
 // let moved = pinned; // ❌ 编译错误！MaybeSelfRef: !Unpin
}

因为 MaybeSelfRef 包含 PhantomPinned，它是 !Unpin 的。这意味着你不能用安全代码把它从 Pin 中取出来，也就无法 move 它。自引用永远安全。

第三步：实现安全的自引用操作

在 Pin 保护下，我们可以安全地操作自引用结构：

impl MaybeSelfRef {
 /// 建立自引用（必须在 Pin 保护下调用）
 fn init(self: Pin<&mut Self>) {
 // 安全性：因为 Self 是 !Unpin，调用者保证 self 不会被移动
 unsafe {
 let this = self.get_unchecked_mut();
 let a_ptr = NonNull::new_unchecked(&mut this.a as *mut usize);
 this.b = Some(a_ptr);
 }
 }

 /// 通过自引用 b 修改 a 的值
 fn set_a_via_b(self: Pin<&mut Self>, new_val: usize) {
 unsafe {
 let this = self.get_unchecked_mut();
 if let Some(ptr) = this.b {
 *ptr.as_ptr() = new_val;
 }
 }
 }
}

注意 self: Pin<&mut Self> 签名——它要求调用者必须持有 Pin<&mut Self>，从而保证调用期间值不会被 move。

示例 & 踩坑

Pin + Future 的关系

整个 Rust async runtime 的安全保证链如下：

Future（状态机）
 ↓
可能包含自引用
 ↓
必须 Pin 固定内存位置
 ↓
Executor poll(Pin<&mut T>)
 ↓
保证 poll 过程中不会 move

这就是为什么标准库的 Future trait 签名是：

fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;

而不是我们手写版本的 fn poll(&mut self, ...)。Pin<&mut Self> 保证 Future 在 poll 过程中不会被移动，自引用始终有效。

为什么不直接禁止所有 move？

只有可能自引用的类型才需要 Pin。大多数普通类型（如 i32、Vec<T>、不含 PhantomPinned 的结构体）是 Unpin 的，可以自由 move。Pin 只对 !Unpin 类型起限制作用，对 Unpin 类型是透明的。

本章完整代码

use std::marker::PhantomPinned;
use std::pin::Pin;
use std::ptr::NonNull;

/// 模拟 async 状态机中的自引用结构
#[derive(Debug)]
struct MaybeSelfRef {
 a: usize,
 // b 可能指向 a 的地址（自引用！）
 b: Option<NonNull<usize>>,
 // PhantomPinned 使这个类型变成 !Unpin
 _pin: PhantomPinned,
}

impl MaybeSelfRef {
 fn new(value: usize) -> Self {
 Self {
 a: value,
 b: None,
 _pin: PhantomPinned,
 }
 }

 /// 建立自引用（必须在 Pin 保护下调用）
 fn init(self: Pin<&mut Self>) {
 // 安全性：因为 Self 是 !Unpin，调用者保证 self 不会被移动
 unsafe {
 let this = self.get_unchecked_mut();
 let a_ptr = NonNull::new_unchecked(&mut this.a as *mut usize);
 this.b = Some(a_ptr);
 }
 }

 /// 通过自引用 b 修改 a 的值
 fn set_a_via_b(self: Pin<&mut Self>, new_val: usize) {
 unsafe {
 let this = self.get_unchecked_mut();
 if let Some(ptr) = this.b {
 *ptr.as_ptr() = new_val;
 }
 }
 }
}

fn main() {
 // === 1. 问题演示：自引用 + swap = 悬垂指针 ===
 println!("=== 自引用问题演示 ===");

 let mut x = MaybeSelfRef::new(42);
 let mut y = MaybeSelfRef::new(99);

 // 建立 x 的自引用：b 指向 a
 unsafe {
 let a_ptr = NonNull::new_unchecked(&mut x.a as *mut usize);
 x.b = Some(a_ptr);
 }

 println!("建立自引用前:");
 println!(" x.a = {}, 通过 x.b 读取的值 = {}", x.a,
 unsafe { x.b.unwrap().as_ref() });

 // 危险！swap 交换了 x 和 y 的内存内容
 // x.b 仍然指向旧地址，但那个地址现在属于 y
 std::mem::swap(&mut x, &mut y);

 println!("\nswap 后:");
 println!(" x.a = {}, 通过 x.b 读取的值 = {}", x.a,
 unsafe { x.b.unwrap().as_ref() });
 println!(" ⚠️ x.b 指向的值 ({}) ≠ x.a ({}) — 悬垂指针！",
 unsafe { *x.b.unwrap().as_ref() }, x.a);

 println!();

 // === 2. 解决方案：Pin 固定内存位置 ===
 println!("=== Pin 解决方案 ===");

 // Box::pin 将值固定在堆上，之后无法被移动
 let mut pinned = Box::pin(MaybeSelfRef::new(42));

 // 建立自引用
 pinned.as_mut().init();

 println!("建立自引用后:");
 println!(" a = {}", pinned.a);

 // 通过 b 修改 a
 pinned.as_mut().set_a_via_b(100);

 println!(" 通过 b 修改后 a = {}", pinned.a);
 println!(" ✅ 自引用仍然有效！");

 // 试图移动会编译失败：
 // let moved = pinned; // ❌ 编译错误！MaybeSelfRef: !Unpin
}

总结

这一章我们解决了 async 编程中一个根本性的安全问题：

自引用结构：结构体内部字段引用自身其他字段，move 后指针失效
PhantomPinned：零大小标记类型，让包含它的类型变为 !Unpin
Pin<T>：禁止 !Unpin 类型被 move 的包装器，保证内存地址不变
Pin + Future：标准库 Future 的 poll() 签名使用 Pin<&mut Self>，确保状态机在 poll 过程中不会被移动

Pin 是 Rust 异步安全的基石——没有它，编译器就无法保证 async fn 生成的状态机在多次 poll 之间自引用始终有效。下一章我们将揭示 async/await 语法糖的本质，看看编译器是如何将异步代码转换为状态机的。

手写 Rust Async Model（三）：并发任务调度

Sun, 26 Apr 2026 12:00:00 +0800

背景 & 问题：单个 Future 不够用

上一章我们实现了一个完整的 Reactor-Executor 模型，但还有一个问题没解决——真实场景中经常需要多个 Future 协作：

多个 async task 同时存在，需要等待全部完成
IO/timer 的完成顺序是乱序的
CPU 需要复用（不能一个 task 占一个线程）

解决方案：构建并发任务调度系统，实现最基础的三种组合模式：

JoinAll：等待全部完成
Then：串联执行
Select：竞速取最快

方案：Future 组合器

组合器（Combinator）本身也是一个 Future，它内部持有子 Future，通过特定的策略来驱动子 Future 的 poll()。

Timer Future：带返回值的延迟

第二章的 Delay 返回 ()，但组合器需要子 Future 返回有意义的值。所以先引入 Timer——一个类似 Delay 但返回 String 消息的 Future：

/// 延迟指定时间后返回消息的 Future
pub struct Timer {
 when: Instant,
 registered: bool,
 message: String,
}

impl Timer {
 pub fn new(ms: u64, message: impl Into<String>) -> Self {
 Self {
 when: Instant::now() + Duration::from_millis(ms),
 registered: false,
 message: message.into(),
 }
 }
}

impl MyFuture for Timer {
 type Output = String;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 if Instant::now() >= self.when {
 let msg = self.message.clone();
 println!("{} done", msg);
 return PollState::Ready(msg);
 }

 if !self.registered {
 let dur = self.when - Instant::now();
 let reactor = Reactor::new();
 reactor.register_timer(dur, waker.clone());
 self.registered = true;
 }

 PollState::Pending
 }
}

实现步骤

JoinAll：等待所有任务完成

JoinAll 接收一组 Future，等待全部完成后，将所有结果收集到一个 Vec 中返回。

/// 等待所有子 Future 完成
pub struct JoinAll<F: MyFuture> {
 /// 存储子 Future 及其完成结果
 /// (已完成的值, 子 Future)
 items: Vec<(Option<F::Output>, F)>,
}

impl<F: MyFuture> JoinAll<F> {
 pub fn new(futures: Vec<F>) -> Self {
 Self {
 items: futures.into_iter().map(|f| (None, f)).collect(),
 }
 }
}

为什么用 Option 存储结果？因为子 Future 的完成顺序不确定，要等所有 Option 都为 Some 才说明全部完成。

poll 实现：

impl<F: MyFuture> MyFuture for JoinAll<F> {
 type Output = Vec<F::Output>;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 let mut pending_count = 0;

 for (result, fut) in self.items.iter_mut() {
 if result.is_some() {
 continue; // 跳过已完成的 Future
 }

 match fut.poll(waker) {
 PollState::Ready(val) => {
 *result = Some(val);
 }
 PollState::Pending => {
 pending_count += 1;
 }
 }
 }

 if pending_count == 0 {
 // 所有子 Future 都已完成，收集结果
 let results: Vec<F::Output> = self
 .items
 .iter_mut()
 .map(|(r, _)| r.take().unwrap())
 .collect();
 PollState::Ready(results)
 } else {
 PollState::Pending
 }
 }
}

每次调用 poll()，JoinAll 会遍历所有子项，驱动未完成的子 Future，直到全部完成才返回结果。

使用示例：

let results = block_on(JoinAll::new(vec![
 Timer::new(300, "任务A"),
 Timer::new(200, "任务B"),
 Timer::new(100, "任务C"),
]));
println!("全部完成: {:?}", results);
// 输出顺序取决于完成顺序，可能是 ["任务C", "任务B", "任务A"]

Then：链式调用

Then 使用串行模式：前一个 Future 的输出作为后一个 Future 的输入。

/// 链式调用：第一个 Future 完成后，用其结果启动第二个
pub struct Then<F, NextF, C>
where
 F: MyFuture,
 NextF: MyFuture,
 C: FnOnce(F::Output) -> NextF,
{
 first: Option<F>,
 second: Option<NextF>,
 callback: Option<C>,
}

impl<F, NextF, C> Then<F, NextF, C>
where
 F: MyFuture,
 NextF: MyFuture,
 C: FnOnce(F::Output) -> NextF,
{
 pub fn new(first: F, callback: C) -> Self {
 Self {
 first: Some(first),
 second: None,
 callback: Some(callback),
 }
 }
}

poll() 实现：

impl<F, NextF, C> MyFuture for Then<F, NextF, C>
where
 F: MyFuture,
 NextF: MyFuture,
 C: FnOnce(F::Output) -> NextF,
{
 type Output = NextF::Output;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 // 1. poll 第一个 Future
 if let Some(mut first) = self.first.take() {
 match first.poll(waker) {
 PollState::Ready(val) => {
 // 第一个完成，用闭包生成第二个 Future
 let cb = self.callback.take().unwrap();
 self.second = Some(cb(val));
 }
 PollState::Pending => {
 // 第一个未完成，放回去等待下次 poll
 self.first = Some(first);
 return PollState::Pending;
 }
 }
 }

 // 2. Poll 第二个 Future
 match self.second.as_mut() {
 Some(second) => second.poll(waker),
 None => unreachable!("Then polled after completion"),
 }
 }
}

使用示例：

let result = block_on(Then::new(
 Timer::new(500, "第一步"),
 |msg| Timer::new(300, format!("{} → 第二步", msg)),
));
println!("最终结果: {}", result);
// 输出: 最终结果: 第一步 → 第二步

Select：竞速

Select 同时运行两个 Future，任意一个完成即返回。常用于超时控制、竞速请求等场景。

首先定义结果标记枚举：

/// 竞速结果的标记
pub enum Either<T1, T2> {
 First(T1),
 Second(T2),
}

Select 结构和实现：

/// 竞速：任一 Future 完成即返回
pub struct Select<F1, F2> {
 f1: Option<F1>,
 f2: Option<F2>,
}

impl<F1: MyFuture, F2: MyFuture> Select<F1, F2> {
 pub fn new(f1: F1, f2: F2) -> Self {
 Self {
 f1: Some(f1),
 f2: Some(f2),
 }
 }
}

impl<F1: MyFuture, F2: MyFuture> MyFuture for Select<F1, F2> {
 type Output = Either<F1::Output, F2::Output>;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 // 先 poll 第一个 Future
 if let Some(mut f1) = self.f1.take() {
 if let PollState::Ready(val) = f1.poll(waker) {
 return PollState::Ready(Either::First(val));
 }
 self.f1 = Some(f1); // 未完成则放回去
 }

 // 再 poll 第二个 Future
 if let Some(mut f2) = self.f2.take() {
 if let PollState::Ready(val) = f2.poll(waker) {
 return PollState::Ready(Either::Second(val));
 }
 self.f2 = Some(f2); // 未完成，放回去
 }

 // 两个都未完成
 PollState::Pending
 }
}

每次 poll() 时，先尝试 poll 第一个 Future，若 Ready 则立即返回；否则 poll 第二个 Future；两个都 Pending 则返回 Pending。

使用示例：

match block_on(Select::new(
 Timer::new(1000, "慢任务"),
 Timer::new(200, "快任务"),
)) {
 Either::First(msg) => println!("胜出(左): {}", msg),
 Either::Second(msg) => println!("胜出(右): {}", msg),
}
// 输出: 胜出(右): 快任务

示例 & 踩坑

三种组合器对比

组合器	语义	返回值	典型场景
`JoinAll`	等待全部完成	`Vec<F::Output>`	并发请求多个 API，全部返回后聚合结果
`Then`	串联执行	`NextF::Output`	先获取 token，再用 token 请求用户数据
`Select`	竞速取最快	`Either<F1::Output, F2::Output>`	超时控制、多源竞速、请求取消

简化版 block_on

本章的组合器演示只需要运行单个 Future，所以使用简化版的 block_on，不需要第二章 Executor 的完整任务管理：

/// 简化版 block_on：事件驱动地执行单个 Future
fn block_on<F: MyFuture>(mut future: F) -> F::Output {
 let queue = Arc::new(Mutex::new(VecDeque::new()));
 let current_thread = thread::current();

 loop {
 let waker = Waker {
 id: 0,
 queue: queue.clone(),
 thread: current_thread.clone(),
 };

 match future.poll(&waker) {
 PollState::Ready(val) => return val,
 PollState::Pending => {
 // 没有 wake 信号就 park 等待
 thread::park();
 }
 }
 }
}

相比第二章的 Executor：

不需要任务 ID 管理：只有一个 Future，固定为 id: 0
不需要 HashMap：只有一个 Future，直接作为局部变量持有
不需要就绪队列的销毁逻辑：park() 被 unpark() 唤醒后，直接重新 poll 那唯一的 Future

当前模型的局限

没有 work-stealing：任务绑定在创建它的线程上，不能跨线程迁移
负载不均衡：某些线程忙，某些线程闲

生产级运行时（如 tokio）使用工作窃取算法解决这个问题——空闲线程可以从忙碌线程"偷"任务。

本章完整代码

use std::collections::VecDeque;
use std::sync::{Arc, Mutex};
use std::thread::{self, Thread};
use std::time::{Duration, Instant};

// ================== 核心抽象 ==================

pub enum PollState<T> {
 Ready(T),
 Pending,
}

pub trait MyFuture {
 type Output;
 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output>;
}

// ================== Waker ==================

#[derive(Clone)]
pub struct Waker {
 id: usize,
 queue: Arc<Mutex<VecDeque<usize>>>,
 thread: Thread,
}

impl Waker {
 pub fn wake(&self) {
 self.queue.lock().unwrap().push_back(self.id);
 self.thread.unpark();
 }
}

// ================== Reactor ==================

#[derive(Clone)]
pub struct Reactor;

impl Reactor {
 pub fn new() -> Self {
 Self
 }

 pub fn register_timer(&self, dur: Duration, waker: Waker) {
 thread::spawn(move || {
 thread::sleep(dur);
 waker.wake();
 });
 }
}

// ================== Timer Future ==================

/// 延迟指定时间后返回消息的 Future
pub struct Timer {
 when: Instant,
 registered: bool,
 message: String,
}

impl Timer {
 pub fn new(ms: u64, message: impl Into<String>) -> Self {
 Self {
 when: Instant::now() + Duration::from_millis(ms),
 registered: false,
 message: message.into(),
 }
 }
}

impl MyFuture for Timer {
 type Output = String;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 if Instant::now() >= self.when {
 let msg = self.message.clone();
 println!("{} done", msg);
 return PollState::Ready(msg);
 }

 if !self.registered {
 let dur = self.when - Instant::now();
 let reactor = Reactor::new();
 reactor.register_timer(dur, waker.clone());
 self.registered = true;
 }

 PollState::Pending
 }
}

// ================== 组合器 ==================

/// 等待所有子 Future 完成
pub struct JoinAll<F: MyFuture> {
 items: Vec<(Option<F::Output>, F)>,
}

impl<F: MyFuture> JoinAll<F> {
 pub fn new(futures: Vec<F>) -> Self {
 Self {
 items: futures.into_iter().map(|f| (None, f)).collect(),
 }
 }
}

impl<F: MyFuture> MyFuture for JoinAll<F> {
 type Output = Vec<F::Output>;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 let mut pending_count = 0;

 for (result, fut) in self.items.iter_mut() {
 if result.is_some() {
 continue;
 }

 match fut.poll(waker) {
 PollState::Ready(val) => {
 *result = Some(val);
 }
 PollState::Pending => {
 pending_count += 1;
 }
 }
 }

 if pending_count == 0 {
 let results: Vec<F::Output> = self
 .items
 .iter_mut()
 .map(|(r, _)| r.take().unwrap())
 .collect();
 PollState::Ready(results)
 } else {
 PollState::Pending
 }
 }
}

/// 链式调用：第一个 Future 完成后，用其结果启动第二个
pub struct Then<F, NextF, C>
where
 F: MyFuture,
 NextF: MyFuture,
 C: FnOnce(F::Output) -> NextF,
{
 first: Option<F>,
 second: Option<NextF>,
 callback: Option<C>,
}

impl<F, NextF, C> Then<F, NextF, C>
where
 F: MyFuture,
 NextF: MyFuture,
 C: FnOnce(F::Output) -> NextF,
{
 pub fn new(first: F, callback: C) -> Self {
 Self {
 first: Some(first),
 second: None,
 callback: Some(callback),
 }
 }
}

impl<F, NextF, C> MyFuture for Then<F, NextF, C>
where
 F: MyFuture,
 NextF: MyFuture,
 C: FnOnce(F::Output) -> NextF,
{
 type Output = NextF::Output;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 if let Some(mut first) = self.first.take() {
 match first.poll(waker) {
 PollState::Ready(val) => {
 let cb = self.callback.take().unwrap();
 self.second = Some(cb(val));
 }
 PollState::Pending => {
 self.first = Some(first);
 return PollState::Pending;
 }
 }
 }

 match self.second.as_mut() {
 Some(second) => second.poll(waker),
 None => unreachable!("Then polled after completion"),
 }
 }
}

/// 竞速结果的标记
pub enum Either<T1, T2> {
 First(T1),
 Second(T2),
}

/// 竞速：任一 Future 完成即返回
pub struct Select<F1, F2> {
 f1: Option<F1>,
 f2: Option<F2>,
}

impl<F1: MyFuture, F2: MyFuture> Select<F1, F2> {
 pub fn new(f1: F1, f2: F2) -> Self {
 Self {
 f1: Some(f1),
 f2: Some(f2),
 }
 }
}

impl<F1: MyFuture, F2: MyFuture> MyFuture for Select<F1, F2> {
 type Output = Either<F1::Output, F2::Output>;

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 if let Some(mut f1) = self.f1.take() {
 if let PollState::Ready(val) = f1.poll(waker) {
 return PollState::Ready(Either::First(val));
 }
 self.f1 = Some(f1);
 }

 if let Some(mut f2) = self.f2.take() {
 if let PollState::Ready(val) = f2.poll(waker) {
 return PollState::Ready(Either::Second(val));
 }
 self.f2 = Some(f2);
 }

 PollState::Pending
 }
}

// ================== 简化版 block_on ==================

fn block_on<F: MyFuture>(mut future: F) -> F::Output {
 let queue = Arc::new(Mutex::new(VecDeque::new()));
 let current_thread = thread::current();

 loop {
 let waker = Waker {
 id: 0,
 queue: queue.clone(),
 thread: current_thread.clone(),
 };

 match future.poll(&waker) {
 PollState::Ready(val) => return val,
 PollState::Pending => {
 thread::park();
 }
 }
 }
}

// ================== main ==================

fn main() {
 // === JoinAll：等待所有任务 ===
 println!("=== JoinAll ===");
 let results = block_on(JoinAll::new(vec![
 Timer::new(300, "任务A"),
 Timer::new(200, "任务B"),
 Timer::new(100, "任务C"),
 ]));
 println!("全部完成: {:?}", results);
 println!();

 // === Then：链式调用 ===
 println!("=== Then ===");
 let result = block_on(Then::new(
 Timer::new(500, "第一步"),
 |msg| Timer::new(300, format!("{} → 第二步", msg)),
 ));
 println!("最终结果: {}", result);
 println!();

 // === Select：竞速 ===
 println!("=== Select ===");
 match block_on(Select::new(
 Timer::new(1000, "慢任务"),
 Timer::new(200, "快任务"),
 )) {
 Either::First(msg) => println!("胜出(左): {}", msg),
 Either::Second(msg) => println!("胜出(右): {}", msg),
 }
}

总结

这一章我们实现了三种核心 Future 组合器：

JoinAll：并发执行多个 Future，等待全部完成后收集结果
Then：串行执行两个 Future，前一个的输出作为后一个的输入
Select：竞速执行，任一 Future 完成即返回

组合器本身也是 Future，它们通过持有子 Future 并在 poll() 中驱动子 Future 的方式工作。这三种模式覆盖了异步编程中最常见的并发控制场景。

但目前的 Future 还有一个根本性的安全问题没解决——async fn 编译后的 Future 可能形成自引用结构，一旦被 move 就会出问题。下一章我们将引入 Pin 来解决这个问题。

手写 Rust Async Model（二）：Reactor-Executor 模型

Sun, 26 Apr 2026 11:00:00 +0800

背景 & 问题：盲目轮询的代价

上一章我们写了一个最小 Runtime，它能跑，但有个致命问题——盲目轮询（busy polling）。即使 I/O 没准备好，Runtime 也在反复 poll()，白白消耗 CPU 资源。

这就像你点了外卖，每隔 10 秒打电话问外卖员"到了没？"——你在"猜"什么时候该 poll。

我们需要的是：完全不主动 poll，等事件来了再 poll。这就是事件驱动的核心思想。

方案：Reactor-Executor 模型

事件驱动的异步运行时由四个核心组件组成：

组件	本质角色	核心职责
Future	状态机	表示异步任务，在 `poll()` 时推进状态，必要时注册唤醒机制
Executor	调度器	维护就绪队列，调度任务并调用 `poll()` 持续推进 Future
Waker	通知器	连接事件与调度的桥梁：在外部事件就绪时，通知 Executor 重新调度
Reactor	事件源	与操作系统交互（epoll/kqueue 等），监听 I/O/timer 事件，就绪时触发 Waker

整体协作流程：

Future 返回 Pending 时 → 向 Reactor 注册事件
 ↓
Reactor 监听到事件就绪 → 调用 Waker.wake()
 ↓
Waker 将任务放回就绪队列 → unpark Executor 线程
 ↓
Executor 从就绪队列取任务 → 再次 poll Future

实现步骤

第一步：定义 Waker（通知器）

Waker 的职责：把任务放回就绪队列，然后唤醒 Executor 线程。

/// 通知器：将任务放回就绪队列，并唤醒 Executor 线程
#[derive(Clone)]
pub struct Waker {
 /// 任务 ID
 id: usize,
 /// 共享的就绪队列
 queue: Arc<Mutex<VecDeque<usize>>>,
 /// Executor 所在线程（用于 unpark）
 thread: Thread,
}

impl Waker {
 /// 唤醒：将任务放回就绪队列，并 unpark Executor
 pub fn wake(&self) {
 self.queue.lock().unwrap().push_back(self.id);
 self.thread.unpark();
 }
}

三个字段各司其职：

id：标识需要被重新调度的任务
queue：共享的就绪队列，存放"可以重新 poll 的任务 ID"
thread：Executor 所在线程的句柄，用于 unpark() 唤醒

关键点：Waker 本身不执行任务，不调用 poll()，不推进状态机。它只负责"通知"。

第二步：定义 Reactor（事件监听者）

Reactor 的职责：等待外部事件，事件就绪后调用 Waker。

/// 事件监听者：后台线程等待 IO/timer 完成，完成后调用 wake
#[derive(Clone)]
pub struct Reactor;

impl Reactor {
 pub fn new() -> Self {
 Self
 }

 /// 注册一个定时器任务
 /// 在 dur 时间后调用 waker.wake()
 pub fn register_timer(&self, dur: Duration, waker: Waker) {
 thread::spawn(move || {
 thread::sleep(dur);
 waker.wake();
 });
 }
}

这里用 thread::sleep 模拟事件等待。在真实的运行时（如 tokio）中，Reactor 会使用操作系统提供的高效事件通知机制（Linux 的 epoll、macOS 的 kqueue 等）。

第三步：优化 Future Trait

由于引入了 Waker，Future 的 poll() 方法需要增加参数：

/// 简化版 Future Trait
pub trait MyFuture {
 type Output;
 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output>;
}

核心改动：Future 不再被忙轮询，而是主动注册唤醒通知。poll() 检查到任务未就绪时，会向 Reactor 注册事件，让它在事件就绪时调用 Waker。

第四步：实现 Delay Future

Delay 是一个等待指定时间后完成的 Future，利用事件驱动机制：

/// 延迟指定时间后完成的 Future
pub struct Delay {
 /// 时间到期的绝对时间点
 when: Instant,
 /// 是否已注册到 Reactor（防止重复注册）
 registered: bool,
 /// 任务 ID（用于日志）
 id: usize,
}

impl Delay {
 pub fn new(id: usize, ms: u64) -> Self {
 Self {
 when: Instant::now() + Duration::from_millis(ms),
 registered: false,
 id,
 }
 }
}

impl MyFuture for Delay {
 type Output = ();

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 // 时间已到 → 完成
 if Instant::now() >= self.when {
 println!("task {} done", self.id);
 return PollState::Ready(());
 }

 // 只注册一次事件（防止重复 wake）
 if !self.registered {
 let dur = self.when - Instant::now();
 let reactor = Reactor::new();
 reactor.register_timer(dur, waker.clone());
 self.registered = true;
 }

 PollState::Pending
 }
}

注意 registered 字段的作用——防止重复注册。如果每次 poll() 都注册一次，会导致重复唤醒、任务被多次调度，甚至引发逻辑错误。

第五步：定义 Executor（任务调度器）

Executor 的职责：管理所有任务的生命周期——创建、调度、轮询、回收。

/// 任务类型: 封装一个可发送的 Future
type Task = Box<dyn MyFuture<Output = ()> + Send>;

/// 任务调度器：从就绪队列取任务，poll Future
pub struct Executor {
 /// 任务表，存储所有未完成的任务
 tasks: HashMap<usize, Task>,
 /// 就绪队列：等待被 poll 的任务 ID
 queue: Arc<Mutex<VecDeque<usize>>>,
 /// 下一个任务 ID
 next_id: usize,
}

impl Executor {
 pub fn new() -> Self {
 Self {
 tasks: HashMap::new(),
 queue: Arc::new(Mutex::new(VecDeque::new())),
 next_id: 0,
 }
 }

 /// 提交一个异步任务
 pub fn spawn<F>(&mut self, fut: F)
 where
 F: MyFuture<Output = ()> + Send + 'static,
 {
 let id = self.next_id;
 self.next_id += 1;
 self.tasks.insert(id, Box::new(fut));
 self.queue.lock().unwrap().push_back(id);
 }

 /// 运行调度循环，直到所有任务完成
 pub fn run(&mut self) {
 let current_thread = thread::current();

 loop {
 // 从就绪队列取一个任务
 // 注意：必须用独立代码块限定锁的生命周期
 // 否则 MutexGuard 的临时变量生命周期会延长到整个 match 块
 // 导致 park() 时仍持有锁，造成死锁
 let id = {
 let mut q = self.queue.lock().unwrap();
 q.pop_front()
 };

 let id = match id {
 Some(id) => id,
 None => {
 if self.tasks.is_empty() {
 // 所有任务已完成
 break;
 }
 // 还有任务但都 Pending → park 等待 wake
 thread::park();
 continue;
 }
 };

 // 从任务表中取出任务
 let mut task = match self.tasks.remove(&id) {
 Some(t) => t,
 None => continue,
 };

 // 创建 Waker（与就绪队列共享）
 let waker = Waker {
 id,
 queue: self.queue.clone(),
 thread: current_thread.clone(),
 };

 // poll 任务
 match task.poll(&waker) {
 PollState::Ready(()) => {
 // 完成 → 丢弃
 }
 PollState::Pending => {
 // 未完成 → 放回
 self.tasks.insert(id, task);
 }
 }
 }
 }
}

run() 方法的调度循环流程：

取任务 ID：从就绪队列中取出队首的任务 ID
取任务：在 HashMap 中根据 ID 取出 Task 实例
创建 Waker：为任务创建专属 Waker
poll() 并处理结果：完成则丢弃，未完成则放回

示例 & 踩坑

运行示例

fn main() {
 let mut exec = Executor::new();

 // 3 个并发延迟任务
 exec.spawn(Delay::new(1, 500));
 exec.spawn(Delay::new(2, 1000));
 exec.spawn(Delay::new(3, 1500));

 let start = Instant::now();
 exec.run();
 println!("非并发的耗时: 3s");
 println!("实际的并发耗时: {:?}", start.elapsed());
}

三个任务分别等待 500ms、1000ms、1500ms。由于是事件驱动的，总耗时约 1.5 秒（最长的那个任务的时间），而不是串行的 3 秒。

调度循环详细流程

1. Executor::spawn(Delay{500ms}) → task 0 加入就绪队列
 Executor::spawn(Delay{1000ms}) → task 1 加入就绪队列
 Executor::spawn(Delay{1500ms}) → task 2 加入就绪队列

2. Executor::run() 开始循环

3. 从队列取出 task 0 → poll → 时间未到
 → 注册 500ms 定时器到 Reactor
 → Reactor spawn 线程 A（sleep 500ms 后调用 waker0.wake()）
 → task 0 返回 Pending，放回 tasks

4. 从队列取出 task 1 → poll → 时间未到 → 注册 1000ms 定时器
5. 从队列取出 task 2 → poll → 时间未到 → 注册 1500ms 定时器

6. 队列为空，tasks 不为空 → thread::park()，Executor 休眠

7. 500ms 后，线程 A 醒来，调用 waker0.wake()
 → task 0 的 ID 被放入就绪队列
 → thread.unpark() 唤醒 Executor

8. Executor 醒来，poll task 0 → Ready → 移除

9. 1000ms 后，waker1.wake() → poll task 1 → Ready
10. 1500ms 后，waker2.wake() → poll task 2 → Ready

11. tasks 为空，退出循环

踩坑：Mutex 锁的生命周期

run() 方法中取任务 ID 时，必须用独立代码块限定锁的生命周期：

// 正确写法
let id = {
 let mut q = self.queue.lock().unwrap();
 q.pop_front()
};

// 错误写法：锁的生命周期可能延长到 park() 时
// let id = self.queue.lock().unwrap().pop_front();

如果锁的生命周期延长到 thread::park()，会导致死锁——Executor 持着锁休眠，Reactor 线程调用 wake() 时试图获取锁，永远拿不到。

本章完整代码

use std::collections::{HashMap, VecDeque};
use std::sync::{Arc, Mutex};
use std::thread::{self, Thread};
use std::time::{Duration, Instant};

// ================== 核心抽象 ==================

/// Future 的状态
pub enum PollState<T> {
 Ready(T),
 Pending,
}

/// 所有异步任务都必须实现这个 trait
pub trait MyFuture {
 type Output;
 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output>;
}

// ================== Waker ==================

#[derive(Clone)]
pub struct Waker {
 id: usize,
 queue: Arc<Mutex<VecDeque<usize>>>,
 thread: Thread,
}

impl Waker {
 pub fn wake(&self) {
 self.queue.lock().unwrap().push_back(self.id);
 self.thread.unpark();
 }
}

// ================== Reactor ==================

#[derive(Clone)]
pub struct Reactor;

impl Reactor {
 pub fn new() -> Self {
 Self
 }

 pub fn register_timer(&self, dur: Duration, waker: Waker) {
 thread::spawn(move || {
 thread::sleep(dur);
 waker.wake();
 });
 }
}

// ================== Delay Future ==================

pub struct Delay {
 when: Instant,
 registered: bool,
 id: usize,
}

impl Delay {
 pub fn new(id: usize, ms: u64) -> Self {
 Self {
 when: Instant::now() + Duration::from_millis(ms),
 registered: false,
 id,
 }
 }
}

impl MyFuture for Delay {
 type Output = ();

 fn poll(&mut self, waker: &Waker) -> PollState<Self::Output> {
 if Instant::now() >= self.when {
 println!("task {} done", self.id);
 return PollState::Ready(());
 }

 if !self.registered {
 let dur = self.when - Instant::now();
 let reactor = Reactor::new();
 reactor.register_timer(dur, waker.clone());
 self.registered = true;
 }

 PollState::Pending
 }
}

// ================== Executor ==================

type Task = Box<dyn MyFuture<Output = ()> + Send>;

pub struct Executor {
 tasks: HashMap<usize, Task>,
 queue: Arc<Mutex<VecDeque<usize>>>,
 next_id: usize,
}

impl Executor {
 pub fn new() -> Self {
 Self {
 tasks: HashMap::new(),
 queue: Arc::new(Mutex::new(VecDeque::new())),
 next_id: 0,
 }
 }

 pub fn spawn<F>(&mut self, fut: F)
 where
 F: MyFuture<Output = ()> + Send + 'static,
 {
 let id = self.next_id;
 self.next_id += 1;
 self.tasks.insert(id, Box::new(fut));
 self.queue.lock().unwrap().push_back(id);
 }

 pub fn run(&mut self) {
 let current_thread = thread::current();

 loop {
 let id = {
 let mut q = self.queue.lock().unwrap();
 q.pop_front()
 };

 let id = match id {
 Some(id) => id,
 None => {
 if self.tasks.is_empty() {
 break;
 }
 thread::park();
 continue;
 }
 };

 let mut task = match self.tasks.remove(&id) {
 Some(t) => t,
 None => continue,
 };

 let waker = Waker {
 id,
 queue: self.queue.clone(),
 thread: current_thread.clone(),
 };

 match task.poll(&waker) {
 PollState::Ready(()) => {}
 PollState::Pending => {
 self.tasks.insert(id, task);
 }
 }
 }
 }
}

// ================== main ==================

fn main() {
 let mut exec = Executor::new();
 let start = Instant::now();

 exec.spawn(Delay::new(1, 500));
 exec.spawn(Delay::new(2, 1000));
 exec.spawn(Delay::new(3, 1500));

 exec.run();

 println!("非并发的耗时: 3s");
 println!("实际的并发耗时: {:?}", start.elapsed());
}

总结

这一章我们引入了事件驱动架构，实现了 Reactor-Executor 模型的完整闭环：

Waker：通知器，将任务放回就绪队列并唤醒 Executor
Reactor：事件监听者，等待外部事件就绪后触发 Waker
Executor：任务调度器，管理就绪队列和任务生命周期
Delay Future：利用事件驱动机制的异步延迟任务

相比上一章的盲目轮询，现在的 Runtime 完全是事件驱动的——不再猜什么时候 poll，而是等事件来了再 poll。但目前的运行时只支持单个 Future 的执行，下一章我们将实现并发任务调度，支持 JoinAll、Then、Select 等组合器。

手写 Rust Async Model（一）：简易版 Future 结构

Sun, 26 Apr 2026 10:00:00 +0800

背景 & 问题：阻塞式编程的代价

假设你有 3 个任务要执行，每个任务耗时 1 秒，最直觉的写法是这样的：

for i in 1..=3 {
 println!("任务 {} 开始", i);
 thread::sleep(Duration::from_secs(1));
 println!("任务 {} 完成", i);
}

这段代码没有任何问题——除了慢。三个任务串行执行，总耗时约 3 秒。在这 3 秒里，线程在 thread::sleep 期间什么都不做，只能傻等。这就是阻塞式编程。

类比现实：这就像你站在厨房，烧水的时候死盯着水壶看，什么都不做。等水开了再去切菜，等菜切完了再煮汤。效率极低。

我们需要一种非阻塞的方式：当一个任务在等待时，线程可以先去做别的事情。Rust 中实现这种思路的核心抽象就是 Future。

方案：Future 状态机

Rust 中的 Future 本质是一个被动状态机——它由"数据 + 状态 + 状态推进逻辑"组成。外部通过调用 poll() 方法来驱动它前进。

整个过程分为三步：

定义协议——Future Trait 和状态枚举 PollState
实现状态机——让具体的异步任务实现这个 Trait
驱动执行——写一个 Runtime 反复调用 poll() 直到任务完成

实现步骤

第一步：定义 Future Trait 和 PollState

要让所有异步任务都遵循同一套协议，我们需要一个 Trait 作为标准：

/// Future 状态机的状态
pub enum PollState<T> {
 /// 任务已完成，携带返回值 T
 Ready(T),
 /// 任务尚未完成
 Pending,
}

/// 简化版 Future Trait
pub trait MyFuture {
 /// 异步任务的返回值类型
 type Output;

 /// 推进状态机
 /// 调用后要么返回 Ready(结果)，要么返回 Pending（稍后再试）
 fn poll(&mut self) -> PollState<Self::Output>;
}

type Output 是关联类型，表示这个 Future 完成后返回什么
poll() 是核心方法：调用一次，状态机前进一步。要么 Ready(结果)，要么 Pending

注意：这里 poll() 的签名和标准库不同（没有 Pin 和 Context），我们先从最简单的版本开始，后续章节会逐步补全。

第二步：实现一个具体的 Future

接下来让一个具体的结构体实现 MyFuture。CountFuture 持有一个计数器，每次 poll 减一，减到零时返回完成：

/// 需要多次 poll 才能完成的 Future
struct CountFuture {
 count: u32,
}

impl CountFuture {
 fn new(count: u32) -> Self {
 Self { count }
 }
}

impl MyFuture for CountFuture {
 type Output = &'static str;

 fn poll(&mut self) -> PollState<Self::Output> {
 if self.count == 0 {
 PollState::Ready("finished")
 } else {
 println!(" count = {}", self.count);
 self.count -= 1;
 PollState::Pending
 }
 }
}

关键点：Future 内部持有状态，poll() 负责推进状态。每次调用 poll()，count 减一，状态机往前走一步。

第三步：写一个 Runtime 驱动 Future

Future 本身只是状态机，需要一个外部"驱动器"来反复调用 poll()。这个驱动器就是 Runtime：

struct Runtime;

impl Runtime {
 fn block_on<F: MyFuture>(&mut self, mut future: F) -> F::Output {
 loop {
 match future.poll() {
 PollState::Ready(val) => return val,
 PollState::Pending => {
 // 模拟等待（真实情况是 IO 事件就绪）
 thread::sleep(Duration::from_millis(200));
 }
 }
 }
 }
}

block_on 做的事很简单：

接收一个实现了 MyFuture 的任务
反复调用 poll()，推动状态机前进
如果返回 Ready(val)，把结果返回给调用者
如果返回 Pending，等一会儿再 poll()

把所有代码串起来运行：

fn main() {
 let mut rt = Runtime;
 let result = rt.block_on(CountFuture::new(3));
 println!("最终结果: {}", result);
}

输出：

 count = 3
 count = 2
 count = 1
最终结果: finished

示例 & 踩坑

当前模型的核心问题

现在我们有了一个完整的闭环：Future 定义"做什么"，Runtime 负责驱动。但这个 Runtime 有一个致命问题——它在盲目轮询（busy polling）。

这就像你点了外卖，每隔 10 秒打电话问外卖员：“到了没？到了没？到了没？” 外卖员还没出发呢，你的电话费先亏完了。

问题出在 Runtime 的这段代码：

PollState::Pending => {
 // 模拟等待
 thread::sleep(Duration::from_millis(200));
}

Runtime 在"猜"什么时候该 poll——它不知道事件什么时候就绪，只能傻等。这浪费了 CPU 资源和等待时间。

本质问题：Future 没有主动通知 Runtime 的能力。

本章完整代码

use std::thread;
use std::time::Duration;

// ================== 核心抽象 ==================

/// Future 的状态
pub enum PollState<T> {
 /// 任务已完成，携带返回值
 Ready(T),
 /// 任务尚未完成
 Pending,
}

/// 所有异步任务都必须实现这个 trait
pub trait MyFuture {
 /// 异步任务的返回值类型
 type Output;

 /// 推进状态机
 fn poll(&mut self) -> PollState<Self::Output>;
}

// ================== 具体实现 ==================

/// 需要多次 poll 才能完成的 Future
struct CountFuture {
 count: u32,
}

impl CountFuture {
 fn new(count: u32) -> Self {
 Self { count }
 }
}

impl MyFuture for CountFuture {
 type Output = &'static str;

 fn poll(&mut self) -> PollState<Self::Output> {
 if self.count == 0 {
 PollState::Ready("finished")
 } else {
 println!(" count = {}", self.count);
 self.count -= 1;
 PollState::Pending
 }
 }
}

// ================== 运行时 ==================

/// 最简单的 Runtime：反复调用 poll 直到完成
struct Runtime;

impl Runtime {
 fn block_on<F: MyFuture>(&mut self, mut future: F) -> F::Output {
 loop {
 match future.poll() {
 PollState::Ready(val) => return val,
 PollState::Pending => {
 // 模拟等待（真实情况是 IO 事件就绪）
 thread::sleep(Duration::from_millis(200));
 }
 }
 }
 }
}

// ================== main ==================

fn main() {
 let mut rt = Runtime;
 let result = rt.block_on(CountFuture::new(3));
 println!("最终结果: {}", result);
}

总结

这一章我们从阻塞式编程的问题出发，实现了 Rust 异步编程的最底层抽象：

PollState<T>：Future 的两种状态——Ready 和 Pending
MyFuture Trait：所有异步任务的标准协议，核心方法是 poll()
CountFuture：一个具体的状态机实现
Runtime：驱动 Future 执行的运行时

但当前的 Runtime 存在一个严重问题：盲目轮询。下一章我们将引入事件驱动模型，让 Future 在事件就绪时主动通知 Runtime，彻底解决这个问题。