设想你在看一场话剧。传统方式下，演员必须一口气把整段独白演完，中间哪怕要等一个道具送上来，全场也只能干等。Rust 的 async/await 像一位聪明的导演，把剧本切成多幕：演员演到“等待道具”时就鞠躬下台，让别的节目继续；道具一到，场务在后台喊一声，演员再上台接着演。“切幕”的过程，就是编译器把 async 函数改写成状态机；“场务喊人”的机制，就是 Executor 与 Waker。更妙的是，舞台上可能有一些道具之间用绳子连着（自引用指针），如果整块布景被挪动，绳子就会指向错误的位置——Rust 用 Pin 这把“钉子”把布景钉死在舞台上。这篇文章就带你从零看懂这套“分幕演出”的底层原理。

岗位关联

理解 async/await 状态机与 Pin，是 Rust 系统开发者设计高并发、低延迟服务的内功心法，也是面试底层原理与内存安全问题的必考点。

目录
  1. 可视化演示
  2. 异步背景：从“一口气演完”到“分幕演出”
  3. 状态机生成：导演改写分幕台本
  4. Future trait：演员手里的状态卡
  5. 执行与唤醒：场务手里的传呼机
  6. 自引用风险：绳子指向的旧位置
  7. Pin 固定原理：用钉子把提词板钉住
  8. 安全使用 Pin：正确钉道具的三种方式
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

动态演示Rust async/awa的核心机制，通过源头/管道/节点/终端四种模式展示关键概念与交互流程。

本节配有交互动效（进入视口后自动加载，约 3KB）。

Rust async/awa：asyn async/await的编译器 Future trait与Po 核心机制可视化 Rust async/awa整体架构与关键组件

异步背景：从“一口气演完”到“分幕演出”

想象剧场里只有一位演员。同步函数像一场独角戏，演员必须一口气演完；一旦某个道具没准备好，他就只能僵在台上，整个剧院都陪他等待。线程切换虽然能换人上场，但每叫来一个临时演员都要化妆、穿戏服，开销很大。Rust 的 async/await 则把剧本提前分成一幕一幕，演员演完当前一幕就退场，道具到位后再回来继续，不需要额外请人。

async fn 就是这种“分幕剧本”的语法糖。调用一个 async fn 不会真的开始表演，而是得到一张“状态记录卡”——在 Rust 中叫 Future。这张卡片记录了“剧本是谁、现在演到哪一幕、下一句台词是什么”。真正要让它动起来，还需要执行器对这张卡片反复“催场”。

所以，async fn 不是“开辟一个新线程”，而是递给执行器一张“分幕剧本卡”。演员还没上台，台上的灯也还没亮。

