C++ 内存模型与原子操作 / The C++ Memory Model and Atomics

1. 为什么需要抽象内存模型

编译器、CPU 和缓存都可在不改变单线程可观察结果的前提下重排。多线程不能用“源代码上一行在前”推断跨线程可见性，必须用标准定义的关系。

Thread A                           Thread B
payload = 42;                      if (ready) use(payload);
ready = true;

没有同步：两个普通线程冲突访问 ready -> data race -> UB

2. 三个顺序关系

• sequenced-before：单线程内的求值顺序；
• synchronizes-with：如 mutex 解锁到后续成功加锁、release 写到读到其值的 acquire 读；
• happens-before：由 sequenced-before、synchronizes-with 及传递闭包建立。

Thread A                            Thread B
payload = 42
   | sequenced-before
ready.store(true, release) --synchronizes-with--> load(acquire)==true
                                                       |
                                                use(payload)

payload 写 happens-before payload 读，因此安全可见

3. Data race 的精确定义

两个潜在并发访问指向同一内存位置，至少一个修改，且二者不是原子访问、也没有 happens-before，则产生 data race 和 UB。UB 允许编译器作激进假设，不只是“偶尔读到旧值”。

不同元素通常是不同内存位置，但 vector<bool> 的位压缩可能让不同逻辑元素共享底层存储。对象生命周期开始/结束本身也可能与访问冲突。

4. Atomic 保证什么

对同一 atomic 对象，所有修改形成单一 modification order。原子读写不会撕裂，并按指定内存序参与同步。

std::atomic<int> counter{0};
counter.fetch_add(1, std::memory_order_relaxed);

这保证计数更新不丢失，却不自动保护旁边的 vector 或多个字段不变量。复合“先检查再更新”通常需要 CAS 循环或 mutex。

5. 六种内存序

内存序	核心语义	常见用途
relaxed	仅原子性和 modification order	独立统计计数
acquire	后续访问不能越过，读取发布数据	消费端
release	之前访问不能越过，发布数据	生产端
acq_rel	对 RMW 同时 acquire/release	状态转换
seq_cst	以上约束加单一全局 SC 顺序	默认、易推理
consume	标准语义长期难以实现，实践常按 acquire	不建议手写依赖

“relaxed 最快”不是通用事实，成本依架构和操作而变。先用 mutex 或 seq_cst 得到正确版本，再以 profile 和形式化推理决定是否降低。

6. Release/Acquire 发布

std::atomic<bool> ready{false};
std::string payload;

// producer
payload = "mesh";
ready.store(true, std::memory_order_release);

// consumer
if (ready.load(std::memory_order_acquire)) {
    consume(payload);
}

acquire 必须读到 release 写入的值或相应 release sequence 才建立同步。只是在同一程序里各写一个 release/acquire 并不会自动配对。

7. CAS 循环

int expected = state.load();
while (!state.compare_exchange_weak(
           expected, desired(expected),
           std::memory_order_acq_rel,
           std::memory_order_acquire)) {
    // 失败时 expected 已更新为实际值
}

compare_exchange_weak 允许伪失败，适合循环；strong 不伪失败但仍会因值变化失败。失败内存序不能包含 release，也不能强于成功序。循环体必须基于更新后的 expected 重新计算 desired。

8. ABA 问题

T1 读取 head = A
T2: A -> B -> A（地址/值又变回 A）
T1 CAS 看到仍是 A，误以为期间未变化

CAS 只比较当前位模式，不记录历史。可用版本标签、不可复用节点、hazard pointer 或 epoch 回收等方案。ABA 往往与“节点过早回收和地址复用”绑定出现。

9. atomic<T> 与 lock-free

is_lock_free() 可在运行时查询，is_always_lock_free 是 C++17 常量。某类型的 atomic 可以内部使用锁；“使用 atomic”不等于硬件无锁。

