Rust 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 内存模型是怎么想出来的

Wed, 01 Jul 2026 10:00:00 +0800

凌晨三点的 segfault

2014 年 4 月，OpenSSL 爆出 Heartbleed。一个缓冲区越界读漏洞，让攻击者可以一遍遍抠出服务器进程的内存碎片，里面有机票订单、Session Cookie，甚至私钥。整个互联网紧急停摆，CVE 编号 CVE-2014-0160。

这并不是孤例。微软和 Google 的内部统计都显示，约 70% 的安全漏洞本质上是内存安全问题。

凌晨三点，你的 C 服务挂了。日志里写着 segmentation fault (core dumped)。你打开 gdb，看到一个悬垂指针，指向一块已经被释放的内存。

这种事系统程序员干了三十年。

于是有人开始问一个怪问题：能不能设计一门语言，从语法上就不让这类错误发生？

Java 和 Go 选了 GC，安全但运行时不可控。Rust 走了第三条路：把所有内存错误在编译期挡住，运行时零成本。

这条路是怎么想出来的？

内存管理要回答的三个问题

任何一门语言，处理内存都要回答三个问题：

谁来分配和释放？
怎么共享同一块内存？
怎么避免访问到无效内存？

第一个问题的三种主流答法，基本定义了一门语言的性格：

方案	思路	优点	代价
手动管理 (C)	程序员自己 malloc/free	极致控制，零运行时开销	内存泄漏、双重释放、悬垂指针
垃圾回收 (Java/Go)	后台 GC 自动清理	开发门槛低	STW 停顿、内存峰值不可控
所有权 (Rust)	编译期插入释放代码	兼顾安全与性能	学习曲线陡

后面三节分别对应这三个问题。Rust 的答案放在一起看才显得天才：单独拿任何一条出来都不新鲜，组合在一起就是另一回事。

第一道：谁来分配和释放？

所有权的三条规则

Rust 的答案叫 Ownership，规则只有三条：

每个值在任意时刻有且只有一个 owner
当 owner 离开作用域，值被自动释放
把值赋给别人，所有权 move，原变量失效

三条加在一起，编译器就能在编译期精确推导每一块内存什么时候该释放。不需要引用计数，不需要 GC 扫描，不需要程序员手写 free。

一个最小的例子

{
 let s = String::from("hello");
 // s 是这块堆内存的 owner
}
// 离开作用域，String 的 drop 自动被调用，内存释放

drop 是编译器在作用域结束处自动插入的。这就是"零运行时开销"的真正含义：最终的机器码和你手写 free 一模一样，只是时机被编译器替你算好了。

Move 语义：赋值后原变量为什么不能用了

let s1 = String::from("hello");
let s2 = s1;

println!("{}", s1); // 编译错误：s1 已经被 move 了

C++ 程序员看到这段代码会本能地紧张：s1 和 s2 是不是指向同一块内存？析构的时候会不会 double free？

Rust 的回答简单粗暴：所有权已经 move 到 s2 了，s1 不再有效，编译器直接拒绝编译。

这看起来别扭，但它解决了一个根本问题：如果两个变量都能访问同一块堆内存，谁负责释放？引用计数？GC？Rust 选择不让这种情况在默认情况下发生。

对照：C 的 use-after-free

char *s = malloc(10);
free(s);
printf("%s\n", s); // 未定义行为，可能崩溃，也可能默默错下去

这种 bug 在 C 里能跑很久才暴露，等到暴露时已经不知道是谁的锅。Rust 里它根本编译不过。

第二道：怎么共享内存？

如果所有权严格只能 move，那很多场景就难办了。函数传参怎么办？是不是每次调用都要把所有权交出去再还回来？

Rust 的答案是 借用 (borrowing)。所有权不交出去，只把使用权临时借出去。

借用规则

借用有两条铁律：

任意时刻，可以有 多个不可变引用 &T
或者 一个可变引用 &mut T，两者不能共存

这两条规则强制实现了一个不变量：同一时间，要么多人读，要么一人写，不能同时发生。

这条规则顺手杀死了 data race

