什么是内存屏障及 atomic 原子操作-Golang-PHP中文网

内存屏障解决乱序执行导致的可见性问题，atomic保障单操作不可分割；二者需配合使用，单独滥用或漏用会引发隐蔽并发bug。

什么是内存屏障及 atomic 原子操作

内存屏障不是“让所有操作变慢”的锁，atomic 也不是“自动线程安全”的银弹。它们各自解决不同层面的问题：内存屏障管的是「顺序可见性」，atomic 管的是「单个操作的不可分割性」；两者常配合使用，但混用或漏用都会导致隐蔽的并发 bug。

现代 CPU 和编译器会重排指令以提升性能，比如把后面一个不依赖前面结果的读操作提前执行。这在单线程下完全正确，但在多线程中可能让另一个线程看到“写了一半”的状态。

典型现象是：线程 A 写了 flag = true 和 data = 42，但线程 B 先看到 flag == true 却读到 data == 0——因为编译器/CPU 把 flag 的写入重排到了 data 之前。

内存屏障强制约束「屏障前的所有内存操作必须对其他核可见后，屏障后的操作才可开始」
x86 上最常用的是 mfence（全屏障），但多数场景只需 lfence（读屏障）或 sfence（写屏障）
内核或用户态代码中直接写汇编调用屏障指令极少见，更常见的是通过语言抽象（如 C++ 的 std::atomic_thread_fence）间接插入
注意：mfence 在 x86 上开销显著高于 lock addl $0, (%rsp) 这类轻量写屏障，后者被 Linux 内核大量用于 release 语义

std::atomic<int></int> 的 store() 或 load() 是原子的，意味着不会出现「只写了低 16 位就被打断」这种撕裂（tearing）；但它不保证多个原子操作组合起来仍安全。

常见误用：用两个 fetch_add 实现「先加再判断是否超限」，中间仍可能被其他线程插足——这需要 CAS 循环或更高层同步。

atomic 的真正价值在于它绑定了内存序（memory order）参数，例如 memory_order_relaxed 不插入任何屏障，memory_order_acquire 在 load 后隐含读屏障
默认的 memory_order_seq_cst 最严格，但性能代价最高；x86 上它等价于带 mfence 的操作，ARM/AArch64 则需显式屏障
对 bool 标志位用 atomic<bool></bool> + memory_order_release / acquire，比自旋锁轻量得多，也比裸变量 + 手动 mfence 更可移植

当你要同步的不是 atomic 对象本身，而是它背后的非原子数据时，仅靠 atomic 操作不够——比如用 atomic flag 控制一段普通数组的访问。

错误写法：ready_flag.store(true, memory_order_relaxed) 后直接写 buffer[i] = x；此时 buffer 的写入可能仍未刷出到 cache，其他核看到 flag 已置位却读到旧 buffer 数据。

正确做法：用 ready_flag.store(true, memory_order_release)，并在另一端用 ready_flag.load(memory_order_acquire) ——这会在语义上建立 happens-before 关系，编译器和 CPU 会自动插入必要屏障
若无法改用 atomic flag（比如 legacy code 中只有 volatile int），就得手动调用 std::atomic_thread_fence(std::memory_order_release) 配合普通写，但易出错且不可移植
Linux 内核中常见模式：smp_store_release(&ptr, val) + smp_load_acquire(&ptr)，底层展开为带 barrier 的汇编，比通用 mfence 更精准

最容易被忽略的一点：内存屏障的效果依赖于配对使用。单边加 acquire 而另一边是 relaxed load，屏障就形同虚设；atomic 的内存序参数一旦选错，调试时几乎无法通过日志或断点复现——它只在特定核间调度时机下才暴露问题。