只有 trivially copyable 等满足要求的类型可用于通用 atomic<T>。atomic<shared_ptr<T>> 是 C++20 专门支持；早期标准提供自由函数接口。控制块安全不代表 T 的成员访问安全。

10. Fence 与何时不用

atomic_thread_fence 可把普通访问与原子操作组合成同步协议，但推理比直接在原子读写上写 acquire/release 更困难。没有配套原子观察关系的 fence 不是“刷新所有缓存”按钮。

业务代码优先使用锁、条件变量、channel 或成熟并发容器。只有协议可书面证明且性能数据支持时才手写 fence/无锁结构。

11. atomic::wait/notify（C++20）

std::atomic<int> state{0};

state.wait(0);  // 值仍为 0 时阻塞；返回后仍应重新验证业务条件
state.store(1, std::memory_order_release);
state.notify_all();

它可避免简单状态的忙等，但对象生命周期、内存序、状态机和关闭协议仍需设计。通知不是业务状态本身。

12. 面试速答

问：volatile 能否解决线程同步？

不能。它不保证原子性，也不建立 happens-before，主要用于特殊 I/O/优化可见性语义。

问：relaxed atomic 有什么保证？

保证该原子操作不可撕裂并参与该对象 modification order，不发布其他普通内存。

问：seq_cst 是否绝对比 acquire/release 慢？

不能绝对化，取决于架构与操作；它主要提供更强、更易推理的全局顺序。

13. 自测题与答案

1. 为什么原子计数器不能保护相邻普通对象？
2. acquire/release 在什么条件下真正配对？
3. weak CAS 失败后 expected 发生什么？
4. ABA 为什么不能只靠再读一次值解决？

<details> <summary>参考答案</summary>

1. atomic 只直接同步自身；其他数据需通过明确发布协议或锁建立顺序。
2. acquire 读到 release 写入的值或相应 release sequence。
3. 被更新为原子对象当前实际值，循环应据此重算。
4. 值可能变走又变回，当前快照无法证明历史未改变。

</details>

返回并发路线

14. 编译器与 CPU 为什么都能重排

单线程只需保持 as-if 可观察结果，编译器和处理器可重排独立操作；多线程若没有同步，另一个线程的观察不能靠源码顺序推断。

source: data=42; ready=true;
observer: if(ready) read data

没有同步：编译器/硬件可见顺序与缓存传播不足以形成语言保证

C++ memory order 约束原子操作以及周围普通访问的跨线程可见关系。

15. 三种关系如何组成 happens-before

sequenced-before：同一线程内的求值顺序
synchronizes-with：如 release store 被 acquire load 读到
happens-before：由上述关系传递闭包形成

若写入 happens-before 读取，读取才能安全观察普通数据。没有 happens-before 的冲突非原子访问构成 data race。

16. release/acquire 发布对象

// producer
payload.value = 42;
ready.store(true, std::memory_order_release);

// consumer
if (ready.load(std::memory_order_acquire)) {
    use(payload.value);
}

write payload
 sequenced-before
release ready=true
 synchronizes-with（acquire 读到该发布序列）
acquire sees true
 sequenced-before
read payload

acquire 必须读到相应 release 发布的值/序列。仅在同一原子上各写一次 acquire/release 关键字，并不自动同步任意线程。

17. relaxed 只保留原子性与修改顺序

适合统计计数等不发布其他数据的场景：

requests.fetch_add(1, std::memory_order_relaxed);

操作不会撕裂，且该原子有单一 modification order；但它不给周围普通变量建立跨线程顺序。用 relaxed 实现引用计数也常需要在最后释放路径配合更强同步，不能只记“计数可 relaxed”。

18. CAS 循环为何要更新 expected

compare_exchange_weak(expected, desired) 失败会把 observed 值写回 expected；weak 还允许伪失败，因此通常放循环：

auto old = counter.load();
do {
    if (old == limit) return false;
} while (!counter.compare_exchange_weak(old, old + 1));