数据竞争 (data race) 在多线程编程里是出了名的难调。两个线程同时改一个变量，没有锁保护，结果完全不可预测。

但仔细想想：data race 的本质，就是"同时存在两个引用，且其中一个是 &mut"。Rust 的借用规则在编译期就把这种情况挡死了。

let mut v = vec![1, 2, 3];
let r1 = &mut v;
let r2 = &mut v; // 编译错误：不能同时有两个 &mut

r1.push(4);

这段代码编译不过。换 Java 它会跑得很欢，然后在某个深夜因为竞态条件挂掉。

一个类比

想象一块白板。借用规则说：要么一群人围观白板（多个 &），要么一个人独自擦写（一个 &mut）。前者保证白板内容不被改，后者保证没人看到擦一半的中间状态。这两件事在物理上不能同时发生，Rust 把这个物理常识编进了语言。

第三道：怎么避免无效内存？

无效内存主要来自两种情况：空指针 和 data race。后者借用规则已经顺手解决了，剩下的就是空指针。

Rust 没有 null

Tony Hoare 把 null 引入 ALGOL 称为自己"十亿美元的错误"。Rust 干脆把 null 从语言里删掉了。

那"没有值"怎么表达？用 Option<T>：

enum Option<T> {
 Some(T),
 None,
}

这个 enum 看起来平平无奇，但它的杀伤力在于：你必须显式处理 None，不能假装它不存在。

let name: Option<String> = find_user(id);

// 编译错误：不能直接当 String 用
// println!("{}", name.len());

// 必须显式处理
match name {
 Some(n) => println!("{}", n),
 None => println!("user not found"),
}

对比 Java：String name = findUser(id); name.length() 这段代码能编译通过，然后在 name 为 null 时抛 NullPointerException。Rust 让你根本写不出这种代码。

一个反复出现的模式

到这里你可能注意到了：Rust 把运行时错误挪到了编译期。

内存泄漏 → 所有权规则
数据竞争 → 借用规则
空指针 → Option 强制 match
资源泄漏 → Drop trait

这就是"零成本抽象"的真正含义：你不需要为安全付出运行时代价，但需要付出学习曲线的代价。

收尾：第三条路的代价与回报

回到开头的对比表。GC 用运行时开销换来了安全，C 用危险换来了自由，Rust 选了第三条路：用编译期的复杂性换运行时的零成本。

这条路不是免费的。借用检查器最初会让你怀疑人生，lifetime 标注会让你想念 GC 的温柔。无数新人卡在 “fighting the borrow checker” 阶段。

但回报是：你写出的并发代码，编译通过基本意味着没有数据竞争。这个说法不算夸张。前面提到约 70% 的安全漏洞是内存安全问题，Rust 在编译期把它们消灭了。

Rust 内存模型的真正天才之处，不在于它发明了什么新概念。所有权、借用、生命周期，每个单独看都不新鲜。天才之处在于把它们组合起来，让"内存安全"从程序员的自觉，变成了语言机制的强制保证。

从这个角度看，Rust 解决内存问题的方式更像一种哲学转变：与其事后修复，不如事前阻止。

References

Rust 迭代器的三个核心 Trait：Iterator、IntoIterator、FromIterator

Tue, 09 Jun 2026 10:00:00 +0800

引言

Rust 标准库中，迭代器无处不在。for 循环、map/filter/collect 链式调用、vec!.into_iter() —— 这些日常操作背后，由三个 trait 协同支撑：

Trait	职责	一句话
`Iterator`	逐个产出元素	“一个一个给我”
`IntoIterator`	把集合变成迭代器	“变成迭代器”
`FromIterator`	把迭代器变成集合	“收集成集合”

三者可以理解为一个数据管线：IntoIterator 将集合拆成逐个元素的管线入口，Iterator 在管线上做加工，FromIterator 把管线出口重新打包为集合。

集合 --<IntoIterator>--> 迭代器 --<Iterator(加工)>--> 迭代器 --<FromIterator>--> 集合

这篇重点讲三件事：

三个 trait 各自的定义和设计意图
for 循环的解糖原理和 collect() 的底层机制
如何为自定义集合实现完整的迭代器支持

