第4章 Rust异步编程与 Tokio 运行时

异步编程是 Rust 分布式系统工程师的必考项，Tokio 作为事实标准运行时常被深度追问。本章从面试官考察视角出发，拆解回答路径、高频追问与常见失分点。

问答卡片 1

回答框架： 先定义 Future 是惰性计算的 trait → 解释 poll 方法返回 Poll::Pending 或 Poll::Ready → 说明 await 会生成状态机并递归调用 poll → 最后点明运行时（如 Tokio）协调跨 task 的 wakeup。

简短示例： “Future 是一个状态机，通过 poll 推进计算。await 语法糖会生成实现了 Future 的匿名结构体，保存所有局部变量。Tokio 的 executor 通过传入 Waker，在 I/O 就绪时重新 poll 该 Future。”

追问： “Waker 的具体实现是怎样的？如果多个 Waker 同时唤醒同一个 task 会怎样？”
避坑： 切忌死记硬背源码行号，要讲清楚 Waker 等价于一个回调句柄，task 被唤醒后放入全局队列；重复唤醒通常由位标记去重，但需要强调 Tokio 会避免重复入队。

问答卡片 2

回答框架： 指出标准 Mutex 可能阻塞线程进而阻塞 event loop → 引出 tokio::sync::Mutex 的作用（await 内部出让线程）→ 但也要权衡性能：长时间持有锁或跨 .await 才需后者，否则常规 Mutex 更高效。

简短示例： “若锁持有时间短且不跨 .await，使用 std::sync::Mutex 配合 try_lock 即可；若必须跨 .await 持有锁，则必须用 tokio::sync::Mutex，否则会导致线程池饥饿。”

追问： “你提到饥饿，能具体描述饥饿发生的场景吗？如何监控？”
避坑： 不要只回答“会死锁”，要画出时间线：一个 task 在 .await 前锁住 Mutex，然后 yield，其他 task 永远获取不到锁。可以结合 tokio-console 或 tracing 工具来检测。

问答卡片 3

回答框架： 用 bucket 算法 + tokio::sync::Semaphore → 通过 tokio::time::interval 定时补充 → 每个请求 try_acquire 如果失败则返回 429 → 考虑跨节点同步时引入 Redis 或 etcd 作为中心化 存储。

简短示例： “使用 Semaphore::new(limit) 控制并发数，用 tokio::spawn 一个后台任务每隔 1 秒增加上限数量的 permit。关键：利用 Semaphore 的关闭特性实现 graceful shutdown。”

追问： “如果跨多个机器实现全局限流怎么办？如何保证 Semaphore 操作不是单点瓶颈？”
避坑： 回答时要区分“本地限流”和“全局限流”。对于全局限流可以提及 Redis Incr 配合 local sliding window（如滑动时间窗口预分配），避免每次都远调 Redis。切忌不提本地缓存优化而直接跳到分布式锁。