第4章 并发编程与多线程面试题：线程同步、无锁编程、内存模型
核心知识结构对比表
| 领域 | 关键概念 | 常用技术 | 面试高频考点 |
|---|---|---|---|
| 线程同步 | 互斥、条件变量、读写锁 | std::mutex, std::condition_variable, std::shared_mutex | 死锁预防、条件变量虚假唤醒、RAII锁封装 |
| 无锁编程 | 原子操作、内存序、CAS | std::atomic, memory_order_relaxed/acquire/release | ABA问题、内存屏障、无锁队列实现 |
| 内存模型 | happens-before、顺序一致性、数据竞争 | atomic操作搭配内存序、volatile | 多线程下未定义行为、编译器重排序、硬件重排序 |
面试问答卡片（3个）
🔹 面试问题1：请解释 C++ 中 std::mutex 和 std::atomic 的区别，以及各自适用的场景。
考察点：是否理解两种同步机制的设计层次（锁 vs 无锁），能否根据并发粒度、性能要求、异常安全做出合理选择。
回答框架：1. 定位本质：mutex 是锁保护临界区，atomic 是硬件支持的原子操作。2. 适用场景：频繁短操作用 atomic，复杂资源访问用 mutex。3. 对比开销：mutex 涉及系统调用/上下文切换，atomic 通常使用 CPU 指令。4. 强调内存序：atomic 需要显式指定 memory_order。5. 举例说明（如计数器 vs 队列）。
示例回答：std::mutex 用于保护临界区内多个变量的复合操作，如链表插入；std::atomic 只保证单变量读‑改‑写原子性，适合计数器或标志位。选择依据是临界区大小和操作频率：短小频繁用 atomic，复杂或涉及多个变量用 mutex。atomic 还需留意内存序可能引入的可见性问题。
可能追问：① std::atomic 的加载/存储默认是什么内存序？② 如果 atomic 内部需要多个原子变量协同，你能用什么方案？③ 用 mutex 实现自旋锁与 std::atomic 自旋的区别？
避坑提醒：不要泛泛说 atomic 比 mutex 快，要说明上下文（临界区极短时快，否则可能因自旋浪费 CPU）。避免混淆 atomic_flag 和 atomic
🔹 面试问题2：如何用 C++ 实现一个无锁的多生产者单消费者（MPSC）队列？你如何保证线程安全？
考察点：对无锁数据结构设计的深度理解（CAS、内存序、ABA 问题），以及能否平衡正确性与性能。
回答框架：1. 提出基于链表或环形缓冲区的方案。2. 生产者使用 atomic compare_exchange_weak 更新尾指针。3. 消费者原子地读取头指针。4. 处理内存序：release-store 生产者数据，acquire-load 消费者。5. 指出 ABA 问题：使用引用计数或标记指针。6. 说明局限：多消费者场景需额外机制。
示例回答：采用链表实现，每个节点含 data 和 next。生产者 CAS 更新队列尾部尾指针，若 CAS 失败则重试；消费者原子地 pop 头节点。内存序上，生产者写入 node->data 后用 release，消费者用 acquire 保证数据可见性。通过附加 ABA 标记（如 tagged pointer）避免重用节点导致的问题。
可能追问：① 为什么不用 std::queue 加 mutex？性能差异在什么量级？② 如何支持多消费者？③ 解释 memory_order_release 和 memory_order_consume 的关系。
避坑提醒：别忽略 ABA 问题（尤其没有 GC 环境）。回答时主动提及并给出解决方案（标记、hazard pointer 或 epoch-based reclamation）。避免假设所有平台都支持 128-bit CAS。
🔹 面试问题3：谈谈 C++ 内存模型中的 happens-before 关系，以及它在多线程编程中的实际意义。
考察点：是否真正理解 C++ 内存模型抽象层，能否将语言规范与硬件重排序联系起来，以及能否用正确术语解释可见性。
回答框架：1. 定义：happens-before 是跨线程操作顺序的偏序关系，A happens-before B 表示 A 对内存的修改对 B 可见。2. 建立方式：同一线程的顺序、锁的解锁‑加锁、atomic 的 release‑acquire 等。3. 重要性：防止数据竞争（data race），数据竞争属于未定义行为。4. 举例：atomic store(release) 和 load(acquire) 形成同步关系，保证之前非原子变量的写入也可见。5. 对比：顺序一致性 vs 松散原子性。
示例回答：Happens-before 确保线程间操作可见性：例如线程A写入 flag.store(true, release)，线程B if(flag.load(acquire)) 可保证A在flag之前的所有写入对B可见。没有这种关系则存在数据竞争，产生未定义行为。实际开发中用它推导多线程逻辑正确性，避免盲目加锁。
可能追问：① 用 volatile 能建立 happens-before 吗？② memory_order_seq_cst 与其他序的性能差异？③ 如何在编译期检测数据竞争？
避坑提醒：不要误认为 volatile 可以用于多线程同步。强调 happens-before 是一种抽象关系，与具体平台无关。面试官常深挖“synchronizes-with”和“dependency-ordered before”的区别。
项目案例：高并发日志系统（真实项目模板）
规模指标：峰值 10 万 QPS 日志写入，日志吞吐量 500MB/s，服务节点 32 台。要求 P99.9 日志写入延迟 < 5ms。
技术栈：C++17、std::atomic、memory_order_release/acquire、无锁 MPSC 队列（基于 tagged pointer）、mmap 文件映射、异步日志落盘线程。
核心难点：
- 多线程同时写入日志时 CAS 竞争，需要减少重试次数。
- ABA 问题：节点回收后可能被新节点误判为相同指针。
- 内存序选择：既要保证日志内容可见性，又不能因过度屏障降低性能。
- 突发写入时，无锁队列内存增长控制。
- 为什么不用 lock‑free 栈而用 MPSC 队列？
- 如何解决 ABA？请具体写出 tagged pointer 的实现。
- 如果消费者线程 crash，如何保证日志不丢失？
- 内存序从 seq_cst 改为 acquire/release 后性能提升了多少？你们做过 benchmark 吗？
- 无锁设计如何做测试和验证正确性？（是否用了 ThreadSanitizer / 模型检查？）
“在我们的高并发日志系统中，选择无锁 MPSC 队列是因为写端是唯一的热点，读端只有单个消费者线程。通过 tagged pointer 解决了 ABA 问题：每个指针关联一个 16-bit 的版本号，CAS 同时比较指针和版本，避免误删。内存序上我们使用 release‑acquire 而不是 strict ordering，压测显示性能提升约 40%。同时我们使用了预分配循环节点池来避免动态内存分配导致的颠簸。如果您遇到类似的单消费者场景，可以优先考虑无锁 MPSC 而不是 mutex 版本。”