前置知识：需要你熟悉 Rust 的 trait、泛型、生命周期和所有权机制。

IntoIterator：集合到迭代器的桥梁

IntoIterator 将容器转换为迭代器。

使用场景：让容器类型可直接用于 for 循环，或自定义容器委托已有迭代器实现。

Trait 定义

trait IntoIterator {
 // 迭代器产生的元素类型
 type Item;
 // 转换后得到的迭代器类型
 type IntoIter: Iterator<Item = Self::Item>;

 // 将当前类型转换为迭代器
 fn into_iter(self) -> Self::IntoIter;
}

type Item 迭代器产生的元素类型
type IntoIter 转换后得到的迭代器类型，必须实现 Iterator<Item = Self::Item>
fn into_iter(self) 消费 self，返回迭代器。注意参数是 self 不是 &self，调用 into_iter() 会拿走所有权

for 循环的本质

Rust for x in collection 是语法糖，底层依赖 IntoIterator trait，不要求类型实现 Iterator：

// 你写的：
for val in &sv {
 println!("{val}");
}

// 编译器看到的（简化版）：
let mut iter = (&sv).into_iter();

while let Some(val) = iter.next() {
 println!("{val}");
}

编译器默认调用 into_iter() 获取迭代器，再不断调用 next() 获取元素。更完整的展开：

let values = vec![1, 2, 3, 4, 5];
{
 let result = match IntoIterator::into_iter(values) {
 mut iter => loop {
 let next;
 match iter.next() {
 Some(val) => next = val,
 None => break,
 };
 let x = next;
 let () = { println!("{x}"); };
 },
 };
 result
}

所以 for x in values 之后 values 不可用，所有权被 into_iter(self) 拿走了。

三种迭代形式

标准库中的集合类型通常提供三种迭代方式：

方法	语义	产出的元素类型
`iter()`	借用迭代	`&T`
`iter_mut()`	可变借用迭代	`&mut T`
`into_iter()`	消费迭代	`T`

集合类型会为 &Collection、&mut Collection 和 Collection（自身）分别实现 IntoIterator：

let mut values = vec![41];

// &Vec<T> 实现了 IntoIterator，委托给 iter()
for x in &values {
 // x: &i32
}

// &mut Vec<T> 实现了 IntoIterator，委托给 iter_mut()
for x in &mut values {
 // x: &mut i32
 *x += 1;
}

// Vec<T> 实现了 IntoIterator，委托给 into_iter()
for x in values {
 // x: i32，values 被消费
}

for x in &values 等价于 for x in values.iter()，for x in &mut values 等价于 for x in values.iter_mut()。

Blanket Impl

标准库有一个关键的 blanket implementation：

impl<I: Iterator> IntoIterator for I {
 type Item = I::Item;
 type IntoIter = I;
 fn into_iter(self) -> I {
 self
 }
}

所有实现了 Iterator 的类型自动实现 IntoIterator，这意味着任何自定义迭代器都可以直接用在 for 循环中，接受 impl IntoIterator 参数的函数既可以传集合也可以传迭代器：

fn print_all<I: IntoIterator>(iterable: I) {
 for item in iterable {
 println!("{item:?}");
 }
}

let v = vec![1, 2, 3];
print_all(&v); // 传 &Vec<i32>
print_all(v.iter()); // 传 std::slice::Iter<i32>
print_all(1..=5); // 传 std::ops::RangeInclusive<i32>

Iterator：迭代器的核心

实现 Iterator 的类型本身就是一个迭代器，它定义了许多 Combinator Methods 用来对元素进行加工。

使用场景：遍历元素、数据转换与过滤、链式数据处理。

Trait 定义

pub trait Iterator {
 // 当前迭代器产生的元素类型
 type Item;

 // 获取下一个元素
 fn next(&mut self) -> Option<Self::Item>;

 // Combinator Methods，用于执行加工操作
 // fn map(...)
 // fn filter(...)
 // fn fold(...)
 // fn collect(...)
 // ...其余 76+ 个方法全部有默认实现，都建立在 next() 之上
}

