首页 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

使用 TCC 模式处理分布式事务一致性

Tue, 26 May 2026 19:10:00 +0800

背景 & 问题

在分布式系统中，一个业务操作往往涉及多个服务。比如电商下单：库存服务扣减库存、订单服务创建订单、支付服务冻结金额。这些操作要么全部成功，要么全部失败——这就是分布式事务问题。

传统的单体应用可以用数据库事务（ACID）轻松解决，但分布式环境下，每个服务有自己的数据库，无法共享一个事务。常见的分布式事务方案有：

方案	核心思路	主要问题
2PC（两阶段提交）	协调者统一控制所有参与者的提交/回滚	同步阻塞、单点故障、性能差
3PC（三阶段提交）	在 2PC 基础上增加"预提交"阶段降低阻塞	实现复杂，仍存在网络分区问题

这些方案依赖数据库层面的全局锁，在高并发场景下性能瓶颈明显。

本文将介绍 TCC（Try-Confirm-Cancel）模式——一种参考 2PC 思想、但不依赖全局锁的分布式事务方案。你将了解到：

TCC 的核心思想和三阶段工作流程
TCC 架构设计及其与 2PC 的对比
用资金转账场景演示 TCC 的完整实现
6 个实现中必须解决的关键问题及其解决方案

前置知识

阅读本文需要了解以下概念（不熟悉也没关系，文中会配合上下文说明）：

分布式事务：跨多个服务或数据库的事务操作，需要保证数据一致性
最终一致性：允许数据在短时间内不一致，但保证最终会达到一致状态
幂等性：同一操作执行一次和多次产生的效果相同

方案或原理

TCC 是什么

TCC（Try-Confirm-Cancel）是一种基于业务补偿的分布式事务解决方案。它将一个完整的业务操作拆分为三个阶段：

阶段	职责	说明
Try	资源预留 / 可行性检查	冻结资源、检查前置条件，但不真正执行业务
Confirm	确认提交	真正执行业务操作，使用 Try 阶段预留的资源
Cancel	取消回滚	释放 Try 阶段预留的资源，恢复到操作前状态

核心思想：不依赖数据库全局锁，而是通过"资源预留 + 显式确认/取消"来控制事务状态。

TCC 本质上是一个带重试、可回滚的分布式状态机。

TCC vs 2PC

两者都采用"两阶段"的思想，但有本质区别：

维度	2PC	TCC
锁机制	数据库全局锁	业务层面资源预留（无全局锁）
实现层面	数据库 / 中间件	业务代码（每个服务实现 Try/Confirm/Cancel）
性能	同步阻塞，资源锁定时间长	无全局锁，并发性能好
侵入性	对业务代码侵入低	需要业务代码配合实现三个阶段
适用场景	对一致性要求极高	高并发、短事务场景

简单来说：2PC 让数据库来管锁，TCC 让业务代码自己管资源。

TCC 架构

核心组件：

事务管理器（TM）：发起分布式事务，决定全局提交或回滚
事务协调器（TC）：协调各分支事务的 Try/Confirm/Cancel 执行
参与者（RM）：各业务服务，实现 Try/Confirm/Cancel 三个接口

TCC 通用流程

flowchart TD
 A[发起分布式事务] --> B[Try 阶段: 资源预留/检查]
 B --> C{所有Try执行成功?}

 C -- 全部成功 --> D[Confirm 阶段: 真正提交执行]
 D --> E[事务完成]

 C -- 部分失败 --> F[Cancel 阶段: 回滚/释放资源]
 F --> G[事务回滚完成]

事务管理器发起分布式事务
Try 阶段：所有参与者执行资源预留和可行性检查
如果所有 Try 都成功，进入 Confirm 阶段，提交业务操作
如果任何一个 Try 失败，进入 Cancel 阶段，释放资源并回滚

优缺点

优势：

性能高：避免数据库长事务与全局锁
隔离性好：资源预留后对其他事务不可见
保证最终一致性，支持回滚操作

代价：

实现复杂：每个业务需要实现三个接口
对幂等要求极高：网络重试可能导致重复调用

适用场景

高并发、短事务：如电商下单、支付冻结
对一致性要求高：如金融交易
不适合长事务：资源会被长期冻结，影响系统性能

实现步骤

下面通过一个资金转账场景（A 账户向 B 账户转账 100 元）演示 TCC 的完整实现。

场景分析

涉及两个服务：

转出服务：从 A 账户扣款
转入服务：向 B 账户加款

1. Try 阶段：资源预留

Try 阶段不是真正扣款/加款，而是"冻结"对应金额。

// 转出服务 - Try：冻结 A 账户 100 元
public boolean tryDeduct(String txId, String accountId, BigDecimal amount) {
 // 检查余额是否充足
 Account account = accountDao.findById(accountId);
 if (account.getBalance().compareTo(amount) < 0) {
 throw new InsufficientBalanceException("余额不足");
 }

 // 冻结金额（可用余额减少，冻结金额增加）
 accountDao.freeze(accountId, amount);

 // 记录事务日志（幂等控制）
 transactionLogDao.save(new TransactionLog(txId, "TRY", accountId));
 return true;
}

// 转入服务 - Try：预增加 B 账户 100 元（标记为待确认）
public boolean tryAdd(String txId, String accountId, BigDecimal amount) {
 // 预增加金额（标记为冻结状态，不可用）
 accountDao.preAdd(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "TRY", accountId));
 return true;
}

关键点：Try 阶段通过"冻结"实现资源预留，而非真正执行业务。

2. Confirm 阶段：确认提交

所有 Try 成功后，执行真正的业务操作。

