23. 内存模型与 happens-before：C++ 并发编程的基石

说实话，很多 C++ 开发者写并发代码时，心里是发虚的。你可能会想：「我加了锁，应该没问题了吧？」或者「这个 atomic 变量我用了，肯定线程安全。」嗯，我以前也这么觉得。直到有一次，我在一个高并发服务里遇到了一个极其诡异的 bug——数据明明被写入了，另一个线程读到的却是旧值，而且不是每次都错，是偶尔错。那段时间我差点把头发薅光。

后来我才明白，光靠直觉写并发代码是不够的。你得理解 C++ 内存模型，理解 happens-before 关系。说白了，这是并发编程的「交通规则」。不懂规则，你就是在马路上闭着眼睛开车。

23.1 C++ 内存模型的核心规则

C++11 开始，标准引入了正式的内存模型。它的核心目标就一个：定义清楚线程之间如何共享数据。为什么需要这个？因为现代 CPU 和编译器太「聪明」了。

你想想看，CPU 会乱序执行指令，编译器会重排代码，缓存也会让数据暂时不同步。这些优化在单线程下完全没问题，但在多线程下，它们会搞出大乱子。

C++ 内存模型把内存访问分为几种类型：

  • 普通内存访问：没有原子性保证，也没有顺序保证
  • 原子操作：有原子性保证，但顺序保证取决于你选的 memory_order
  • 互斥锁：提供临界区内的完全顺序保证

我个人习惯把内存模型想象成一个「契约」：你告诉编译器「这里我需要什么级别的保证」，编译器就按这个级别来优化。你给的保证越强，优化空间越小，但代码越安全。

核心要点：C++ 内存模型定义了两种基本保证——原子性（操作要么完全执行，要么完全不执行）和顺序性（操作在另一个线程看来是什么顺序）。

23.2 happens-before 关系的建立

happens-before 是理解并发正确性的关键。它的定义很简单：如果操作 A happens-before 操作 B，那么 A 的结果对 B 是可见的，而且 A 的顺序在 B 之前。

但注意，这不是时间上的先后，而是逻辑上的先后。两个线程各自执行自己的操作，如果没有 happens-before 关系，那它们之间就没有任何可见性保证。

happens-before 关系怎么建立？主要有这几种方式：

  1. 同一个线程内：按代码顺序，前面的操作 happens-before 后面的操作
  2. 互斥锁：解锁操作 happens-before 后续的加锁操作
  3. 原子操作：使用 memory_order_release 的写操作 happens-before 使用 memory_order_acquire 的读操作
  4. 线程创建与汇合：创建线程的操作 happens-before 新线程的所有操作；线程的所有操作 happens-before join 操作

举个例子，我项目中经常用 atomic 来做简单的同步：

std::atomic<bool> ready{false};
int data = 0;

// 线程 A
data = 42;                    // 普通写
ready.store(true, std::memory_order_release);  // 释放语义

// 线程 B
while (!ready.load(std::memory_order_acquire));  // 获取语义
// 此时 data 一定是 42
assert(data == 42);

为什么会这样？因为 release 操作与 acquire 操作建立了 happens-before 关系。线程 A 中 data 的写入 happens-before release 操作，release 操作 happens-before acquire 操作，acquire 操作 happens-before 线程 B 读取 data。所以 data 的写入对线程 B 可见。

我的经验：我在项目中遇到过有人把 memory_order 全写成 memory_order_relaxed，结果数据竞争问题排查了整整两天。记住，relaxed 只保证原子性，不保证任何顺序。除非你非常清楚自己在做什么，否则别用 relaxed。

23.3 数据竞争的定义与检测

数据竞争是并发编程的头号敌人。它的定义其实很明确：两个或多个线程同时访问同一内存位置，其中至少一个是写操作，而且这些访问之间没有 happens-before 关系。

注意，数据竞争是未定义行为。一旦出现数据竞争，你的程序可能在任何时候以任何方式崩溃。不是「可能出错」，而是「一定出错」，只是出错时机不确定。

我曾经在一个金融交易系统里遇到过数据竞争。两个线程同时更新一个计数器，一个加一，一个减一。理论上最终结果应该不变，但实际跑起来，计数器偶尔会莫名其妙地跳变。嗯，这就是典型的数据竞争——两个操作之间没有 happens-before 关系，导致中间状态被看到了。

检测数据竞争的方法：

  • 静态分析：用 ThreadSanitizer（TSan）这样的工具。编译时加上 -fsanitize=thread，运行时就能检测到数据竞争
  • 动态分析：在测试阶段开启 TSan，跑各种并发场景
  • 代码审查：人工检查每个共享变量的访问是否都有同步保护

避坑指南：我曾经以为「只要用 volatile 就能解决并发问题」。这是错的。volatile 只告诉编译器不要优化这个变量，它不提供任何原子性或顺序保证。在 C++ 并发编程中，volatile 基本没用。要用 atomic 或者 mutex。

下面这张图展示了 happens-before 关系如何防止数据竞争：

happens-before 关系与数据竞争 线程 A 线程 B A1: data = 42 (写) A2: ready.store(release) B1: ready.load(acquire) B2: 读取 data (读) happens-before happens-before happens-before 无同步：数据竞争！ 无同步：数据竞争！ 同步操作 数据操作 数据竞争

图中展示了两种场景。上半部分：通过 release-acquire 建立了 happens-before 链，数据安全。下半部分：如果去掉同步操作，两个线程直接读写 data，就产生了数据竞争。

23.4 实际应用中的注意事项

讲到这里，我想分享几个实际项目中的经验：

  • 别过度设计：能用 mutex 的地方别用 atomic。mutex 虽然慢一点，但语义清晰，不容易出错。我见过有人为了性能把 mutex 改成 atomic，结果引入了一堆 bug。
  • 理解 memory_order：默认的 memory_order_seq_cst 是最安全的，但也是最慢的。如果你确实需要优化，先理解 acquire/release 语义，再考虑 relaxed。
  • 工具是你的朋友：TSan 和 AddressSanitizer 是并发编程的必备工具。每次跑测试都开启它们，能帮你省下大量调试时间。

我的习惯：写并发代码时，我会在注释里明确标注每个共享变量的同步方式。比如「// protected by mutex_」或者「// atomic with release-acquire」。这样半年后回来维护，自己还能看懂。

最后，记住一句话：没有 happens-before 关系的共享访问，就是数据竞争。数据竞争就是未定义行为。未定义行为就是灾难。 写并发代码时，时刻问自己：「这个访问有没有 happens-before 关系？」如果答案是否定的，停下来，加同步。

公众号：蓝海资料掘金营，微信 deep3321

← 上一章 📖 返回目录 下一章 →