type Item 当前迭代器产生的元素类型
next() 返回 Some(Item) 表示还有元素，None 表示结束。&mut self 说明每次调用会修改内部状态

Rust 的迭代器是惰性的，仅创建一个迭代器什么都不会发生，只有调用 next() 或消费适配器时才开始工作。

Combinator Methods

这些默认方法可以分为两大类。

Consuming Adapters，消耗原迭代器，返回结果：

let v = vec![1, 2, 3];

let total: i32 = v.iter().sum(); // 求和
let count = v.iter().count(); // 计数
let v2: Vec<i32> = v.iter()
 .map(|x| x + 1)
 .collect(); // 收集成集合

调用后迭代器被消耗，不能再次使用。

Iterator Adapters，不消耗原迭代器，返回新的迭代器：

let v = vec![1, 2, 3, 4, 5];

let result: Vec<i32> = v.iter()
 .filter(|&&x| x % 2 == 0)
 .map(|&x| x * 10)
 .collect();
assert_eq!(result, vec![20, 40]);

Iterator Adapters 也是惰性的，上面如果去掉 .collect()，filter 和 map 里的闭包不会执行，编译器会警告：

warning: unused `Map` that must be used
 = note: iterators are lazy and do nothing unless consumed

迭代器适配器都是泛型结构体，编译器在单态化之后能将整个迭代器链内联优化。Rust Book 第 13 章给出了一个基准测试，在《福尔摩斯探案集》全文中搜索单词，迭代器版本和手写 for 循环性能几乎相同，甚至略快。

自定义迭代器

两步就够了：定义一个结构体保存状态，然后为它实现 Iterator。一个从 1 数到 5 的迭代器：

struct Counter {
 count: usize,
}

impl Counter {
 fn new() -> Self {
 Counter { count: 0 }
 }
}

impl Iterator for Counter {
 type Item = usize;

 fn next(&mut self) -> Option<Self::Item> {
 self.count += 1;
 if self.count < 6 {
 Some(self.count)
 } else {
 None
 }
 }
}

实现了 Iterator 之后，所有 Combinator Methods 全部可用：

let sum: usize = Counter::new().sum();
assert_eq!(sum, 15);

let doubled: Vec<usize> = Counter::new().map(|x| x * 2).collect();
assert_eq!(doubled, vec![2, 4, 6, 8, 10]);

FromIterator：迭代器到集合的桥梁

FromIterator 允许用迭代器中产出的元素流来构建一个具体类型。

使用场景：构建集合（.collect() 底层机制）、类型转换、错误处理（Result 实现了 FromIterator，可以实现 fail-fast）。

Trait 定义

trait FromIterator<A>: Sized {
 // 从一个迭代器构建目标类型
 fn from_iter<T: IntoIterator<Item = A>>(iter: T) -> Self;
}

A 元素类型
接受任何实现了 IntoIterator<Item = A> 的类型作为输入

.collect() 的本质

FromIterator 是 .collect() 的底层支撑。collect() 的简化逻辑：

fn collect<B: FromIterator<Self::Item>>(self) -> B {
 FromIterator::from_iter(self)
}

let doubled: SortedVec<i32> = sv
 .into_iter()
 .filter(|&x| x > 1)
 .map(|x| x * 2)
 .collect();

对于上面的代码，之所以用 .collect() 就能生成 SortedVec<i32>，是因为你用 : SortedVec<i32> 显式指定了目标类型，编译器去找 impl FromIterator<i32> for SortedVec<i32>，并调用其 from_iter() 方法生成目标集合。

当 turbofish 嵌套过深时，FromIterator::from_iter() 的写法更清晰：

// 两种写法等价
let deque: VecDeque<i32> = (0..10).collect();
let deque = VecDeque::from_iter(0..10);

标准库中的实现

几乎所有标准库集合都实现了 FromIterator：

// Vec<T>
let v: Vec<i32> = (1..=5).collect();

// HashMap<K, V>
let map: HashMap<&str, i32> = [("a", 1), ("b", 2)].into_iter().collect();