async fn (⋅)  ⟼  Future⟨T⟩\text{async fn}\,(\cdot) \;\longmapsto\; \text{Future}\langle T\rangle
这个式子说明：async fn 的调用结果不是普通返回值，而是一个 Future 对象，最终输出类型是 T。
  1. async fnasync 和 fn 组合声明一个异步函数，编译器会将其体转换为状态机。
    async fn (⋅)\displaystyle \text{async fn}\,(\cdot)
  2. 映射符\(\longmapsto\) 读作“映射到”，强调调用后产生的是一个待执行的 Future。
    ⟼\displaystyle \longmapsto
  3. Future\<T\>Future 是一个惰性的计算载体，泛型参数 T 表示最终产出的值类型。
    Future⟨T⟩={Ready(v:T)Pending\displaystyle \text{Future}\langle T\rangle = \begin{cases} \mathrm{Ready}(v: T) \\ \mathrm{Pending} \end{cases}
  4. 惰性含义此时函数体一行都没运行，只有被 poll 才会推进。

状态机生成：导演改写分幕台本

导演拿到一部连续三小时的剧本，不会让演员真的连续演三小时，而是把剧本裁剪成若干幕：第一幕到“等待道具”结束，第二幕从道具送来开始。Rust 编译器就是这样一位导演，它把 async 函数体在每一个 await 点处切断。每两个切断点之间的代码，构成状态机中的一个状态。

编译器生成的状态机结构体通常包含一个判别字段用来记录当前在第几幕，同时把跨过 await 仍然需要存活的局部变量保存到结构体里。为什么？因为 Future 可以在中途被丢弃，下次 poll 时它必须从上次“落幕”的地方继续，而不是从头开始。状态机让“接着演”变成一条精确的转换路径。

分幕台本的好处是：演员（线程）不用一直占着舞台。编译器把“连续演出”变成了“可中断、可恢复”的状态机，这正是异步并发能够高效运转的根基。

M=(S,  E,  δ,  s0,  F)M = (S,\; E,\; \delta,\; s_0,\; F)
这是状态机五元组：状态集、事件集、转换函数、初始状态和终态，用来形式化描述 async 函数如何被切分。
  1. 状态集 S每个 await 之间的代码段对应一个状态，加上初始状态和完成状态。
    S={s0,  s1,  …,  sn}\displaystyle S = \{s_0,\; s_1,\; \ldots,\; s_n\}
  2. 事件集 E可以触发状态转换的事件，例如“poll 被调用”或“IO 完成”。
    E={poll,  io_ready,  …}\displaystyle E = \{ \mathrm{poll},\; \mathrm{io\_ready},\; \ldots \}
  3. 转换函数 δ描述在某个状态遇到某个事件后跳转到哪个状态。
    δ:S×E→S\displaystyle \delta: S \times E \to S
  4. 初始状态与终态Future 刚创建时位于 s₀，所有 await 完成则到达终态 F，之后 poll 返回 Ready。

Future trait：演员手里的状态卡

演员在后台休息时，手里会拿着一张“状态卡”，上面写着：现在是第几幕、下一句台词是什么、道具需要谁的签名。Rust 中这张状态卡就是 Future trait。任何类型只要实现它，就表明自己是一台可以分幕执行的状态机。

核心方法是 poll，导演每喊一次“继续”，就调用一次 poll。poll 执行一小段代码，然后返回两个结果之一：Poll::Ready(T) 表示全剧演完，交出最终值；Poll::Pending 表示剧情暂停，还需要等某个外部事件。poll 的参数 cx: &mut Context 里藏着 Waker——那是场务的传呼机。

对初学者来说，可以先把 poll 理解成“导演喊 action”。它不会保证一次演完，但每次喊都会让剧情往前挪一点。整个 async 生态就是在无数个“action/暂停/再 action”的循环上构建起来的。

poll:  Pin⟨&mut Self⟩×&mut Context⟶Poll⟨Output⟩\mathrm{poll}:\;\mathrm{Pin}\langle\&mut\,\mathrm{Self}\rangle \times \&mut\,\mathrm{Context} \longrightarrow \mathrm{Poll}\langle \mathrm{Output}\rangle
poll 接收固定住的可变 self 和上下文引用，返回 Ready（结果） 或 Pending，这是异步任务推进的最小单元。
  1. Pin\<&mut Self\>self 的类型是“固定不可移动的可变引用”，这是为了防止自引用结构移动后出错。
    Pin⟨&mut Self⟩\displaystyle \mathrm{Pin}\langle\&mut\,\mathrm{Self}\rangle
  2. Context 引用&mut Context 携带 Waker，供 Future 登记“准备继续”的信号。
    &mut Context\displaystyle \&mut\,\mathrm{Context}
  3. Poll 枚举返回值是 Poll，要么 Ready(v) 带着输出，要么 Pending 表示暂停。
    Poll⟨Output⟩=Ready(v)∣Pending\displaystyle \mathrm{Poll}\langle \mathrm{Output}\rangle = \mathrm{Ready}(v) \mid \mathrm{Pending}
  4. 调用效果每次 poll 都会从当前状态向后推进一段代码。
rust4 行
pub trait Future {    type Output;    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;}

执行与唤醒：场务手里的传呼机

分幕演出要想流畅，剧院需要一个调度中心（Executor）和一群场务（Waker）。调度中心维护一张“待演剧目表”（任务队列），不断从表中取一个任务、喊一次 action，也就是调用 poll。如果演员说 “Pending，我还在等道具”，调度中心就把这个任务放回队列，先处理别的节目。

问题来了：如果只是不断轮询“道具好了吗？”，会浪费大量时间。于是 Waker 出场：当 Future 返回 Pending 时，它可以克隆一份 Waker，交给操作系统或另一个线程，让它们在事件真正完成时调用 wake()。wake() 一响，执行器就知道某部戏可以再次上台，于是把对应的 Future 重新放回任务队列。

这个机制让“等待”不再白占资源。就像场务拿着传呼机，道具到了才呼一声，演员才重新上台，而不是每隔几秒就跑上台问“道具好了吗”。

Executor(q)  →poll  {Ready(v):q:=q∖{task}Pending(w):q:=q∪{task}\mathrm{Executor}(q) \;\xrightarrow{\text{poll}}\;\begin{cases}\mathrm{Ready}(v) : q := q \setminus \{\mathrm{task}\}\\[2mm]\mathrm{Pending}(w) : q := q \cup \{\mathrm{task}\}\end{cases}
执行器调度公式：任务完成后移出队列；任务暂停则继续留在队列中，等待 Waker 苏醒后再次被 poll。
  1. 任务队列 q执行器保存的一组待调度的 Future。
    q={fut1,  fut2,  …}\displaystyle q = \{\mathrm{fut}_1,\; \mathrm{fut}_2,\; \ldots\}
  2. poll 调用执行器从队首取出任务并调用其 poll 方法。
    Executor(q)→poll…\displaystyle \mathrm{Executor}(q) \xrightarrow{\text{poll}} \ldots
  3. Ready 分支如果返回 Ready，任务已经演完，把它移出队列，输出结果交给上层。
    q:=q∖{task}\displaystyle q := q \setminus \{\mathrm{task}\}
  4. Pending 分支如果返回 Pending，任务被重新入队或登记在唤醒列表，待 wake 后再次加入队列。
    q:=q∪{task}\displaystyle q := q \cup \{\mathrm{task}\}

自引用风险：绳子指向的旧位置

分幕演出最怕一类道具事故：两块提词板之间用绳子系着，绳头固定在其中一块的边角上，而另一块板上画着指向第一块的箭头。如果工作人员把两块板一起搬到舞台另一侧，箭头仍然指向原来的空位置——绳子拉了个空。这在编程里叫自引用结构：结构体内部的一个字段，保存着指向另一个字段的引用。

在 async 函数中，如果某个局部变量在 await 之后还要用，并且另一个变量持有它的引用，编译器为了让状态机恢复执行，会把这两个变量都存进同一个结构体。于是结构体内部出现了“字段 A 指向字段 B”的自引用。此时如果这个 Future 结构体在内存中被移动（比如返回值、重新赋值），字段 A 里保存的地址就不再指向字段 B 的新家，成为悬垂指针。

没有 Pin 之前，Rust 的 async 曾因为这个痛点难以安全实现。解决办法不是禁止自引用，而是保证“结构体一旦创建，就钉死在某个地址上，不再移动”。

T={ base: String,  ref: &′a String, },move(T)  ⇒  ref↦̸baseT = \{\, \mathbf{base}:\,\mathrm{String},\; \mathbf{ref}:\,\&'a \,\mathrm{String},\,\},\quad\mathrm{move}(T) \;\Rightarrow\; \mathrm{ref}\not\mapsto \mathbf{base}
T 含有一个数据字段 base 和一个指向 base 的引用字段 ref；一旦 T 整体移动，ref 将指向旧地址。
  1. 结构体 T 的两个字段base 持有实际数据，ref 存有指向 base 的引用。
    T={ base: String,  ref: &′a String }\displaystyle T = \{\, \mathbf{base}:\,\mathrm{String},\; \mathbf{ref}:\,\&'a \,\mathrm{String}\,\}
  2. 移动语义Rust 中赋值、传参、返回都可能移动结构体，内存地址随之变化。
    move(T)\displaystyle \mathrm{move}(T)
  3. 引用失效移动后 ref 仍指向旧地址，不再指向 base 的新位置。
    ref↦̸base\displaystyle \mathrm{ref}\not\mapsto \mathbf{base}
  4. 悬垂指针后果使用 ref 读取的是已失效内存，这属于未定义行为，可能导致崩溃或数据损坏。

Pin 固定原理：用钉子把提词板钉住

剧场应对道具事故的方法是：给重要的提词板钉上一颗钉子，并挂上警示牌“此道具禁止搬动”。Rust 的 Pin 就是这颗钉子。Pin<P> 包装一个指针 P（比如 &mut T、Box<T>），并约定：如果 T 没有实现 Unpin，那么通过安全代码就无法获得 T 的可变引用去移动它。

Unpin 是一个 auto trait，绝大多数普通类型（Vec、String、u64）都自动实现，意思是“移动我很安全”。但编译器为 async 生成的自引用 Future 默认不实现 Unpin，也就是 !Unpin。对这类类型，Pin<&mut T> 的 get_mut 或 DerefMut 等能力被收走，只有 unsafe 代码才能绕过限制。这样，自引用字段指向的地址就永远不会因为移动而失效。

钉子并不改变舞台本身，只是改变“能搬动”的规则。Pin 也不改变结构体内部布局，只是让编译器禁止移动行为，这正是内存安全的精巧之处。

∀T, 若 T:!Unpin,Pin⟨P⟩  ⟹  P::Target 在内存中不被移动\forall T,\ \text{若}\ T:\mathrm{!Unpin},\quad \mathrm{Pin}\langle P\rangle \;\Longrightarrow\; P::\mathrm{Target}\ \text{在内存中不被移动}
对！Unpin 类型，Pin 的核心保证是“目标内存位置固定不动”。
  1. Unpin 标记类型上的一个自动 trait，表示移动该类型是安全的。
    T:Unpin\displaystyle T: \mathrm{Unpin}
  2. !Unpin 类型如 async 生成的自引用结构，默认不实现 Unpin。
    T:!Unpin\displaystyle T: \mathrm{!Unpin}
  3. Pin 的约束若 T: !Unpin，Pin<&mut T> 不提供安全的 DerefMut，因此无法得到 &mut T 来移动。
    Pin⟨&mutT⟩⇏&mutT(T:!Unpin)\displaystyle \mathrm{Pin}\langle\&mut T\rangle \not\Rightarrow \&mut T \quad (T:\mathrm{!Unpin})
  4. 安全保证只要不通过 unsafe 解除 Pin，编译器就会阻止移动操作，使自引用保持有效。

安全使用 Pin：正确钉道具的三种方式

既然提词板不能搬，最省心的做法是把板子放在一个沉重的固定托架上，托架可以搬，但板子巍然不动。这对应 Box::pin：把 T 分配到堆上，返回 Pin<Box<T>>。之后移动 Box 指针只改变指针变量本身，堆上的 T 地址始终不变，自引用安全无忧。

如果想在栈上固定，可以使用 pin! 宏（标准库和 Tokio 等都提供）。pin! 在栈上创建一个局部固定对象，并借用它得到 Pin<&mut T>。由于该对象是局部变量，且借用期不会超出作用域，移动风险被控制住。自实现 Future 时，常见做法是用 pin_project 这类库在字段声明 #[pin] 属性，让编译器安全地处理固定字段。

钉子和托架要配合使用：Box::pin 适合所有权明确的场景，pin! 适合临时借用，pin_project 适合在自定义 Future 中管理多个固定字段。只要固定做对了，异步舞台就能安全地一幕一幕演下去。

Box::pin(t)  :  Pin⟨Box⟨T⟩⟩,move(Box)⇏move(T)\mathrm{Box}::\mathrm{pin}(t) \;:\; \mathrm{Pin}\langle \mathrm{Box}\langle T\rangle\rangle,\quad \mathrm{move}(\mathrm{Box}) \not\Rightarrow \mathrm{move}(T)
Box::pin 将 T 固定在堆上，Box 指针移动不会改变 T 的地址，这是最常见的固定方式。
  1. 堆分配Box::pin(t) 在堆上为 t 分配空间，返回一个特殊指针。
    Box::pin(t)\displaystyle \mathrm{Box}::\mathrm{pin}(t)
  2. Pin 包装返回值类型是 Pin<Box<T>>，同时享有 Box 的所有权和 Pin 的固定语义。
    Pin⟨Box⟨T⟩⟩\displaystyle \mathrm{Pin}\langle \mathrm{Box}\langle T\rangle\rangle
  3. 移动 Box 不移动目标Box 指针移动时，堆上的 T 地址不变。
    move(Box)⇏move(T)\displaystyle \mathrm{move}(\mathrm{Box}) \not\Rightarrow \mathrm{move}(T)
  4. 安全边界固定后不能通过安全代码取出 &mut T，否则可能破坏自引用。

AI 应用场景

高并发网络服务

阶段：请求处理与异步推理调度

解决的问题：传统每连接一线程的模型在数万并发下会耗尽内存；AI 服务的推理等待、数据预处理等步骤也大量处于 IO 等待。Rust async 把每个请求变成一个轻量 Future 状态机，配合执行器复用少量线程，支撑超高并发。

具体案例：某推荐系统网关需要同时为 5 万在线用户转发请求。使用 Tokio 编写异步 HTTP 服务，每个连接在等下游模型响应时返回 Pending，由 Waker 在响应到达后唤醒，网关在 4 核机器上也能轻松抗住峰值流量。

实时数据流处理

阶段：数据采集与特征计算流水线

解决的问题：多个传感器或数据源在毫秒级间隔产生事件，若同步等待会阻塞特征计算。使用 async 状态机管理每条数据流的等待与计算，把特征提取过程的每个 await 点切分成独立阶段，灵活调度。

具体案例：量化交易系统需要同时订阅行情、新闻、舆情等 20 路数据流。Rust async 让每个订阅源是一个 Future，行情到达时 Waker 唤醒对应回调，特征计算器在 CPU 核上并行运行，延迟从毫秒级降到微秒级。

嵌入式异步驱动

阶段：端侧 AI 模型的 IO 调度

解决的问题：嵌入式设备上内存和线程都极其宝贵，且有大量外设等待。async 状态机让每个外设操作（如读取传感器）变成轻量协程；Pin 保证涉及自引用的驱动状态安全固定。

具体案例：一款 TinyML 手势识别设备需要同时轮询加速度计和陀螺仪。用 async fn 描述读取流程，Box::pin 固定驱动对象，主循环用 wake() 唤醒待读外设，最终在仅 64KB RAM 的 MCU 上流畅运行。

Python 演示

python54 行
from collections import dequefrom enum import Enumimport random  class Stage(Enum):    INIT = 0    WAIT_IO = 1    PROCESS = 2    DONE = 3  class MiniFuture:    """用 Python 模拟 Rust async 状态机的基本轮询行为"""    def __init__(self, tid):        self.tid = tid        self.stage = Stage.INIT        self.output = None        self._poll_count = 0     def poll(self):        """对应 Future::poll；返回 True 表示 Ready，False 表示 Pending"""        self._poll_count += 1        if self.stage == Stage.INIT:            self.stage = Stage.WAIT_IO            return False        if self.stage == Stage.WAIT_IO:            # 模拟 IO 事件完成的概率            if random.random() < 0.4:                self.stage = Stage.PROCESS            return False        if self.stage == Stage.PROCESS:            self.stage = Stage.DONE            self.output = f"task-{self.tid}-done"            return True        return True  def main():    tasks = deque(MiniFuture(i) for i in range(5))    round_no = 0    while tasks and round_no < 100:        round_no += 1        task = tasks.popleft()        if task.poll():            print(f"[round {round_no}] {task.output}")        else:            # Pending 的任务重新放到队尾等待下次轮询            tasks.append(task)    print("all done")  if __name__ == "__main__":    main()
目的：用 Python 模拟 Rust Future 的状态机轮询，演示 poll 推进状态、Pending 任务重新入队的核心调度逻辑。
  1. self.stage = Stage.WAIT_IO第一次 poll 把状态从 INIT 推到 WAIT_IO，对应 async fn 首次执行遇到 await。
  2. if random.random() < 0.4:模拟外部 IO 事件是否完成，对应真实异步中由 Waker 通知的“就绪”。
  3. if task.poll():执行器对 Future 的一次调用，返回 True 表示 Ready，否则 Pending。
  4. tasks.append(task)Pending 任务重新入队，对应执行器调度队列的重新安排。
  5. while tasks and round_no < 100:事件循环主体，不断从队列取出任务并 poll，直到全部完成。

常见误区

误区我刚学 Rust async 时，以为 `async fn` 会和 `thread::spawn` 一样创建一个新线程，只是 API 不同。

正解async fn 只生成一个 Future 状态机，它本身不占用任何线程。线程由执行器提供，poll 在哪个线程上跑完全由执行器决定。分幕剧本不会自动多出一个演员，还是同一个舞台，只是剧目被切开了而已。

为何常见：很多其他语言的异步实现或并发概念容易让人联想到线程，尤其“异步”一词常让人误以为背后有隐藏线程。

误区我写 `let f = my_async_fn();` 后以为函数体已经开跑了，等一会儿就会自动完成。

正解调用 async fn 只创建 Future，函数体一行都没执行。直到第一次 poll（例如执行器选中它）才开始执行，而且只会执行到第一个 await。发给你一本剧本不算开演，导演喊“开始”才进入第一幕。

为何常见：普通函数调用会立即执行体中的代码，这种惯性思维被迁移到了 async 上。

误区我听说自引用结构移动会出问题，所以把所有自引用对象都放进 Box，以为这样万事大吉。

正解Box 把对象放在堆上，移动 Box 指针时对象地址不变，所以堆分配确实能避免“结构体移动导致内部指针失效”的问题。但如果之后从 Box 中取出 T 并移动它，或类型本身是！Unpin，仍需要 Pin 来保证安全。Pin 才是表达“禁止移动”的语言级约定。

为何常见：Box 提供了稳定堆地址，容易让人误以为地址固定就等于已经处理了所有移动问题。

误区我看到 async 生成的 Future 是！Unpin，以为所有 Rust 类型都默认不可移动，Pin 会导致平时写代码处处受限。

正解Unpin 是 auto trait，绝大多数类型（Vec、String、u64、普通 struct）都自动实现，它们移动毫无问题。只有编译器生成的 async Future 等自引用类型才不实现 Unpin。Pin 只对！Unpin 类型有实际约束。

为何常见：把“类型是否 Unpin”与“是否被 Pin 固定”混为一谈，听说 async Future 不可移动就以为所有类型都不可移动。

面试题

Q1. 调用一个 async fn 函数会发生什么？

单选题 · easy

  • A.立即在当前线程中执行函数体
  • B.返回 Future，函数体延迟执行← 正确答案
  • C.自动创建一个专属线程运行它
  • D.在编译阶段就完成所有计算

答案：B。async fn 调用时只创建 Future 状态机，函数体并不会运行。比喻：拿到剧本不代表开演，导演（执行器）喊 action 才进入第一幕。A 错在“立即执行”，C 错在“创建线程”，D 错在“编译期计算”。

Q2. Future::poll 返回 Poll::Pending 表示什么？

单选题 · easy

  • A.任务已经全部完成
  • B.任务尚未完成，需要等待唤醒← 正确答案
  • C.任务发生了致命 IO 错误
  • D.任务被操作系统强制终止

答案：B。Pending 是“暂停”不是“结束”，演员说“道具还没到，我歇一会儿”。A 是 Ready 的语义，C 和 D 在 Poll 枚举中不存在，错误分支由 Output 类型或错误处理表达。

Q3. 编译器把 async 函数转换成的核心结构是？

单选题 · mid

  • A.操作系统线程和线程池
  • B.保存状态与局部变量的状态机← 正确答案
  • C.基于编译器协程的栈对象
  • D.一组系统级信号处理器

答案：B。async fn 的函数体被切分成多个状态，存在结构体里，poll 时通过 match 推进。B 是标准模型。A、C、D 都不是编译器的产物。

Q4. 关于 Waker 的作用，下面哪项最准确？

单选题 · mid

  • A.为异步任务分配一个唯一的线程名
  • B.在 Future 可继续执行时通知 Executor 重新调度← 正确答案
  • C.直接调用 Future 的 poll 方法推进任务
  • D.在每个 CPU 核上均衡任务数量

答案：B。Waker 是“传呼机”，事件发生后调用 wake() 唤醒执行器，让任务重新进入队列。B 正确。A 是线程概念，C 是执行器的职责，D 是负载均衡器的职责。

Q5. 自引用结构体整体移动后，内部引用会出现什么问题？

单选题 · hard

  • A.编译器自动修复引用地址
  • B.引用仍指向旧地址，成为悬垂指针← 正确答案
  • C.结构体大小自动扩展以容纳新地址
  • D.poll 方法会自动跳过这段代码

答案：B。移动后结构体所有字段地址都变了，但引用字段里存的还是旧地址。就像绳子仍拴在原来的钉孔上，板子已经搬走。B 正确，A、C、D 都是不存在的机制。

Q6. Rust 中 Pin<P> 的核心目的是什么？

单选题 · mid

  • A.提升指针解引用的执行性能
  • B.防止 P::Target 在内存中被移动，保证自引用安全← 正确答案
  • C.自动释放结构体的堆内存
  • D.把栈上数据自动拷贝到堆上

答案：B。Pin 是语言提供的“钉子”，钉住！Unpin 类型的内存位置。B 正确。性能不是 Pin 的目的，内存释放是所有权/RAII 的职责，堆拷贝是 Box 的能力。

Q7. 以下哪个类型通常实现了 Unpin？

单选题 · easy

  • A.async 生成的自引用 Future
  • B.包含 PhantomPinned 字段的结构体
  • C.普通的 Vec<u8>← 正确答案
  • D.所有类型都默认不实现 Unpin

答案：C。Unpin 是自动 trait，大部分普通类型如 Vec 都能自由移动。A、B 是典型的！Unpin 类型，D 与事实相反。

Q8. 以下哪些方式可以安全地获得一个固定（pinned）的 Future？

多选题 · mid

  • A.使用 Box::pin(fut) 在堆上固定← 正确答案
  • B.使用 pin! 宏在栈上固定← 正确答案
  • C.使用 pin_project 在自定义类型中固定字段← 正确答案
  • D.直接使用 std::mem::swap 交换 Future 和占位符

答案：ABC。Box::pin 和 pin! 都是标准做法，pin_project 能让自定义 Future 安全地处理固定字段。D 的 swap 会在移动 Future，破坏 Pin 的固定性，不正确。

Q9. 对于 Pin<&mut T>，当 T: !Unpin 时，下列哪些操作是不被安全代码允许的？

多选题 · extreme

  • A.调用 pin.as_mut() 得到 Pin<&mut T> 的可变形式
  • B.调用 Pin::get_mut(pin) 直接获得 &mut T← 正确答案
  • C.在 T 构造完成后，用 Pin::new(&mut t) 包装一个新的可变引用← 正确答案
  • D.执行 *pin = new_value 来整体覆盖 T← 正确答案

答案：BCD。Pin<&mut T> 对！Unpin 类型只允许安全的 as_mut 等方法，无法通过 get_mut 获得 &mut T，也无法移动 T 或通过 DerefMut 赋值。就像钉子钉住后，你只能调整灯光，不能搬动道具。

Q10. 一个异步运行时（如 Tokio）中 Executor 的主要职责包括哪些？

多选题 · hard

  • A.维护就绪任务队列并调度 poll← 正确答案
  • B.为每个任务创建独立操作系统线程
  • C.在 Waker 触发后重新 poll 对应任务← 正确答案
  • D.直接修改 Future 内部状态以强制完成

答案：AC。Executor 负责维护任务队列和调用 poll，并在 Waker 触发后重新调度任务。B 和 D 不是异步运行时的职责：async 模型不会为每个任务建线程，也不会强制修改状态。