C++内存模型详解：理解顺序一致性与relaxed原子操作【并发底层原理】

顺序一致性（sequential consistency）是c++中最严格内存序：所有线程看到的原子操作全局顺序一致，且各线程内部顺序与程序顺序相同；它等价于所有原子操作排成单一时序线，但开销大、禁用优化，不能替代锁保护非原子数据。

什么是顺序一致性（sequential consistency）？

顺序一致性是 C++ 内存模型中最直观、最严格的执行语义：所有线程看到的原子操作全局顺序一致，且每个线程内部的操作顺序与程序顺序完全相同。它等价于“所有原子操作排成一条时间线，每条线程按自己代码顺序从中取操作执行”。

但要注意：std::memory_order_seq_cst 是默认选项，不代表它是零成本——它在 x86 上会插入 mfence（或隐式全屏障），在 ARM/AArch64 上开销更大；它保证强语义，也意味着放弃编译器和 CPU 的部分优化机会。

• 所有 seq_cst 读写自动构成一个全局唯一修改顺序
• 它能防止重排序：编译器不会把 seq_cst 操作与前后其他内存访问乱序（除非有明确 relaxed 操作介入）
• 它不能替代锁来保护非原子数据结构；比如两个 seq_cst 原子变量的读，并不保证它们之间对共享 int 的读是同步的

relaxed 原子操作适合什么场景？

std::memory_order_relaxed 只保证原子性（即读写不撕裂），不提供任何同步或顺序约束。它适用于计数器、引用计数、状态标志等“只要值正确、不关心谁先谁后”的场景。

典型误用是把它用于发布-订阅模式中的 flag：仅靠 relaxed 写 flag + relaxed 读 flag，无法确保之前写入的数据对读者可见。

立即学习“C++免费学习笔记（深入）”；

• 适用：单生产者单消费者队列的索引递增（如 tail.fetch_add(1, std::memory_order_relaxed)）
• 不适用：跨线程传递指针或初始化完成信号（必须搭配 acquire/release 或 seq_cst）
• ARM/AArch64 下，relaxed load/store 编译为普通 ldr/str，无额外指令；x86 下也几乎无开销

为什么 release-acquire 配对比 seq_cst 更轻量？

release store 和 acquire load 构成同步关系：前者之后的所有内存操作（包括非原子）不能重排到它之前，后者之前的所有内存操作不能重排到它之后。这种配对只约束两个线程间的因果链，不牵涉全局顺序。

关键点在于：多个 release store 可以对应一个 acquire load，反之亦然；但它们之间不构成全序，因此不触发全局屏障。

std::atomic data{0}; std::atomic ready{false};  // 线程 A data.store(42, std::memory_order_relaxed); ready.store(true, std::memory_order_release); // 保证 data.store 在此之前完成  // 线程 B while (!ready.load(std::memory_order_acquire)) { } // 保证后续能看见 data==42 std::cout << data.load(std::memory_order_relaxed) << "n";

• x86 上 release store 和 acquire load 都不生成额外指令（仅依赖 CPU 的 store-buffer 和 memory-ordering 规则）
• ARM/AArch64 上，release 编译为 stlr，acquire 编译为 ldar，比 seq_cst 的 stl+ldp 或带 dmb 的组合更高效
• 不能跨不同原子变量混用：用 release 写 A、acquire 读 B，无法建立同步

容易被忽略的编译器重排陷阱

即使用了正确的内存序，编译器仍可能在原子操作周围做优化——比如把非原子读提到 acquire load 之前，或把非原子写拖到 release store 之后。这不违反 C++ 标准，但会破坏逻辑正确性。

解决方法不是加 seq_cst，而是用 std::atomic_thread_fence 显式干预编译器行为（注意：fence 不影响 CPU 执行序，只限制编译器指令调度）。

• std::atomic_thread_fence(std::memory_order_acquire) 阻止编译器把其后的读/写移到 fence 前
• std::atomic_thread_fence(std::memory_order_release) 阻止编译器把其前的读/写移到 fence 后
• 不要在无必要时用 seq_cst fence：它在多数架构上等价于 full barrier，开销远高于 acquire/release fence

真正难调试的问题，往往出在“以为用了 acquire 就万事大吉”，却忽略了编译器对 nearby 非原子变量的重排。