// 转出服务 - Confirm：真正扣除冻结金额
public boolean confirmDeduct(String txId, String accountId, BigDecimal amount) {
 // 幂等检查：是否已执行过
 if (transactionLogDao.exists(txId, "CONFIRM")) {
 return true;
 }

 // 扣除冻结金额
 accountDao.deductFrozen(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CONFIRM", accountId));
 return true;
}

// 转入服务 - Confirm：将预增加金额转为可用
public boolean confirmAdd(String txId, String accountId, BigDecimal amount) {
 if (transactionLogDao.exists(txId, "CONFIRM")) {
 return true;
 }

 accountDao.confirmPreAdd(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CONFIRM", accountId));
 return true;
}

3. Cancel 阶段：回滚释放

任何一个 Try 失败时，所有参与者执行 Cancel 释放资源。

// 转出服务 - Cancel：解冻金额
public boolean cancelDeduct(String txId, String accountId, BigDecimal amount) {
 if (transactionLogDao.exists(txId, "CANCEL")) {
 return true;
 }

 // 空回滚检查：Try 是否执行过
 if (!transactionLogDao.exists(txId, "TRY")) {
 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
 }

 // 解冻金额
 accountDao.unfreeze(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
}

// 转入服务 - Cancel：撤销预增加
public boolean cancelAdd(String txId, String accountId, BigDecimal amount) {
 if (transactionLogDao.exists(txId, "CANCEL")) {
 return true;
 }

 if (!transactionLogDao.exists(txId, "TRY")) {
 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
 }

 accountDao.cancelPreAdd(accountId, amount);

 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
}

注意每个 Cancel 方法都包含了幂等检查和空回滚检查——这是 TCC 实现中最关键的两个防护机制。

示例 / 踩坑

TCC 的核心难点不在"正常流程"，而在各种异常场景下的正确处理。以下是 6 个实现中必须解决的问题。

1. 幂等问题

问题：网络超时后协调器会重试 Confirm/Cancel，可能导致同一操作被执行多次。例如：已经扣款的账户被再次扣款。

解决：

唯一事务 ID：每次操作携带全局唯一的事务 ID
事务状态日志：执行前检查该事务 ID 是否已执行过当前阶段
数据库防重：通过唯一索引防止重复提交

每个 Confirm/Cancel 方法的开头都要做幂等检查：

if (transactionLogDao.exists(txId, "CONFIRM")) {
 return true;
}

2. 空回滚

问题：Try 请求因网络丢包未到达参与者，但协调器因超时触发 Cancel。此时参与者的 Cancel 没有对应的 Try 操作，执行回滚逻辑会导致数据错误。

解决：

Cancel 执行前检查 Try 是否已执行（查询事务日志）
如果 Try 未执行，直接记录日志并返回成功，不执行业务逻辑

// 空回滚检查
if (!transactionLogDao.exists(txId, "TRY")) {
 transactionLogDao.save(new TransactionLog(txId, "CANCEL", accountId));
 return true;
}

3. 悬挂事务

问题：Try 请求网络延迟，Cancel 已经先于 Try 到达并完成（触发了空回滚）。随后延迟的 Try 才到达并执行成功，资源被冻结但无人推进事务——形成"悬挂"。

解决：

定时轮询监控：后台任务周期扫描，识别长时间停留在 Try 阶段的事务并主动推进
MQ 异步补偿：通过消息队列异步触发后续 Confirm/Cancel 操作，解耦并保障执行可靠性

4. 补偿失败

问题：自动补偿机制可能失效（如数据库宕机、代码 Bug），需要人工介入保证数据一致性。

解决：

预留补偿接口：为 Try/Confirm/Cancel 分别提供可手动触发的补偿接口
事务状态查询接口：供运维人员查询事务当前状态，判断是否需要补偿
补偿任务调度：定时扫描未完成的事务分支，自动重试补偿

5. 超时处理

问题：受网络分区、服务宕机等影响，事务长期滞留于 Try 阶段，无法正常推进。

解决：设置事务超时时间，超时后自动标记为失败，触发 Cancel 回滚。

6. 协调者故障

问题：事务协调器是 TCC 的核心组件，一旦故障，所有进行中的事务都无法推进。

解决：

协调器集群部署，主节点故障后备用节点接管
提供管理后台，允许运维人员手动决定提交或回滚
持久化事务日志，恢复后可继续推进未完成的事务

常见 TCC 组件

组件	语言	特点
Apache Seata	Java	功能全面，支持 AT/TCC/Saga/XA 四种模式
DTM	Go	支持多语言 SDK，轻量级
rust-tcc	Rust	轻量级 TCC 实现

总结

本文介绍了 TCC 分布式事务模式的核心思想和实践方法，回顾要点：

核心思路：将事务拆分为 Try（资源预留）、Confirm（确认提交）、Cancel（取消回滚）三个阶段，通过业务补偿代替全局锁
与 2PC 的区别：TCC 在业务层面控制资源而非依赖数据库锁，性能更好但实现更复杂
关键实现挑战：幂等性、空回滚、悬挂事务、补偿失败、超时处理、协调者故障——每个都需要针对性的解决方案
适用场景：高并发短事务（电商下单、支付冻结），不适合长事务

TCC 不是银弹。如果你的系统事务简单、并发不高，可以考虑更轻量的方案（如本地消息表）。当系统确实面临"分布式事务 + 高并发"的瓶颈时，TCC 是一个值得投入的解决方案。

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

使用 CQRS 处理读写分离架构

Tue, 05 May 2026 10:00:00 +0800

背景 & 问题

在传统架构中，单个数据模型通常兼顾读和写的职责。但随着系统规模扩展，读和写操作在性能和扩展性上呈现出明显的不对称性：

数据表示不匹配：写入时需要的字段结构与读取时需要的展示形式往往不同。例如，创建订单需要商品 ID 列表，但查询订单详情时用户希望看到商品名称和价格
锁竞争严重：读操作和写操作共享同一份数据，复杂查询（join / 聚合 / 过滤）会长时间占用连接，阻塞写操作
性能无法兼顾：写入追求强一致性和事务安全，读取追求高并发和低延迟，两者的优化方向天然矛盾

这些问题的本质是：单一数据模型无法同时高效满足读与写需求。

本文将介绍 CQRS（Command Query Responsibility Segregation）模式，说明它如何通过读写职责分离来解决上述问题，并给出从简单到复杂的三种演进方案和完整的电商订单系统案例。

前置知识

阅读本文需要了解以下概念（不熟悉也没关系，文中会配合上下文说明）：

领域驱动设计（DDD）：一种以业务领域为核心组织代码的方法论，强调领域模型和业务规则的封装
领域模型（Domain Model）：面向业务的对象模型，包含实体、值对象和聚合根，封装业务规则
领域事件（Domain Event）：表示领域中发生的重要事情（如"订单已创建"），用于解耦不同模块之间的通信
聚合根（Aggregate Root）：一组相关对象的入口点，保证业务规则的一致性边界

方案或原理

CQRS 是什么

CQRS（Command Query Responsibility Segregation）是一种架构模式，核心思想是：将修改数据的操作（Command）和读取数据的操作（Query）彻底解耦，使用不同的模型、流程和存储来分别服务。

简单来说，就是让"写"和"读"各走各的路，各自优化。

优缺点

优势：

写操作聚焦强一致性和业务规则，读操作聚焦高并发和数据展示
读写可独立扩容，读模型可以使用缓存、搜索引擎等专门优化
降低单个模型的复杂度，职责更清晰

代价：

需要维护两套模型，开发成本和学习成本增加
读模型通常异步更新，存在数据延迟（最终一致性）
事件同步、消息队列等基础设施需要额外运维

适用场景

场景	说明
读多写少	用户频繁查询但写入较少，如电商订单查询
查询逻辑复杂	需要多表 join、聚合计算，如报表系统
读写性能要求差异大	写要求强一致，读要求低延迟高并发
业务逻辑复杂	领域规则复杂，不适合在查询中混入业务逻辑

如果你的系统读写都很简单，或者读远大于写但查询也不复杂，引入 CQRS 可能是过度设计。先评估实际需求，再决定是否采用。

五个设计原则

1. 读写职责分离

写操作只负责修改状态 + 执行业务规则
读操作只负责数据获取 + 展示优化
禁止在 Query 中修改状态

目的：避免读路径被业务逻辑污染，也保证查询可独立优化。

2. 一致性策略明确

写路径：强一致（通过事务和聚合保证）
读路径：最终一致（允许短暂延迟）

必须根据业务定义"可接受延迟范围"。例如：订单创建后 1 秒内可在查询中看到，这通常是可接受的。

目的：用"可控不一致"换取系统性能与扩展性。

3. 模型分离

写模型（Domain Model）：面向业务规则与一致性
读模型（Read Model）：面向查询与展示，可以反范式化（去范式化）以提高查询效率

读模型不需要与数据库表结构一致，它只为查询服务。

目的：避免一个模型同时承担"复杂业务 + 高性能查询"两种职责。

4. 存储分离

写存储：事务型数据库（如 MySQL），保证强一致性
读存储：缓存（如 Redis）/ 搜索引擎（如 ElasticSearch）/ 副本库

是否拆分存储取决于读压力与查询复杂度，并非所有场景都需要物理分离。

目的：让存储层也服务于不同的优化目标。

5. 异步解耦

通过领域事件（Domain Event）连接读写模型
流程：写操作 → 发布事件 → 异步更新读模型（Projection）

需要接受最终一致性（存在延迟）。

目的：降低系统耦合，支持独立扩展读模型。

CQRS 架构概览

┌─────────────┐ Command ┌──────────────────┐ Event ┌──────────────────┐
│ Client │ ──────────────→ │ Command Handler │ ─────────────→ │ Event Handler │
│ │ │ (写流程编排) │ │ (Projection) │
└─────────────┘ └────────┬─────────┘ └────────┬─────────┘
 │ │
 ▼ ▼
 ┌──────────────┐ ┌──────────────┐
 │ Write Store │ │ Read Store │
 │ (MySQL) │ │ (Redis/ES) │
 └──────────────┘ └──────────────┘
 ▲
┌─────────────┐ Query ┌──────────────────┐ │
│ Client │ ──────────────→ │ Query Handler │ ───────────────────┘
│ │ │ (读流程编排) │
└─────────────┘ └──────────────────┘

实现步骤

CQRS 并不是一步到位的，可以根据系统复杂度分三个层次渐进式引入。不必一上来就用最复杂的方案。

Level 1：逻辑分离（单库）

思路：仍然使用单个数据库，只在代码层面分离读和写。

做法：

代码中分为 Command 对象和 Query 对象
写操作使用 Domain Model，读操作使用独立的 Read Model（DTO / VO）
共享同一个数据库，读模型可以通过 SQL 视图或简单映射得到

适用场景：系统初期，读写压力都不大，但希望代码职责清晰。

优点：改动最小，风险最低局限：读和写仍然竞争同一份数据库资源

Level 2：物理分离（双库）

思路：将数据库分为写库和读库，读库独立优化。

做法：

写库（MySQL 主库）：处理所有写操作，保证强一致性
读库（MySQL 从库 / Redis / ElasticSearch）：处理所有读操作
写库数据通过主从复制或同步机制同步到读库

适用场景：读多写少，查询逻辑较复杂，读操作需要独立扩容。

优点：读写不竞争数据库资源，读库可针对性优化局限：需要维护数据同步机制，存在同步延迟

Level 3：事件驱动（Event Sourcing + CQRS）

思路：写路径产生的状态变化抽象为领域事件（Domain Event），由 Event Handler 异步构建和更新 Read Model。

做法：

写操作修改 Domain Model 后，发布领域事件
Event Handler 监听事件，将数据转换为读模型需要的格式，写入 Read Store
读操作直接查询 Read Store，完全不访问 Write Store

适用场景：业务逻辑复杂，需要完整的审计日志，或需要多个读模型服务不同查询场景。

优点：读写完全解耦，可灵活构建多个专用读模型局限：架构最复杂，需要事件基础设施（消息队列），调试难度最高

三种层次对比

维度	L1 逻辑分离	L2 物理分离	L3 事件驱动
存储数量	1 个	2 个	2+ 个
代码改动	小	中	大
读写解耦程度	低	中	高
一致性	强一致	最终一致（秒级延迟）	最终一致（毫秒~秒级延迟）
基础设施要求	无	主从复制 / 同步工具	消息队列 + Event Store
适用阶段	项目初期	系统成长期	大型复杂系统

示例 / 踩坑

下面通过一个电商订单系统，演示 CQRS Level 3（事件驱动）的完整实现。

业务场景

电商订单系统，核心需求：

写：创建订单、支付、取消（要求强一致性和复杂业务规则校验）
读：订单列表、订单详情（用户频繁查询，需要低延迟）
特点：读多写少，查询涉及多表 join 和聚合计算

CQRS 改造思路

写（Command）：CreateOrder → OrderAggregate → MySQL
读（Query）：GetOrderDetail → Redis / Read DB（预聚合数据）
连接：OrderCreatedEvent → Event Handler 异步更新 Read Model

代码实现

Command：写路径的输入模型

public class CreateOrderCommand {
 private Long userId;
 private List<Long> productIds;

 // 构造方法 / getter
}

Domain Model：核心领域对象

public class Order {
 private Long id;
 private Long userId;
 private List<Long> productIds;
 private String status;

 public static Order create(Long userId, List<Long> productIds) {
 if (productIds == null || productIds.isEmpty()) {
 throw new IllegalArgumentException("商品不能为空");
 }

 Order order = new Order();
 order.userId = userId;
 order.productIds = productIds;
 order.status = "CREATED";
 return order;
 }
}

Command Handler：写流程编排

public class CreateOrderHandler {

 private OrderRepository repository;
 private EventPublisher eventPublisher;

 public Long handle(CreateOrderCommand cmd) {
 // 1. 构建领域对象（业务规则校验在 create 方法中）
 Order order = Order.create(cmd.getUserId(), cmd.getProductIds());

 // 2. 持久化（事务保证强一致性）
 repository.save(order);

 // 3. 发布事件（异步更新读模型）
 eventPublisher.publish(new OrderCreatedEvent(order.getId()));

 return order.getId();
 }
}

Read Model：读模型（专为查询设计）

public class OrderView {
 private Long orderId;
 private String status;
 private List<String> productNames;
 private BigDecimal totalPrice;

 // getter
}

注意读模型和写模型的区别：写模型存储 productIds（商品 ID），读模型存储 productNames（商品名称）和 totalPrice（总价）——这是面向查询优化的结果。

Query Handler：读流程编排

public class GetOrderDetailHandler {

 private OrderReadRepository readRepository;

 public OrderView handle(Long orderId) {
 // 直接查缓存或 Read DB，无业务逻辑
 return readRepository.findById(orderId);
 }
}

Event Handler：投影器（Projection）

Projection 监听领域事件，将 Command Side 的数据转换为 Read Model 并持久化：

public class OrderProjectionHandler {

 private OrderReadRepository readRepository;
 private ProductRepository productRepository;

 public void on(OrderCreatedEvent event) {

 List<String> productNames =
 productRepository.findNames(event.getProductIds());

 OrderView view = new OrderView();
 view.setOrderId(event.getOrderId());
 view.setStatus(event.getStatus());
 view.setProductNames(productNames);

 readRepository.save(view);
 }
}

常见问题与踩坑

问题 1：读模型更新延迟导致用户看不到最新数据

这是 CQRS 最常见的问题。用户刚创建订单，立刻查询却找不到。

解决方案：

前端在写操作成功后，短暂轮询或使用 WebSocket 等待读模型更新
在读模型未就绪时，回退到写库查询（Fallback 策略）
在 UI 上提示用户"数据正在同步中"

问题 2：事件处理失败导致读写数据不一致

Event Handler 处理事件时可能失败（网络抖动、数据库异常等），导致读模型缺失数据。

解决方案：

事件消费必须实现幂等性，重复消费不会产生副作用
使用消息队列的重试机制（如 RabbitMQ 的 Dead Letter Queue）
定期做数据对账，比对写库和读库的数据差异并修复

问题 3：读模型结构变更困难

业务变化导致读模型需要新增字段，但历史事件中不包含这些字段。

解决方案：

新增字段设置默认值，避免历史数据缺失
设计事件时采用"事件增量"模式，通过版本号管理字段变更
需要时可以发起全量重建（Rebuild）读模型

问题 4：过度设计

并非所有系统都需要 CQRS。如果读写逻辑简单、并发量不大，引入 CQRS 反而增加不必要的复杂度。

判断标准：当你的系统确实面临"读写性能无法兼顾"的瓶颈时，再考虑引入。

总结

本文介绍了 CQRS 模式的核心思想和实践方法，回顾要点：

核心思路：将 Command（写）和 Query（读）解耦，各自优化
五个设计原则：读写职责分离、一致性策略明确、模型分离、存储分离、异步解耦
三种演进层次：逻辑分离 → 物理分离 → 事件驱动，根据系统复杂度渐进式引入
关键取舍：用最终一致性换取读写性能和扩展性

CQRS 不是银弹，它解决的是"读写性能无法兼顾"这一类特定问题。如果你的系统面临这个瓶颈，可以从 Level 1（逻辑分离）开始，渐进式演进到更复杂的方案。

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

接口 + 抽象模板组合模式：让子类只写核心逻辑

Sat, 11 Apr 2026 10:00:00 +0800

🤔 你是否在子类里写了大量重复的"流程代码"？

假设你有三个业务 Service：订单服务、支付服务、库存服务。它们各自的 apply() 方法看起来是这样的：

public class OrderService {
 public Result apply(Request request) {
 validate(request); // 参数校验
 initContext(); // 初始化上下文
 try {
 Result result = doOrder(request); // ← 唯一不同的部分
 postProcess(result); // 后置处理
 return result;
 } catch (Exception e) {
 handleError(e); // 异常处理
 throw e;
 } finally {
 cleanUp(); // 资源清理
 }
 }
}

把上面代码里的 doOrder 换成 doPayment、doInventory，你会发现流程完全一样，只有核心业务逻辑那一行不同。

⚠️️这就是问题所在：相同的流程控制代码在每个子类中重复出现。如果某天需要在所有服务中增加一个"日志记录"步骤，你得挨个修改每一个 Service。

本文将介绍一种接口 + 抽象模板的组合模式，让通用流程只写一次，子类只需关注自己的核心逻辑。

读完本文，你将了解：

“接口定义契约 + 抽象模板控制流程"的组合设计思想
Spring 的 JdbcTemplate 是如何运用这一思想的

🏗️ 核心思想：三层分工

这个模式的核心可以用一句话概括：

接口定义契约，抽象模板控制流程，子类专注实现具体逻辑。

三个角色各有明确的职责边界：

角色	职责	关键手段
接口	定义"做什么”——对外暴露的业务契约	声明 `apply()` 方法
抽象模板类	定义"怎么做"——控制不可变的通用流程	实现 `apply()` 为 `final`，内部调用 `doApply()`
具体子类	实现"做哪样"——只填入核心业务逻辑	重写 `protected doApply()`

为什么不能只用接口或只用抽象类？

只用接口：无法复用流程代码，每个实现类都要重复写一遍 validate → try → do → catch → finally。
只用抽象类：可以实现模板方法，但一个类只能单继承，限制了灵活性。而且调用方无法面向接口编程。
接口 + 抽象类组合：接口提供了多态和面向接口编程的能力，抽象类提供了流程复用的能力。两者互补。

🛠️ 一步步实现组合模式

第一步：接口定义业务契约

接口只关心"能做什么"，不关心"怎么做"：

public interface BusinessService {
 Result apply(Request request);
}

这个接口是对外的契约。调用方只需要知道 BusinessService 有一个 apply() 方法，不需要知道背后是哪个具体实现。

第二步：抽象模板封装通用流程

这是整个模式的核心。抽象类实现接口，把不可变的流程写死在 apply() 中，把可变的部分留给子类：

public abstract class AbstractBusinessTemplate implements BusinessService {

 // 声明为 final，子类不能覆盖流程
 @Override
 public final Result apply(Request request) {
 validateRequest(request);
 initializeContext();

 try {
 // 核心：调用子类实现的具体逻辑
 Result result = doApply(request);

 postProcess(result);
 return result;
 } catch (Exception e) {
 handleException(e);
 throw e;
 } finally {
 cleanUp();
 }
 }

 // 子类必须实现的抽象方法
 protected abstract Result doApply(Request request);

 // 以下通用方法提供默认实现，子类可选择性覆盖
 protected void validateRequest(Request request) {
 if (request == null) {
 throw new IllegalArgumentException("Request cannot be null");
 }
 }

 protected void initializeContext() { /* 默认实现 */ }

 protected void postProcess(Result result) { /* 默认实现 */ }

 protected void handleException(Exception e) {
 // 默认异常处理，比如记录日志
 }

 protected void cleanUp() { /* 默认清理 */ }
}

注意几个关键设计决策：

apply() 声明为 final：防止子类覆盖流程。流程是"不变的骨架"，不应该被篡改。
doApply() 声明为 protected abstract：子类只能实现这个方法。protected 确保只有子类能看到它，外部调用方不会直接调用。
通用方法提供默认实现：validateRequest、postProcess 等方法提供了钩子（Hook），子类可以按需覆盖，但不是必须的。

第三步：子类只写核心逻辑

public class OrderService extends AbstractBusinessTemplate {

 @Override
 protected Result doApply(Request request) {
 // 只需要关注核心业务逻辑
 Order order = createOrder(request);
 orderRepository.save(order);
 return Result.success(order);
 }
}

public class PaymentService extends AbstractBusinessTemplate {

 @Override
 protected Result doApply(Request request) {
 // 每个子类只写自己的核心逻辑
 Payment payment = processPayment(request);
 paymentGateway.charge(payment);
 return Result.success(payment);
 }
}

对比重构前后：原来每个 Service 要写 15-20 行流程代码，现在只需要 3-5 行核心逻辑。

调用方式

调用方完全面向接口编程，不知道也不需要知道模板的存在：

BusinessService service = new OrderService();
Result result = service.apply(request);

📦 实战：数据导出服务

上一节讲了模式的骨架，现在来看一个后端开发中常见的真实场景——数据导出。

假设系统需要支持多种格式的数据导出：CSV、Excel、PDF。不管导出哪种格式，流程都是一样的：

查询数据 → 生成文件 → 上传到存储 → 发送通知

唯一不同的是"生成文件"这一步。这正好是"接口 + 抽象模板"模式的用武之地。

第一步：定义领域模型

// 导出请求
public class ExportRequest {
 private String dataType; // 导出数据类型，如 "order"、"user"
 private LocalDate startDate;
 private LocalDate endDate;
 private String operatorId; // 操作人
 // getter / setter 省略
}

// 导出结果
public class ExportResult {
 private String fileUrl; // 文件下载地址
 private String fileName;
 private long file_size; // 文件大小（字节）
 // getter / setter 省略
}

第二步：接口定义导出契约

public interface DataExporter {
 ExportResult export(ExportRequest request);
}

第三步：抽象模板封装导出流程

public abstract class AbstractDataExporter implements DataExporter {

 @Override
 public final ExportResult export(ExportRequest request) {
 // 1. 参数校验
 validateRequest(request);

 // 2. 查询数据
 List<Map<String, Object>> data = queryData(request);

 // 3. 生成文件（由子类实现）
 byte[] fileContent = generateFile(data);
 String fileName = buildFileName(request);

 // 4. 上传文件
 String fileUrl = uploadFile(fileName, fileContent);

 // 5. 发送通知
 notifyOperator(request.getOperatorId(), fileUrl);

 // 6. 构造结果
 ExportResult result = new ExportResult();
 result.setFileUrl(fileUrl);
 result.setFileName(fileName);
 result.setFileSize(fileContent.length);
 return result;
 }

 // 子类必须实现：按特定格式生成文件
 protected abstract byte[] generateFile(List<Map<String, Object>> data);

 // 子类必须实现：声明文件格式后缀
 protected abstract String getFileExtension();

 // 通用校验逻辑
 protected void validateRequest(ExportRequest request) {
 if (request.getStartDate() == null || request.getEndDate() == null) {
 throw new IllegalArgumentException("导出时间范围不能为空");
 }
 if (request.getStartDate().isAfter(request.getEndDate())) {
 throw new IllegalArgumentException("开始时间不能晚于结束时间");
 }
 }

 // 通用数据查询（实际项目中注入 Repository）
 protected List<Map<String, Object>> queryData(ExportRequest request) {
 // 根据 request.getDataType() 和时间范围查询数据
 return dataRepository.queryByDateRange(
 request.getDataType(),
 request.getStartDate(),
 request.getEndDate()
 );
 }

 // 通用文件上传
 private String uploadFile(String fileName, byte[] content) {
 return storageService.upload(fileName, content);
 }

 // 通用通知
 private void notifyOperator(String operatorId, String fileUrl) {
 notificationService.send(operatorId, "导出完成：" + fileUrl);
 }

 // 构建文件名
 private String buildFileName(ExportRequest request) {
 return request.getDataType() + "_"
 + request.getStartDate() + "_"
 + request.getEndDate()
 + "." + getFileExtension();
 }
}

第四步：具体子类只写文件生成逻辑

// CSV 导出
public class CsvDataExporter extends AbstractDataExporter {

 @Override
 protected byte[] generateFile(List<Map<String, Object>> data) {
 StringBuilder sb = new StringBuilder();

 // 写表头
 if (!data.isEmpty()) {
 String header = String.join(",", data.get(0).keySet());
 sb.append(header).append("\n");
 }

 // 写数据行
 for (Map<String, Object> row : data) {
 String line = row.values().stream()
 .map(v -> String.valueOf(v))
 .collect(Collectors.joining(","));
 sb.append(line).append("\n");
 }

 return sb.toString().getBytes(StandardCharsets.UTF_8);
 }

 @Override
 protected String getFileExtension() {
 return "csv";
 }
}

// Excel 导出（假设使用 Apache POI）
public class ExcelDataExporter extends AbstractDataExporter {

 @Override
 protected byte[] generateFile(List<Map<String, Object>> data) {
 try (Workbook workbook = new XSSFWorkbook()) {
 Sheet sheet = workbook.createSheet("数据导出");

 // 写表头
 Row headerRow = sheet.createRow(0);
 if (!data.isEmpty()) {
 int col = 0;
 for (String key : data.get(0).keySet()) {
 headerRow.createCell(col++).setCellValue(key);
 }
 }

 // 写数据行
 int rowIdx = 1;
 for (Map<String, Object> rowData : data) {
 Row row = sheet.createRow(rowIdx++);
 int col = 0;
 for (Object value : rowData.values()) {
 row.createCell(col++).setCellValue(String.valueOf(value));
 }
 }

 ByteArrayOutputStream out = new ByteArrayOutputStream();
 workbook.write(out);
 return out.toByteArray();
 } catch (IOException e) {
 throw new RuntimeException("Excel 生成失败", e);
 }
 }

 @Override
 protected String getFileExtension() {
 return "xlsx";
 }
}

调用方式与扩展

// 根据用户选择的格式，创建对应的导出器
DataExporter exporter = exporterFactory.getExporter("csv");
ExportResult result = exporter.export(request);
// result.getFileUrl() → "https://storage.example.com/order_2026-01-01_2026-03-31.csv"

如果将来需要支持 PDF 导出，只需新增一个 PdfDataExporter，实现 generateFile() 和 getFileExtension()，其他流程代码一行都不用改。

这正体现了开闭原则：对扩展开放（新增导出格式），对修改关闭（不动已有的导出器和模板）。

从 JdbcTemplate 看真实框架的应用

Spring 的 JdbcTemplate 并没有严格使用继承式模板方法，而是用回调接口实现了同样的思想。理解它有助于你看到这个模式的另一种变体。

JdbcTemplate 的"接口 + 模板"结构

// 1. 回调接口 —— 相当于 doApply()
interface StatementCallback<T> {
 T doInStatement(Statement stmt) throws SQLException;
}

StatementCallback 就是那个"可变的部分"，用户通过实现它来提供具体的 SQL 操作逻辑。

// 2. 模板类 —— 相当于 apply() 的流程控制
public class JdbcTemplate {

 public <T> T execute(StatementCallback<T> action) throws DataAccessException {
 Connection con = DataSourceUtils.getConnection(obtainDataSource());
 Statement stmt = null;
 try {
 stmt = con.createStatement();
 // 调用用户提供的具体逻辑
 T result = action.doInStatement(stmt);
 return result;
 } catch (SQLException ex) {
 // 统一异常转换
 throw translateException("StatementCallback", getSql(action), ex);
 } finally {
 // 统一资源清理
 JdbcUtils.closeStatement(stmt);
 DataSourceUtils.releaseConnection(con, getDataSource());
 }
 }
}

注意 execute() 方法里的流程：获取连接 → 创建 Statement → 执行回调 → 异常处理 → 资源清理。这和我们的 apply() 流程如出一辙。

// 3. 用户代码 —— 只关注 SQL 操作本身
jdbcTemplate.execute(new StatementCallback<Integer>() {
 @Override
 public Integer doInStatement(Statement stmt) throws SQLException {
 stmt.execute("SELECT COUNT(*) FROM users");
 ResultSet rs = stmt.getResultSet();
 rs.next();
 return rs.getInt(1);
 }
});

两种实现的对比

维度	继承式（AbstractBusinessTemplate）	回调式（JdbcTemplate）
扩展方式	继承抽象类	实现回调接口
灵活性	单继承限制	可组合多个回调
适用场景	业务逻辑有明确的父子关系	一次性操作、策略型逻辑
核心思想	一样：固定流程 + 可变逻辑	一样：固定流程 + 可变逻辑

⚡ 容易踩的坑

忘记把 apply() 声明为 final：子类可能不小心覆盖了流程，导致通用逻辑被跳过。如果你使用继承式实现，务必加 final。
在 doApply() 中写流程控制代码：doApply() 应该只包含纯业务逻辑。如果你发现自己在这里做参数校验或资源清理，说明抽象模板的流程设计有问题。
通用方法过度设计：不需要一开始就抽出 10 个 Hook 方法。先写 2-3 个最常用的，等有实际需求时再扩展。

✅ 总结

“接口 + 抽象模板"组合模式的核心思想是分离不变和可变：

不变的部分（流程控制）放在抽象类的 final 方法里
可变的部分（业务逻辑）交给子类的 doApply() 实现
契约（对外暴露什么）由接口定义

这个模式在框架设计中非常常见。无论是 Spring 的 JdbcTemplate、TransactionTemplate，还是业务系统中的订单处理、审批流程，只要存在"相同流程、不同业务"的场景，都可以用这个思想来消除重复代码。

下次你发现自己在多个 Service 中写着相似的 try-catch-finally 结构时，不妨试试这个模式——通用流程放在抽象模板类，让子类只写核心逻辑。

纯函数带来的架构思考：Functional Core 与 Imperative Shell

Wed, 08 Apr 2026 10:00:00 +0800

一、🎯 背景 & 问题：当业务逻辑遇上副作用

作者作为一个 Java 后端开发，经常需要写这样的函数，不知你也是否写过这样的函数：

一个 createOrder 方法，既要计算订单金额、应用折扣规则，还要保存到数据库、打印日志。

这看起来是个很正常的业务函数，但当你想给"折扣计算"写单元测试时，却发现必须连接数据库才能运行测试。

这种"业务逻辑 + 副作用"混在一起的模式，带来了三个核心问题：

问题	表现
❌难以测试	必须依赖数据库/网络等外部系统
❌难以预测	函数行为依赖外部状态，相同输入不一定得到相同输出
❌难以复用	逻辑绑死在 I/O 上，换个场景就得重写

⚠️ 本质原因：纯计算和副作用混在一起，导致核心业务逻辑被 I/O 操作"绑架"。

💡 读完本文，你将学到：

纯函数的核心思想及其对架构设计的启发
Functional Core / Imperative Shell 模式：如何将纯计算与副作用分离
通过 Java 和 Rust 两个案例，掌握具体的重构方法

二、🧩 方案或原理：纯函数与架构分离

什么是纯函数（Pure Function）

纯函数是函数式编程的核心概念，指相同输入下始终返回相同输出，且不产生任何副作用的函数。

两个关键特征：

结果可预测（Determinism）：输入唯一决定输出，不依赖外部状态
无副作用（No Side Effects）：不修改外部变量、不操作 I/O、不影响外部世界

// 纯函数：相同输入 → 相同输出，无副作用
fn add(a: i32, b: i32) -> i32 {
 a + b
}

// 纯函数：只依赖输入，返回新值，不修改原数据
fn to_uppercase(s: &str) -> String {
 s.to_uppercase()
}

纯函数天然适合以下场景：基础计算、数据转换、集合处理、参数校验。它们的共同点是——只关心输入到输出的映射，不关心数据从哪来、到哪去。

什么是副作用（Side Effects）

副作用指函数在执行过程中，除返回值外带来的其他影响：

副作用类型	带来的影响
修改外部变量 / 全局状态	破坏可预测性，增加隐式依赖
I/O 操作（文件、网络、数据库）	不可控（延迟/失败），结果不可复现
控制台输出（print）	引入环境依赖，测试需要 mock
依赖外部状态（环境变量、配置）	行为不再由输入决定
使用时间 / 随机数	相同输入得到不同输出

副作用本身不是"坏东西"——没有副作用的程序无法与真实世界交互。问题在于，副作用和业务逻辑混在一起时，代码变得难以理解和测试。

核心思想：纯计算与副作用分离

这就引出了本文的核心架构模式：Functional Core / Imperative Shell。

┌───────────────────────────────────────────┐
│ Imperative Shell │
│ （命令式外壳 - 负责副作用） │
│ │
│ · 读取数据库 / 文件 │
│ · 调用 Functional Core 完成业务计算 │
│ · 保存结果到数据库 │
│ · 记录日志 │
│ │
│ ┌─────────────────────────┐ │
│ │ Functional Core │ │
│ │ （纯逻辑内核 - 只做计算）│ │
│ │ │ │
│ │ · 业务规则计算 │ │
│ │ · 权限判断 │ │
│ │ · 数据转换 │ │
│ │ · 校验逻辑 │ │
│ │ │ │
│ │ ✅ 无副作用 │ │
│ │ ✅ 可预测 │ │
│ │ ✅ 容易测试（无需 mock） │ │
│ └─────────────────────────┘ │
└───────────────────────────────────────────┘

Functional Core（纯逻辑内核）：

由纯函数组成，只负责业务计算
不访问数据库、不打印日志、不修改外部状态
相同输入 → 相同输出，可独立测试

Imperative Shell（命令式外壳）：

负责与外界交互（I/O、事务、日志）
调用 Functional Core 完成业务计算
包含副作用（不可避免），但不承担复杂业务逻辑

💡 核心思想：不是消除副作用，而是隔离副作用，保护核心逻辑的可测试性。

三、🛠️ 使用步骤：重构"脏函数"

重构模板

将一个"业务逻辑 + 副作用"混合的函数，拆分为 FC/IS 结构，只需三步：

提取纯业务逻辑：将计算、校验等逻辑提取为独立函数（只依赖输入参数）
提取副作用逻辑：将数据库、I/O、日志等操作留在 Shell 中
Shell 调用 Core：在副作用函数中调用纯业务函数

案例1：Java - 创建订单

场景

输入：商品价格、数量、用户等级
输出：订单金额 + 折扣结果
同时需要：保存数据库 + 打日志

❌ 传统写法：逻辑 + 副作用混在一起

class OrderService {

 public double createOrder(double price, int quantity, int userLevel) {
 double total = price * quantity;

 // 折扣逻辑（业务计算）
 if (userLevel == 2) total *= 0.9;
 if (userLevel == 3) total *= 0.8;

 // 数据库写入（副作用）
 Database.save(total);

 // 日志（副作用）
 System.out.println("Order created: " + total);

 return total;
 }
}

问题：想测试"折扣计算"逻辑，必须先连接数据库。

✅ 重构后：FC/IS 分离

Step 1：提取 Functional Core（纯逻辑内核）

/**
 * 纯逻辑内核 - 只负责业务规则计算
 *
 * 特点：
 * - 只依赖输入参数
 * - 不访问数据库 / 不打印日志 / 不修改外部状态
 * - 相同输入 → 相同输出
 */
class OrderCore {

 /**
 * 计算订单最终价格（纯函数）
 */
 public static double calculateTotal(double price, int quantity, int userLevel) {
 double total = price * quantity;

 if (userLevel == 2) return total * 0.9;
 if (userLevel == 3) return total * 0.8;

 return total;
 }
}

Step 2：构建 Imperative Shell（命令式外壳）

/**
 * 命令式外壳 - 负责副作用和流程编排
 *
 * 职责：
 * - 调用纯函数完成业务计算
 * - 处理所有副作用（数据库 / 日志 / 外部交互）
 *
 * 不承担复杂业务逻辑，只做"编排"
 */
class OrderService {

 public double createOrder(double price, int quantity, int userLevel) {
 // 调用纯逻辑（核心计算）
 double total = OrderCore.calculateTotal(price, quantity, userLevel);

 // 副作用：持久化数据
 Database.save(total);

 // 副作用：记录日志
 System.out.println("Order created: " + total);

 return total;
 }
}

Step 3：测试纯逻辑，无需 mock

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class OrderCoreTest {

 @Test
 void 普通用户无折扣() {
 assertEquals(100.0, OrderCore.calculateTotal(50.0, 2, 1));
 }

 @Test
 void 二级会员九折() {
 assertEquals(90.0, OrderCore.calculateTotal(50.0, 2, 2));
 }

 @Test
 void 三级会员八折() {
 assertEquals(80.0, OrderCore.calculateTotal(50.0, 2, 3));
 }
}

测试无需数据库连接、无需 mock 框架，直接验证业务规则。

案例2：Rust - 文件单词统计

场景

实现一个 CLI 工具，读取文件内容并统计单词数量。

❌ 传统写法：逻辑 + I/O 混在一起

use std::fs;

fn count_words_in_file(path: &str) -> usize {
 // 副作用：读取文件
 let content = fs::read_to_string(path).unwrap();

 // 业务逻辑：统计单词
 let count = content.split_whitespace().count();

 // 副作用：打印结果
 println!("Word count: {}", count);

 count
}

问题：

想测试"单词统计"逻辑，必须依赖真实文件
逻辑绑死在文件 I/O 上，换数据来源就得重写

✅ 重构后：FC/IS 分离

Step 1：提取 Functional Core（纯逻辑内核）

/// 统计字符串中的单词数量（纯函数）
///
/// - 只依赖输入参数 content
/// - 不进行 I/O 操作
/// - 相同输入 → 相同输出
fn count_words(content: &str) -> usize {
 content.split_whitespace().count()
}

Step 2：构建 Imperative Shell（命令式外壳）

use std::fs;

fn run(path: &str) {
 // 副作用：读取文件
 let content = fs::read_to_string(path)
 .expect("Failed to read file");

 // 调用纯函数（核心逻辑）
 let count = count_words(&content);

 // 副作用：输出结果
 println!("Word count: {}", count);
}

Step 3：测试纯逻辑

#[cfg(test)]
mod tests {
 use super::*;

 #[test]
 fn 统计普通文本() {
 assert_eq!(count_words("hello world rust"), 3);
 }

 #[test]
 fn 空字符串返回零() {
 assert_eq!(count_words(""), 0);
 }

 #[test]
 fn 处理多余空白() {
 assert_eq!(count_words(" hello world "), 2);
 }
}

测试无需文件系统，直接验证计算逻辑。

四、💡 示例 / 踩坑

识别非纯函数

在实践中，学会识别哪些操作是不纯的，是正确应用 FC/IS 模式的前提。以下都是非纯函数的常见形式：

// 修改外部状态 - 依赖并修改全局变量
let mut total = 0;
fn add_to_total(x: i32) { total += x; }

// 依赖外部状态 - 行为由环境变量决定
fn get_env_port() -> String {
 std::env::var("PORT").unwrap_or("3000".to_string())
}

// 依赖时间 - 每次调用结果不同
fn get_timestamp() -> u64 {
 SystemTime::now()
 .duration_since(UNIX_EPOCH)
 .unwrap()
 .as_secs()
}

// 控制台输出 - 产生外部可观察行为
fn log_and_add(a: i32, b: i32) -> i32 {
 println!("calculating...");
 a + b
}

它们的共同特征：函数的行为不完全由输入决定。

常见陷阱

⚠️ 陷阱	表现	✅ 正确做法
过度追求纯函数	试图让所有函数都变纯，导致代码复杂度暴增	只隔离核心业务逻辑，I/O 操作交给 Shell
边界划分不清	不知道哪些逻辑属于 Core，哪些属于 Shell	判断标准：是否依赖外部状态？是否可预测？
Shell 承担业务逻辑	Shell 中又混入了计算逻辑	Shell 只做编排和 I/O，计算全交给 Core
忽略副作用传染性	在 Core 中调用了不纯函数，导致 Core 也不纯	Core 中的所有调用链都必须是纯的

什么时候适合使用 FC/IS 模式？

适合使用的场景：
├── 业务逻辑较复杂，需要频繁测试
├── 函数中混合了计算和 I/O 操作
└── 多个场景复用同一套计算逻辑

不一定需要的场景：
├── 简单的 CRUD 操作（逻辑简单，收益不大）
├── 纯 I/O 转发（没有业务计算）
└── 一次性脚本（不需要长期维护）

五、📋 总结

核心要点回顾

纯函数的本质：相同输入 → 相同输出，无副作用。它是可预测、可测试、可组合的基石
FC/IS 模式的核心思想：不是消除副作用，而是隔离副作用，保护核心逻辑
重构方法：提取纯逻辑为 Functional Core，将副作用留在 Imperative Shell，Shell 调用 Core

与方法拆分的关系

本文的 FC/IS 模式和"方法拆分"重构（重构实战：打破依赖关系的两种核心方法）是一脉相承的：

方法拆分：在同一类内分离纯逻辑与副作用（微观层面）
FC/IS 模式：将纯逻辑和副作用分到不同的模块/类（架构层面）

延伸方向

领域驱动设计（DDD）：Functional Core 可以对应领域层（Domain Layer），Imperative Shell 对应基础设施层（Infrastructure Layer）
六边形架构（Hexagonal Architecture）：核心业务逻辑不依赖外部，通过端口与适配器与外界交互
Effect Systems：在类型系统层面追踪副作用（如 Haskell 的 IO Monad）

💡 实践建议：下次写一个包含计算和 I/O 的函数时，先问自己——“能不能把计算逻辑提取出来，让它不依赖任何外部系统？”

重构实战：打破依赖关系的两种核心方法

Tue, 24 Mar 2026 10:00:00 +0800

一、🎯 背景 & 问题：你的代码为什么难以测试？

在日常开发中，我们经常会遇到这样的困境：

你想给一个 checkout 方法写单元测试，但发现它内部调用了数据库；你想测试 registerUser 方法，但发现它会真的发送邮件…

这些问题的共同特征是：测试依赖外部系统（数据库、网络、第三方服务），导致：

问题	表现
测试运行慢	每次都要连接真实数据库/网络
测试结果不稳定	外部系统的状态不可控
无法独立测试核心逻辑	被副作用绑架

⚠️ 本质原因：代码"设计耦合严重"——业务逻辑与副作用混在一起，形成了难以分割的依赖关系。

本文目标：通过两种实用的重构方法，让你的代码从"依赖具体实现"转变为"依赖抽象 + 可替换实现"，从而获得可独立测试的纯业务逻辑。

💡 读完本文，你将学到：两种常用的变更代码思路（如何解耦）

二、🧩 方案概述：解耦的核心思想

打破依赖关系的本质是 解耦（Decoupling）。

简单来说，就是让代码从：

调用方 --> 直接依赖具体实现

变成：

调用方 --> 依赖抽象接口 --> 可替换的具体实现（真实/测试）

本文介绍两种核心方法：

方法	核心思想	适用场景
🔧 方法拆分	将纯业务逻辑与副作用操作分离	单方法内部混杂多种职责
🔄 依赖倒置	通过接口抽象依赖，引入中介层	类与类之间的强耦合

三、🛠️ 实现步骤

🔧 方法1：方法拆分（逻辑隔离）

核心概念：

📌 纯业务逻辑：可直接测试的计算、校验等（无副作用）
🌊 副作用操作：依赖外部系统的操作（数据库、网络、I/O）

重构目标：将大方法中的"纯业务逻辑"和"副作用操作"拆分，让核心逻辑可单独测试。

原始代码：测试被数据库绑架

public class OrderService {

 public int checkout(Order order) {
 // ① 业务逻辑：计算价格
 int total = 0;
 for (Item item : order.getItems()) {
 total += item.getPrice();
 }

 // ② 副作用：访问数据库（不可控）
 Database db = new Database();
 db.save(order);

 return total;
 }
}

问题：想测试"价格计算"，必须先连接数据库。

重构后：职责分离

public class OrderService {

 public int checkout(Order order) {
 // 1️⃣ 只负责流程编排（orchestration）
 int total = calculateTotal(order);
 save(order);
 return total;
 }

 /**
 * 纯函数：无副作用，可单独测试
 * 通过提炼方法将纯逻辑分离出来
 */
 int calculateTotal(Order order) {
 int total = 0;
 for (Item item : order.getItems()) {
 total += item.getPrice();
 }
 return total;
 }

 /**
 * 副作用方法：隔离数据库依赖
 * 将副作用集中到单独方法中
 */
 private void save(Order order) {
 new Database().save(order);
 }
}

单元测试：无需数据库

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class OrderServiceTest {

 @Test
 void testCalculateTotal() {
 // 准备测试数据
 Order order = new Order(List.of(
 new Item(10),
 new Item(20)
 ));

 // 执行测试 - 不依赖数据库
 int result = new OrderService().calculateTotal(order);

 // 验证结果
 assertEquals(30, result);
 }
}

关键收益：calculateTotal 现在是一个纯函数（Pure Function）——给定相同输入永远返回相同输出，且没有副作用，非常容易测试。

⭐ 测试优势：无需任何 Mock 框架，直接调用即可验证

🔄 方法2：引入中介（依赖倒置）

当依赖关系跨越类边界时，方法拆分就不够用了。这时需要引入一个**中介（接口）**来替代具体实现，让依赖"可替换"。

这就是 依赖倒置原则（Dependency Inversion Principle） 的实践：

📌 高层模块不应依赖低层模块，两者都应依赖抽象
📌 抽象不应依赖细节，细节应依赖抽象

原始代码：硬编码依赖

public class UserService {
 // ❌ 硬编码依赖具体实现（强耦合）
 private RealEmailSender emailSender = new RealEmailSender();

 public void registerUser(String email) {
 // ... 业务逻辑：验证邮箱格式、检查重复等 ...

 // ❌ 副作用：真实发送邮件
 emailSender.sendWelcomeEmail(email);
 }
}

测试困境：测试 registerUser 时会真的发送邮件，既慢又有副作用。

重构步骤

Step 1：定义抽象（接口）

/**
 * 抽象：定义"发送邮件"的能力，而不是具体实现
 */
interface EmailProvider {
 void send(String to, String subject, String content);
}

Step 2：提供真实实现（生产环境使用）

/**
 * 真实实现：生产环境发送真实邮件
 */
class RealEmailSender implements EmailProvider {

 @Override
 public void send(String to, String subject, String content) {
 // 实际发送邮件（网络请求）
 // 调用邮件服务商 API 等
 }
}

Step 3：业务类依赖抽象

public class UserService {

 // ✅ 依赖抽象（接口）而不是具体类
 private final EmailProvider emailProvider;

 /**
 * 通过构造函数注入依赖（Dependency Injection）
 * 调用方决定使用哪个实现
 */
 public UserService(EmailProvider emailProvider) {
 this.emailProvider = emailProvider;
 }

 public void registerUser(String email) {
 // ... 业务逻辑 ...

 // ✅ 调用抽象，不关心具体如何发送
 emailProvider.send(email, "欢迎注册", "欢迎加入我们！");
 }
}

Step 4：创建测试用的 Fake / Stub 实现

/**
 * 测试用实现：只记录调用，不执行真实操作
 */
class FakeEmailSender implements EmailProvider {

 // 记录发送的邮件，用于验证
 private final List<EmailRecord> sentEmails = new ArrayList<>();
 private boolean isCalled = false;

 @Override
 public void send(String to, String subject, String content) {
 // ✅ 不做真实操作，只记录
 sentEmails.add(new EmailRecord(to, subject, content));
 isCalled = true;
 }

 public boolean wasEmailSentTo(String email) {
 return sentEmails.stream()
 .anyMatch(e -> e.to().equals(email));
 }

 // 记录类
 record EmailRecord(String to, String subject, String content) {}
}

单元测试：完全隔离外部依赖

import org.junit.jupiter.api.Test;
import static org.junit.jupiter.api.Assertions.*;

class UserServiceTest {

 @Test
 void registerUser_shouldSendWelcomeEmail() {
 // 1️⃣ 创建测试替身（Test Double）
 FakeEmailSender fakeEmailSender = new FakeEmailSender();

 // 2️⃣ 注入测试替身
 UserService userService = new UserService(fakeEmailSender);

 // 3️⃣ 执行被测方法
 userService.registerUser("user@example.com");

 // 4️⃣ 验证行为（而不是结果）
 assertTrue(fakeEmailSender.wasEmailSentTo("user@example.com"));
 }
}

关键收益：

🚀 测试速度快：没有网络请求
✅ 测试可重复：结果不受外部服务状态影响
🔍 验证行为：可以精确验证 EmailProvider.send() 是否被调用

四、💡 实战示例 & 踩坑指南

综合案例：订单处理服务

让我们看一个更复杂的例子，结合两种方法：

/**
 * 重构后的订单处理服务：完全可测试
 */
public class OrderProcessor {

 private final PaymentGateway paymentGateway;
 private final InventoryService inventoryService;

 // 通过构造函数注入所有外部依赖
 public OrderProcessor(PaymentGateway paymentGateway,
 InventoryService inventoryService) {
 this.paymentGateway = paymentGateway;
 this.inventoryService = inventoryService;
 }

 public OrderResult process(Order order) {
 // 1️⃣ 纯业务逻辑：验证订单
 validateOrder(order);

 // 2️⃣ 纯业务逻辑：计算总价
 BigDecimal total = calculateTotal(order);

 // 3️⃣ 副作用：检查库存（通过抽象）
 if (!inventoryService.isAvailable(order)) {
 return OrderResult.outOfStock();
 }

 // 4️⃣ 副作用：处理支付（通过抽象）
 PaymentResult payment = paymentGateway.charge(order.getCustomerId(), total);

 // 5️⃣ 纯业务逻辑：根据支付结果处理
 return buildResult(order, payment);
 }

 // 可独立测试的纯方法
 void validateOrder(Order order) {
 if (order == null || order.getItems().isEmpty()) {
 throw new IllegalArgumentException("订单无效");
 }
 }

 // 可独立测试的纯方法
 BigDecimal calculateTotal(Order order) {
 return order.getItems().stream()
 .map(item -> item.getPrice().multiply(BigDecimal.valueOf(item.getQuantity())))
 .reduce(BigDecimal.ZERO, BigDecimal::add);
 }

 // 可独立测试的纯方法
 private OrderResult buildResult(Order order, PaymentResult payment) {
 return payment.isSuccess()
 ? OrderResult.success(order.getId())
 : OrderResult.paymentFailed(payment.getErrorMessage());
 }
}

常见陷阱 & 解决方案

⚠️ 陷阱	表现	✅ 解决方案
接口过大	一个接口包含十几个方法，实现困难	遵循接口隔离原则，拆分为小接口
过度设计	简单场景也强行引入接口	先有测试需求再抽象，避免过早优化
Mock 滥用	测试全是 Mock，失去实际意义	优先用 Fake，核心业务逻辑用真对象
依赖隐藏	在方法内部 `new` 依赖对象	所有依赖通过构造函数注入

测试策略选择

┌─────────────────────────────────────────────────────────┐
│ 纯业务逻辑（calculateTotal, validateOrder） │
│ └── 直接测试，无需任何 Mock/Fake │
├─────────────────────────────────────────────────────────┤
│ 外部依赖（EmailProvider, PaymentGateway） │
│ ├── 集成测试：使用真实实现（连接测试环境） │
│ └── 单元测试：使用 Fake/Stub 实现 │
├─────────────────────────────────────────────────────────┤
│ 协调/编排逻辑（checkout, process） │
│ └── 使用 Fake 验证交互行为 │
└─────────────────────────────────────────────────────────┘

五、📋 总结

核心要点回顾

为什么要打破依赖：让代码可测试、可维护，将业务逻辑与副作用分离

两种核心方法：

🔧 方法拆分：在同一类内分离纯逻辑与副作用
🔄 引入中介：通过接口实现类间的依赖倒置

关键原则：

依赖抽象，而非具体实现
构造函数注入依赖
优先使用可独立测试的纯函数

重构决策流程

开始
 │
 ▼
方法内部混杂了业务逻辑和副作用？ ──是──▶ 方法拆分（提炼纯函数）
 │否
 ▼
类依赖了具体实现导致难以测试？ ────是──▶ 引入中介（依赖倒置）
 │否
 ▼
结束（代码已足够清晰）

💡 实践建议：下次写代码时，先问自己——“这个方法能脱离数据库运行测试吗？“如果不能，也许就是重构的时候了。

六、📚 参考

程序员的README (豆瓣) - 第二章的部分内容

Hugo 结合 Github Pages，部署你自己的静态博客

Wed, 18 Mar 2026 22:30:00 +0800

📖 读前概览

🎯 读完本篇文章，你将获得：

如何结合 Hugo 和 Github Pages，免费部署你自己的静态博客网站
⏱️ 预计阅读时间：8 分钟

Prerequisite（前置）

你需要先下载 hugo 本地

前言

Hugo 是一个基于 Go 语言的静态网站生成器，具有构建速度快、使用简单等特点。结合 GitHub Pages，我们可以免费部署一个美观的个人博客。本文将详细介绍从创建仓库到自动部署的完整流程。

一、创建 GitHub 仓库

首先，需要在 GitHub 上创建一个仓库来存放博客源码。

仓库名称建议

推荐使用 <username>.github.io 格式的仓库名，这样访问地址就是 https://<username>.github.io/，更加简洁。

例如：用户名是 Claude，仓库名就是 Claude.github.io

仓库设置

仓库必须设置为 Public，否则 GitHub Pages 无法正常访问。

二、配置 Hugo 项目

1. 修改 baseURL

编辑 Hguo 项目根目录下的 hugo.toml 文件，修改 baseURL 为你的 GitHub Pages 地址：

baseURL = 'https://<username>.github.io/'

2. 配置 .gitignore

在 Hugo 项目根目录创建 .gitignore 文件（如果不存在），添加以下内容：

# ==============================================================================
# Hugo 生成文件和缓存
# ==============================================================================
# 生成的静态网站目录
public/

# Hugo 资源处理缓存（图片压缩、SCSS 编译等）
resources/

# Hugo 构建锁文件
.hugo_build.lock

# ==============================================================================
# 操作系统和编辑器生成的文件
# ==============================================================================
# macOS
.DS_Store
.AppleDouble
.LSOverride

# Windows
Thumbs.db
ehthumbs.db
Desktop.ini

# Linux
*~

# 编辑器
.vscode/
.idea/
*.swp
*.swo
*.swn

# ==============================================================================
# 其他
# ==============================================================================
*.log
node_modules/
.env

这些配置确保只上传源代码，而不上传生成的静态文件。

三、配置 GitHub Actions 自动部署

GitHub Actions 可以在代码推送后自动构建和部署博客，无需手动操作。

创建工作流文件

在 Hugo 项目根目录创建 .github/workflows/deploy.yml 文件，作为 Github Actions 的配置文件

# Workflow 名称
name: deploy

# 触发条件：当代码 push 到 main 分支时执行
on:
 push:
 branches:
 - main

jobs:
 deploy:
 # 运行环境：GitHub 提供的 Ubuntu 虚拟机
 runs-on: ubuntu-latest

 # 赋予 Action 向仓库写入内容的权限（用于推送 gh-pages 分支）
 permissions:
 contents: write

 steps:
 # 1. 拉取仓库代码
 - name: Checkout
 uses: actions/checkout@v4
 with:
 # 如果主题使用 git submodule 引入，需要递归拉取
 submodules: recursive
 # 获取完整 git 历史（某些主题或插件需要）
 fetch-depth: 0

 # 2. 安装 Hugo
 - name: Setup Hugo
 uses: peaceiris/actions-hugo@v3
 with:
 # 使用最新 Hugo 版本
 hugo-version: latest
 # 使用 extended 版本（支持 SCSS/SASS）
 extended: true

 # 3. 构建 Hugo 网站
 - name: Build
 # --gc 清理未使用缓存
 # --minify 压缩 HTML/CSS/JS，减少页面体积
 run: hugo --gc --minify

 # 4. 部署到 GitHub Pages
 - name: Deploy
 uses: peaceiris/actions-gh-pages@v4
 with:
 # 使用 GitHub 自动提供的 token，无需手动创建
 github_token: ${{ secrets.GITHUB_TOKEN }}
 # 要发布的目录（Hugo 构建输出目录）
 publish_dir: ./public
 # 发布到 gh-pages 分支（与源码 main 分离）
 publish_branch: gh-pages
 # 自动生成提交信息
 commit_message: "Deploy: ${{ github.sha }}"

工作流说明

这个配置文件做了以下几件事：

Checkout: 拉取代码和主题子模块
Setup Hugo: 安装最新版本的 Hugo extended
Build: 执行 hugo --gc --minify 构建网站
Deploy: 将 public/ 目录推送到 gh-pages 分支

四、启用 GitHub Pages

进入 GitHub 仓库的 Settings 页面

在左侧菜单找到 Pages
配置如下选项：
- Source: 选择 Deploy from branch
- Branch: 选择 gh-pages 分支

⚠️注意，若没有 gh-pages 分支，可能是 Github Actions 执行失败，导致没创建分支

配置完成后，GitHub 会自动开始部署，几分钟后即可通过 https://<username>.github.io/ 访问你的博客。

五、推送代码到 GitHub

首次推送

第一次推送代码到 main 分支时，GitHub Actions 会自动创建 gh-pages 分支并完成部署。

# 初始化 git 仓库（如果还没有）
git init

# 添加所有文件
git add .

# 提交
git commit -m "Initial commit"

# 添加远程仓库
git remote add origin https://github.com/<username>/<username>.github.io.git

# 推送到 main 分支
git push -u origin main

️⚠️注意：如果你本地的默认分支是 master，需要先改为 main 分支，因为 GitHub Actions 配置文件中指定的分支是 main。

# 重命名 master 为 main
git branch -M main

分支说明

main 分支：存放纯净的 Markdown 源码和配置文件
gh-pages 分支：存放生成的 HTML 静态文件（由 Actions 自动维护）

六、日常写作与发布

创建新文章

# 使用 Hugo 命令创建新文章
hugo new posts/my-new-post.md

# 或在分类目录下创建
hugo new posts/category/article-name.md

发布流程

在本地编写文章（Markdown 格式）
修改文章的 front matter，将 draft = true 改为 draft = false

提交并推送到 GitHub：

git add .
git commit -m "Add new post"
git push

GitHub Actions 自动构建并部署
几分钟后访问你的博客，新文章已上线

七、总结

通过 Hugo + GitHub Pages 的组合，我们可以：

零成本：完全免费托管
自动化：推送即发布，无需手动构建
高性能：Hugo 构建速度极快，生成的页面轻量
版本控制：所有文章都在 Git 中管理，永不丢失
自定义主题：丰富的 Hugo 主题生态

快快尝试搭建你的个人博客吧！

参考资料

操作系统基础：进程与线程

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

进程 (Process)

进程是操作系统分配资源的基本单位。

进程特征

独立性：拥有独立的内存空间
动态性：动态创建、运行、消亡
并发性：多个进程可以并发执行

进程状态转换

就绪 → 运行 → 阻塞
 ↑ ↓
 ←———————←——————

线程 (Thread)

线程是 CPU 调度的基本单位，轻量级进程（LWP）。

线程特点

共享进程资源（内存、文件等）
独立的执行流（寄存器、栈）
创建和切换开销小

进程 vs 线程

特性	进程	线程
资源共享	独立	共享
通信方式	IPC（管道、消息队列等）	共享内存
开销	大	小
安全性	高（隔离）	低（需同步）

总结

进程是资源分配单位
线程是调度执行单位
现代应用通常采用多线程模型提高并发性能

CAP 定理：分布式系统的权衡

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

CAP 定理

CAP 定理指出，分布式系统最多只能同时满足以下三个特性中的两个：

一致性 (Consistency)

所有节点在同一时间看到相同的数据。

可用性 (Availability)

每个请求都能得到响应（成功或失败），保证系统持续服务。

分区容错性 (Partition Tolerance)

系统在网络分区的情况下仍能继续运行。

三种权衡组合

组合	说明	典型系统
CA	放弃分区容错	单机数据库（RDBMS）
CP	放弃可用性	HBase, MongoDB, Redis
AP	放弃强一致性	Cassandra, DynamoDB

BASE 理论

CAP 的替代方案：

Basically Available：基本可用
Soft state：软状态
Eventually consistent：最终一致性

总结

在设计分布式系统时，需要根据业务场景选择合适的权衡：

金融交易：优先保证一致性（CP）
社交媒体：优先保证可用性（AP）

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
高性能，无运行时开销
明确的代码意图

ConcurrentHashMap 原理分析

Mon, 16 Mar 2026 11:05:04 +0800

概述

ConcurrentHashMap 是 Java 并发包中最重要的并发容器之一，本文将深入分析其实现原理。

核心特点

线程安全：无需额外同步措施即可在多线程环境下使用
高性能：采用分段锁/ CAS 机制，减少锁竞争
弱一致性：迭代器不保证强一致性，但不会抛出 ConcurrentModificationException

JDK 1.7 实现：分段锁

Segment 结构

static final class Segment<K,V> extends ReentrantLock {
 transient volatile HashEntry<K,V>[] table;
 // ...
}