// Result<Vec<T>, E> - 收集多个 Result
let results: Vec<Result<i32, &str>> = vec![Ok(1), Ok(2), Ok(3)];
let collected: Result<Vec<i32>, &str> = results.into_iter().collect();
assert_eq!(collected, Ok(vec![1, 2, 3]));

// Option<Vec<T>> - 收集多个 Option
let options: Vec<Option<i32>> = vec![Some(1), Some(2), Some(3)];
let collected: Option<Vec<i32>> = options.into_iter().collect();
assert_eq!(collected, Some(vec![1, 2, 3]));

Result 和 Option 的 FromIterator 实现让 .collect() 变成短路操作，遇到第一个 Err 或 None 就停止收集并返回。

总结

Trait	核心方法	职责	何时实现
`IntoIterator`	`fn into_iter(self) -> Self::IntoIter`	集合转迭代器	为自定义集合实现（通常提供 `&T`、`&mut T`、`T` 三种版本）
`Iterator`	`fn next(&mut self) -> Option<Self::Item>`	加工迭代器中的元素	为自定义迭代器结构体实现
`FromIterator`	`fn from_iter<I: IntoIterator<Item = A>>(iter: I) -> Self`	迭代器转集合	为自定义集合实现，支持 `.collect()`

实战：为自定义集合实现完整的迭代器支持

目标：为一个保持元素有序的 SortedVec 集合实现三个核心 trait，让它能用在 for 循环中，也能用 .collect() 构建。

先看骨架，试试自己能不能补完（提示在注释中）：

use std::iter::FromIterator;

#[derive(Debug)]
struct SortedVec<T> {
 data: Vec<T>,
}

impl<T: Ord> SortedVec<T> {
 fn new() -> Self {
 SortedVec { data: Vec::new() }
 }

 fn push(&mut self, item: T) {
 // 提示：用 iter().position() 找到第一个大于 item 的位置
 // 提示：用 Vec::insert 在该位置插入
 todo!()
 }
}

// 提示：为 SortedVec<T> 实现 IntoIterator
// - Item 类型是什么？
// - IntoIter 可以直接复用 Vec 的迭代器类型 std::vec::IntoIter<T>
// - into_iter 做什么？把 self.data 变成迭代器

// 提示：为 &'a SortedVec<T> 实现 IntoIterator（借用版本）
// - Item 类型是 &'a T
// - IntoIter 是 std::slice::Iter<'a, T>
// - into_iter 委托给 self.data.iter()

// 提示：为 SortedVec<T> 实现 FromIterator<T>
// - 遍历迭代器，对每个元素调用 push
// - 约束 T: Ord（因为 push 需要比较大小）

fn main() {
 let mut sv = SortedVec::from_iter([5, 1, 3, 2, 4]);
 sv.push(0);
 assert_eq!(sv.data, vec![0, 1, 2, 3, 4, 5]);

 for val in &sv {
 println!("{val}");
 }

 let doubled: SortedVec<i32> = sv
 .into_iter()
 .filter(|&x| x > 1)
 .map(|x| x * 2)
 .collect();
 assert_eq!(doubled.data, vec![4, 6, 8, 10]);
}

完整实现：

use std::iter::FromIterator;

#[derive(Debug)]
struct SortedVec<T> {
 data: Vec<T>,
}

impl<T: Ord> SortedVec<T> {
 fn new() -> Self {
 SortedVec { data: Vec::new() }
 }

 fn push(&mut self, item: T) {
 let pos = self.data.iter()
 .position(|x| x > &item)
 .unwrap_or(self.data.len());
 self.data.insert(pos, item);
 }
}

// IntoIterator（消费版本）
impl<T> IntoIterator for SortedVec<T> {
 type Item = T;
 type IntoIter = std::vec::IntoIter<T>;

 fn into_iter(self) -> Self::IntoIter {
 self.data.into_iter()
 }
}

// IntoIterator（借用版本）
impl<'a, T> IntoIterator for &'a SortedVec<T> {
 type Item = &'a T;
 type IntoIter = std::slice::Iter<'a, T>;

 fn into_iter(self) -> Self::IntoIter {
 self.data.iter()
 }
}

