内存屏障解决多线程中因编译器/cpu重排序导致的非原子变量可见性与顺序问题；memory_order_release确保其前所有内存访问不被重排到其后，memory_order_acquire确保其后所有内存访问不被重排到其前，二者配对建立happens-before关系。
内存屏障解决什么问题？
在多线程 C++ 程序中，std::atomic 变量的读写本身不保证其他非原子变量的可见顺序。编译器和 CPU 都可能对指令做重排序——比如把某个非原子变量的赋值提前到原子操作之前，或延后到之后。这会导致其他线程看到“逻辑上不可能”的状态，比如看到指针已更新但指向的对象尚未初始化完毕。
memory_order_acquire 和 memory_order_release 怎么用？
它们是隐式带内存屏障的原子操作语义，比手动插入 std::atomic_thread_fence 更常用、更安全。
-
memory_order_release用于写操作：确保该原子写之前的**所有内存访问**（包括非原子读写）不会被重排到它之后 -
memory_order_acquire用于读操作：确保该原子读之后的**所有内存访问**不会被重排到它之前 - 二者配对使用才能建立同步关系（happens-before），单用没意义
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)) { } // 获取操作
std::cout << data << "\n"; // 此时一定能读到 42
什么时候必须用 std::atomic_thread_fence？
当需要在**没有原子读写参与的位置**插入屏障，或者需要跨多个原子操作统一约束顺序时。例如：两个独立的原子变量之间建立顺序，或配合 relaxed 原子操作做精细控制。
-
std::atomic_thread_fence(std::memory_order_acquire)等价于 acquire 读的屏障部分，但不读任何值 -
std::atomic_thread_fence(std::memory_order_release)等价于 release 写的屏障部分，但不写任何值 - 注意：fence 不作用于任何特定原子对象，影响的是当前线程所有内存访问
std::atomic<int> flag{0};
int payload = 0;
// 线程 A
payload = 100;
std::atomic_thread_fence(std::memory_order_release);
flag.store(1, std::memory_order_relaxed);
// 线程 B
while (flag.load(std::memory_order_relaxed) == 0) { }
std::atomic_thread_fence(std::memory_order_acquire);
std::cout << payload << "\n"; // 能正确读到 100
容易忽略的关键点
内存屏障只约束**本线程内指令的重排序可见性**，不保证缓存一致性自动传播；它也不代替互斥锁——如果存在数据竞争（如两个线程同时写同一非原子变量），加屏障也解决不了未定义行为。
立即学习“C++免费学习笔记（深入）”；
- 仅靠
memory_order_relaxed的原子操作，无法建立线程间同步 - x86/x64 上
acquire/release几乎不生成额外指令（靠 CPU 内存模型保证），但 ARM/AArch64 必须插入dmb指令 - 过度使用
memory_order_seq_cst（默认）会显著影响性能，尤其在弱序架构上
真正难的不是插哪条 fence，而是准确识别哪些变量需要同步、哪些访问必须按序——这取决于你设计的同步协议，而不是语法本身。