每次失败都基于最新 old 重算 desired。成功/失败内存序有约束，失败序不能包含释放语义。

19. ABA 不是“值没变”，而是历史被抹掉

T1 reads head=A
T2 changes A->B, removes A, later head=A again
T1 CAS expects A succeeds, but structure generation changed

版本标签、hazard pointer、epoch reclamation 或不复用节点等方案需要同时解决身份与内存回收。仅把指针改 atomic 不能阻止节点释放后访问。

20. seq_cst 提供什么

顺序一致原子除 acquire/release 类效果外，还参与一个所有 seq_cst 操作的全局单一顺序，便于推理但可能限制优化/产生平台成本。默认 seq_cst 是合理正确性起点；只有 profile 与形式化证明支持时再放宽。

21. lock-free 查询不代表无等待

atomic<T>::is_lock_free 说明特定原子实现是否以 lock-free 方式提供，但 lock-free 只保证系统整体推进，单线程仍可能长期重试。类型是否 always lock-free 也受平台与 ABI 影响。

22. 内存序证明模板

1. 列出共享变量和访问线程；
2. 标记哪些访问冲突；
3. 选择承载同步的原子或锁；
4. 画 sequenced-before 与 synchronizes-with；
5. 证明所有普通冲突访问有 happens-before；
6. 审查对象回收、失败 CAS 和关闭路径；
7. TSan/压力测试只能补证，不能替代理论证明。

23. 连续追问与自测

问：volatile 能否做线程同步？ 答：不能；它不提供原子性和 happens-before，主要用于特定设备/可观察访问语义。

问：atomic 是否消除所有 race condition？ 答：只消除该操作的数据竞争，检查后行动等逻辑竞态仍可能存在。

1. release/acquire 同步的关键？ 答：acquire 读取到相应 release 发布的值/序列。
2. relaxed 保证什么？ 答：该原子操作的原子性与 modification order，不排序周围普通访问。
3. ABA 与回收关系？ 答：节点地址被复用会让相同位值掩盖对象身份/代次变化。

9. 真实问题：标志位已经变了，数据却还是旧的

生产线程先写 payload，再写 ready。 消费线程看到 ready 后读取 payload。 如果两个字段都是普通变量，编译器和 CPU 都可能让消费线程看到不一致状态。 这不是缓存“偶尔没刷新”这么简单。 两个线程对同一对象的冲突访问没有同步时，程序已经进入未定义行为。 未定义行为允许编译器删除看似不可能的分支。 调试构建能工作不代表发布构建正确。 解决方案是定义发布和获取关系。 发布者用 release 操作发布数据。 观察者用 acquire 操作获取数据。 只有读取到对应发布值时，前面的普通写入才被同步。

10. 最小实验：release/acquire 发布

int payload = 0;
std::atomic<bool> ready = false;

void producer() {
    payload = 42;
    ready.store(true, std::memory_order_release);
}

void consumer() {
    while (!ready.load(std::memory_order_acquire)) {}
    assert(payload == 42);
}

把 acquire 改为 relaxed 后，代码不再建立 payload 的可见性保证。 把 payload 改为原子并不自动表达业务顺序。 如果消费者只读一个计数，而没有读取发布值，仍需检查协议。 实验应在优化构建和多核机器上运行。 不要用一次成功输出作为证明。 使用 ThreadSanitizer 检查普通变量访问是否有数据竞争。 工具报告的是执行路径上的竞争，不是所有逻辑错误。

11. 正式规则：happens-before

sequenced-before 描述同一线程内的求值顺序。 同步操作可以把一个线程的事件连接到另一个线程。 happens-before 是可传递关系。 如果冲突访问之间没有 happens-before，且至少一个是写入，就形成 data race。 data race 的程序行为是未定义的。 原子对象的修改有单独的 modification order。 每个原子对象都有一致的修改序列，但不同原子对象之间未必有全局顺序。 seq_cst 在此基础上提供更强的单一总顺序。 强内存序不能修复错误的状态机。 需要先画出状态和所有权，再选择最弱足够内存序。