// FromIterator
impl<T: Ord> FromIterator<T> for SortedVec<T> {
 fn from_iter<I: IntoIterator<Item = T>>(iter: I) -> Self {
 let mut sv = SortedVec::new();
 for item in iter {
 sv.push(item);
 }
 sv
 }
}

fn main() {
 let mut sv = SortedVec::from_iter([5, 1, 3, 2, 4]);
 sv.push(0);
 assert_eq!(sv.data, vec![0, 1, 2, 3, 4, 5]);

 for val in &sv {
 println!("{val}");
 }

 let doubled: SortedVec<i32> = sv
 .into_iter()
 .filter(|&x| x > 1)
 .map(|x| x * 2)
 .collect();
 assert_eq!(doubled.data, vec![4, 6, 8, 10]);
}

SortedVec 内部是 Vec，直接复用 Vec 的迭代器，不需要自定义 Iterator 实现（写法见上文 Counter 示例）。需要手写的是 IntoIterator（借用和消费两种版本）和 FromIterator（支持 .collect()）。

References

RAII：将资源生命周期绑定给对象

Mon, 11 May 2026 09:00:00 +0800

背景

在系统编程中，资源管理是一个核心问题。无论是内存、文件句柄、Socket 连接还是锁，都需要在不再使用时正确释放。如果忘记释放，就会造成资源泄漏；如果重复释放，又会导致未定义行为。

传统做法是让开发者手动管理资源的获取和释放——在 C 语言中这体现为成对的 malloc/free、fopen/fclose 调用。这种方式灵活但脆弱，一旦控制流变得复杂（异常、早期返回、嵌套调用），很容易遗漏释放逻辑。

RAII (Resource Acquisition Is Initialization，资源获取即初始化) 提供了一种优雅的解决思路：将资源的生命周期绑定到对象的生命周期上。对象创建时获取资源，对象销毁时自动释放资源。开发者不再需要手动编写清理代码，资源的释放由语言运行时保证。

本文将从 RAII 的核心思想出发，重点讲解 Rust 如何通过 Drop trait 实现这一机制，并对比 C++、Java、Go 中资源管理方式的差异。

RAII 的核心思想

RAII 的原则很简单：资源生命周期与对象生命周期绑定。

具体来说有三个关键特性：

安全性：避免内存泄漏和双重释放，资源的释放由编译器保证，而非依赖开发者记忆
简洁性：调用者无需显式编写 cleanup 代码，减少出错的可能
确定性释放：资源在对象离开作用域时立即释放，不需要依赖不确定性 GC 的调度

RAII 的典型使用场景包括：

自动释放文件句柄、Socket 连接、数据库连接
互斥锁的自动释放（离开临界区即解锁）
临时状态的恢复（如修改配置后自动还原）
事务的自动回滚
Scope Exit 清理逻辑

本质上，RAII 做的事情是：把操作系统层面的物理资源，映射为代码中的逻辑对象，不需要依赖不确定性 GC 的调度。

Rust 中的 RAII 实现

Rust 将 RAII 作为语言规范的一部分，通过三个核心机制协同实现：Drop trait、所有权系统和生命周期。

当所有权变量超出作用域时，Rust 会自动：

释放变量占用的内存
调用该变量的析构函数（drop），释放被映射给它的资源

Drop trait

Rust 通过 Drop trait 提供析构函数机制。当资源超出作用域时，编译器会自动插入对 drop 方法的调用。

Drop trait 只有一个方法：

fn drop(&mut self);

下面是一个完整的示例：

struct FileGuard;

impl Drop for FileGuard {
 fn drop(&mut self) {
 println!("release resource");
 }
}

fn main() {
 let _f = FileGuard;

 println!("working...");
}
// 离开作用域时，编译器自动调用 _f 的 drop()
// 输出顺序：
// working...
// release resource

注意输出顺序——drop 在 main 函数结束、变量离开作用域时被调用，这正是 RAII 确定性释放的体现。

所有权与 RAII 的配合

Rust 的所有权系统进一步强化了 RAII 的保证。因为每个值在任意时刻只有一个所有者，所以不存在"多个对象引用同一资源但无法确定谁负责释放"的问题。当所有者离开作用域，资源必定被释放，且只释放一次。

