📚 课程目录第4章并发编程与异步模型

4. 并发编程与异步模型

本章聚焦大厂面试高频考点：异步运行时选型、线程安全机制、锁策略决策链。以下通过结构化卡片与真实案例拆解，帮助你建立可迁移的并发知识体系。

📌 图形解读：从“冲突概率”出发，沿着高/低分支依次检查读写比例和临界区长度，终端节点即为推荐锁类型。注意：异步场景应优先使用 tokio::sync::Mutex 避免阻塞线程。

面试问答卡片

  🎯 面试问题：如何选择异步运行时（Tokio / async-std / smol）？
  考察点：对各运行时特性、生态、性能的认知，能否根据场景做技术选型。
回答框架：定位三个运行时 → 按场景分类（I/O密集型选Tokio，轻量/嵌入式选smol，简洁体验选async-std但注意生态）。
示例回答：“Tokio 是业界标准，成熟度高，适合高I/O并发微服务；async-std 语法接近std但生态薄；smol 极简洁，适合嵌入式或极小运行时。我通常默认选Tokio，除非对二进制大小有严格限制。”
可能追问：Tokio 的多线程调度机制？runtime.spawn 与 task::spawn 区别？如何控制线程数？
避坑提醒：❌ 不要在生产高并发场景用 smol 默认配置；✅ 明确区分 std::sync::Mutex 与 tokio::sync::Mutex 的使用场景。

  🎯 面试问题：Rust 中如何保证线程安全？
  考察点：对 Send/Sync trait 的理解，同步原语的使用经验，是否了解编译时与运行时两层保障。
回答框架：先讲编译时（Trait 边界）→ 后讲运行时（Arc、Mutex、RwLock、原子操作）→ 最后提异步场景的特殊性。
示例回答：“Rust 通过 Send、Sync 在编译期检查线程安全。运行时用 Arc> 共享可变状态，读多写少用 RwLock，短操作用 Atomic。异步中优先使用 tokio::sync::Mutex 避免阻塞。”
可能追问：为什么 Rc<T> 不是 Send？parking_lot::Mutex 与 std 版本对比？死锁预防策略？
避坑提醒：❌ 避免盲目使用 unsafe impl Send；✅ 多读场景用 RwLock 而非 Mutex。

  🎯 面试问题：锁策略如何根据业务场景选择？
  考察点：是否具备锁的选型经验，能否在性能、正确性、复杂度之间权衡。
回答框架：冲突概率 → 读写比例 → 临界区耗时 → 是否可无锁。画出一个决策树（可参考上方 SVG）。
示例回答：“高冲突用 Mutex（std 或 tokio）；读远多于写用 RwLock；临界区极短（<100ns）用自旋锁；能用原子操作解决的问题优先用 atomic。”
可能追问：自旋锁的缺点？tokio::sync::Mutex 内部实现 vs std::sync::Mutex？如何实现无锁结构（crossbeam）？
避坑提醒：❌ 不要在异步 .await 点持有 std::Mutex 锁；✅ 了解 C++ 锁策略 vs Rust 锁策略的差异。

项目案例：高并发实时聊天系统

维度	内容
项目名称	BuzzChat — 基于 Rust+Tokio 的实时消息平台
业务背景	支持百万级用户同时在线的聊天室，消息秒级可达，需处理房间内广播与点对点私信。
规模指标	10万并发 WebSocket 连接，消息延迟 <50ms，单房间最大 1万人。
技术栈	Tokio / Axum / WebSocket / Redis Pub/Sub / Postgres / `Arc<RwLock<HashMap>>` 管理连接
核心难点	连接生命周期管理（优雅关闭、心跳检测）房间内消息广播的锁竞争：使用 `tokio::sync::broadcast` 替代全局锁背压控制：慢消费者导致内存堆积，引入令牌桶限流
面试高频追问	为什么选用 `broadcast` 而非 `mpsc`？（解耦生产者/消费者数量）如何防止慢消费者拖垮系统？（`recv()` 超时 + 独立丢弃策略）百万连接下 `Arc<RwLock>` 是否成为瓶颈？（实际读操作极快，写锁仅房间成员变更时触发）
可迁移回答话术	“在处理扇出场景时，我使用 `tokio::sync::broadcast` 实现一对多推送，并通过背压层限制每个消费者的缓冲大小。对于连接管理，我用 `Arc<RwLock<HashMap<UserId, Sender>>>`，写锁仅在用户加入/离开时抢占，读锁近乎无竞争。”

⚠️ 项目面试要点：面试官关注你是否理解 “为什么” 而非 “用了什么”。务必解释锁选型背后的权衡，以及 broadcast 与 mpsc 在语义上的差异。背压处理是区分初级与高阶工程师的关键。