12. CAS 与失败语义

compare_exchange 读取当前值并尝试替换期望值。 失败时会把实际值写回 expected。 循环重试前必须重新计算基于新值的更新。 不能把 expected 当作永远不变的输入。 弱 CAS 允许伪失败，适合循环。 强 CAS 减少伪失败，但不保证无竞争时一次成功。 成功和失败可以使用不同内存序。 失败序不能是 release 或 acq_rel。 指针 CAS 只解决指针值原子替换，不解决节点回收。 删除节点后立即释放可能让另一个线程解引用悬空指针。 hazard pointer、epoch 或共享所有权负责回收边界。

13. 工程实践：原子变量的审查表

说明每个原子字段代表的状态，而不是只写“线程安全”。 记录写入者、读取者和允许的状态转换。 为 release/acquire 配对写注释。 对 relaxed 说明为什么不需要跨变量顺序。 避免一个原子计数器暗中代表多个非原子字段。 不要用 volatile 代替同步。 避免依赖原子对象的锁实现细节。 检查 is_lock_free() 结果是否符合目标平台要求。 跨进程共享原子还涉及映射、ABI 和硬件一致性条件。 优先使用 mutex 表达复杂不变量。 只有测量证明锁是瓶颈时才考虑无锁结构。

14. 失败场景复盘

失败一：relaxed 标志配普通 payload，线上读取旧值。 修复：建立 release/acquire 发布协议。 失败二：CAS 成功后释放节点，读者仍在访问。 修复：加入安全回收方案。 失败三：用 fetch_add 计数推断任务完成顺序。 修复：分离计数与完成发布状态。 失败四：错误地把 atomic<bool> 当条件变量。 修复：原子等待或 condition_variable 配合谓词。 失败五：seq_cst 让延迟暴涨却没有解决丢更新。 修复：审查线性化点和状态转换。 失败六：测试只在单核机器通过。 修复：在不同架构和优化级别下运行压力测试。

15. 自测题

问：原子变量是否自动让关联普通字段安全？ 答：只有建立正确同步关系时才安全。 问：relaxed 读能否观察到 release 写？ 答：可以读到值，但不提供该 release 之前普通写的可见性排序。 问：CAS 失败后 expected 为什么变化？ 答：库把实际原子值返回，便于下一轮基于最新值重算。 问：volatile 适合什么？ 答：设备寄存器或特定可观察访问，不是线程同步原语。 问：TSan 没有报告是否等于逻辑正确？ 答：不等于，未覆盖路径和原子逻辑竞态仍可能存在。

工程深化：把本篇知识落到项目里

这一节不是为了凑篇幅，而是把《C++ 内存模型与原子操作 / The C++ Memory Model and Atomics》从“知道概念”推进到“能在项目里稳定使用”。 阅读时可以把每个知识点都追问成四件事：它保护什么边界，失败时有什么现象，怎样最小复现，怎样写进团队流程。

concept -> boundary -> failure signal -> minimal proof -> project rule

工程切片 1：最小可复现样例

**场景。**围绕 原子读写 建一个很小的案例，不要一开始就放进完整业务系统。把问题压缩到一个可以提交给同事的目录，保留源码、构建命令、版本输出和预期现象。

**边界。**先判断这里讨论的是 原子读写、happens-before 还是 可见性 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 原子读写 -> happens-before -> 可见性 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 2：接口边界

**场景。**围绕 happens-before 建一个很小的案例，不要一开始就放进完整业务系统。写清调用方能依赖什么、不能依赖什么，并把隐式假设转换成命名函数、配置项或测试。

**边界。**先判断这里讨论的是 happens-before、可见性 还是 重排 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> happens-before -> 可见性 -> 重排 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 3：失败注入