其他语言中的资源管理

不同语言对 RAII 的支持程度各不相同，理解这些差异有助于在实际项目中做出合理的技术选择。

C++：RAII 的原产地

C++ 从 C++98 开始就在标准库中支持 RAII，是最早将这一思想内化为语言习惯的编程语言。

核心实现方式：

构造函数获取资源
析构函数释放资源

标准库提供了大量 RAII 包装器：

// 智能指针
std::make_unique<T>() // 独占所有权
std::make_shared<T>() // 共享所有权

// 其他 RAII 类型
std::scoped_lock<Mutex> // 自动解锁
std::fstream // 自动关闭文件

C++ 中 RAII 与异常机制天然配合——即使函数因异常中途返回，栈展开过程中仍会调用局部对象的析构函数，确保资源被正确释放。

Java 和 Go：依赖 GC 和显式清理

Java 和 Go 不属于典型的 RAII 语言。它们的资源释放并不真正绑定对象生命周期，因此不具备严格意义上的 RAII 语义。

两者的共同特点：

内存由 GC 自动管理，开发者无需手动释放
非内存资源（文件、Socket、锁等）仍需显式关闭

以 Java 为例，try-with-resources 语法虽然提供了类似 RAII 的自动关闭能力，但本质上是通过 AutoCloseable 接口和编译器生成的 finally 块实现的，而非对象析构：

try (var file = new FileInputStream("data.txt")) {
 // 使用 file
}
// 离开 try 块后 file 自动关闭
// 但关闭时机依赖 finally 的执行，而非对象 GC

Go 则更加依赖显式的 defer 来保证清理逻辑执行：

func processFile() error {
 f, err := os.Open("data.txt")
 if err != nil {
 return err
 }
 defer f.Close() // 函数返回时执行

 // 使用 f
 return nil
}

defer 提供了确定性的清理保证，但它绑定的是函数作用域而非对象生命周期，与 RAII 的语义仍有本质区别。

对比总结

特性	Rust	C++	Java	Go
RAII 支持	语言规范级	语言习惯级	有限（try-with-resources）	有限（defer）
内存管理	所有权 + Drop	RAII 智能指针	GC	GC
非内存资源	Drop trait 自动释放	析构函数自动释放	AutoCloseable / 显式	defer / 显式
释放确定性	作用域结束时	作用域结束时	GC 调度不确定	函数返回时

总结

RAII 的核心价值在于将资源管理的正确性从开发者的自觉转移到了语言机制的保证上。

在 Rust 中，Drop trait + 所有权系统构成了语言级的 RAII 支持，编译器确保资源在离开作用域时被释放，且只释放一次
在 C++ 中，RAII 是长期以来的惯用模式，构造/析构函数和栈展开机制提供了完整的保证
在 Java 和 Go 中，GC 解决了内存管理问题，但非内存资源仍需通过 try-with-resources 或 defer 等机制显式管理，与真正的 RAII 存在语义差异

如果你正在使用 Rust 或 C++，充分利用 RAII 可以大幅减少资源管理的 bug。如果你来自 Java 或 Go 背景，理解 RAII 的思想也有助于写出更安全、更简洁的资源管理代码。

References

手写 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，彻底解决这个问题。

Rust 所有权系统详解

Mon, 16 Mar 2026 12:00:00 +0800

什么是所有权

所有权（Ownership）是 Rust 最独特的特性，它使 Rust 无需垃圾回收就能保证内存安全。

所有权规则

Rust 中每个值都有一个所有者（owner）
值在同一时间只能有一个所有者
当所有者离开作用域，值将被丢弃

示例代码

{
 let s = String::from("hello"); // s 是所有者
 // 使用 s
} // s 离开作用域，内存被自动释放

移动语义

let s1 = String::from("hello");
let s2 = s1; // s1 的所有权移动到 s2
// println!("{}", s1); // 错误！s1 已失效

总结

掌握所有权是学习 Rust 的关键，它带来：

内存安全，无需 GC
高性能，无运行时开销
明确的代码意图