**场景。**围绕 可见性 建一个很小的案例，不要一开始就放进完整业务系统。故意制造一个常见错误，让日志、断言或测试先失败，再用修复后的证据说明规则生效。

**边界。**先判断这里讨论的是 可见性、重排 还是 数据竞争 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 可见性 -> 重排 -> 数据竞争 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 4：跨平台差异

**场景。**围绕 重排 建一个很小的案例，不要一开始就放进完整业务系统。至少比较 Windows、Linux 或不同编译器下的一个差异，记录差异属于标准、实现还是平台约定。

**边界。**先判断这里讨论的是 重排、数据竞争 还是 TSAN 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 重排 -> 数据竞争 -> TSAN -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 5：性能观察

**场景。**围绕 数据竞争 建一个很小的案例，不要一开始就放进完整业务系统。用小规模和压力规模各跑一次，区分算法成本、同步成本、I/O 成本和工具链配置成本。

**边界。**先判断这里讨论的是 数据竞争、TSAN 还是 原子读写 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 数据竞争 -> TSAN -> 原子读写 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 6：生命周期

**场景。**围绕 TSAN 建一个很小的案例，不要一开始就放进完整业务系统。标出资源创建、转移、共享、停止和销毁的顺序，特别关注错误返回和提前退出路径。

**边界。**先判断这里讨论的是 TSAN、原子读写 还是 happens-before 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> TSAN -> 原子读写 -> happens-before -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 7：诊断证据

**场景。**围绕 原子读写 建一个很小的案例，不要一开始就放进完整业务系统。保留命令、日志、符号、栈、测试输出或截图，让结论可以被另一个环境重新验证。

**边界。**先判断这里讨论的是 原子读写、happens-before 还是 可见性 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 原子读写 -> happens-before -> 可见性 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 8：维护策略

**场景。**围绕 happens-before 建一个很小的案例，不要一开始就放进完整业务系统。把一次性经验沉淀到 README、CI、脚本、示例工程或检查表里，避免只存在个人记忆中。

**边界。**先判断这里讨论的是 happens-before、可见性 还是 重排 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> happens-before -> 可见性 -> 重排 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 9：版本演进

**场景。**围绕 可见性 建一个很小的案例，不要一开始就放进完整业务系统。为未来变更预留兼容策略：版本号、特性位、弃用窗口、迁移脚本和回滚入口。

**边界。**先判断这里讨论的是 可见性、重排 还是 数据竞争 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 可见性 -> 重排 -> 数据竞争 -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

工程切片 10：最小消费者

**场景。**围绕 重排 建一个很小的案例，不要一开始就放进完整业务系统。从使用者角度写一个小程序或小工程，只依赖公开接口，验证安装包、头文件和运行时行为。

**边界。**先判断这里讨论的是 重排、数据竞争 还是 TSAN 的责任；如果三者混在一起，先把输入、输出和所有权拆开。

input -> 重排 -> 数据竞争 -> TSAN -> observable result

**验证。**记录一条能重复运行的命令或测试，并写明成功输出和失败输出。只说“本机能跑”不够，至少要记录工具版本、构建类型和关键参数。

**常见错误。**把偶然通过当成规则、把私有实现当成公开契约、或者让错误路径绕开清理逻辑，都会让本篇主题在真实项目里变得不可维护。

**复盘问题。**如果明天换一个编译器、Qt 版本、插件版本、输入规模或发布目录，这个结论是否仍成立？不成立时，应该由文档、测试还是 CI 给出提示？

本篇收束

掌握《C++ 内存模型与原子操作 / The C++ Memory Model and Atomics》的标志，不是记住所有名词，而是能把 原子读写、happens-before、可见性、重排、数据竞争、TSAN 放进一条可验证的工程链路。 先用最小样例建立判断，再用测试和脚本固定判断，最后把失败证据留给未来的自己和团队。