std::atomic_thread_fence不能替代硬件屏障，但可约束编译器和CPU的内存访问重排；它不读写变量，仅起顺序约束作用，需配合原子操作或volatile访问才能生效。
什么是 std::atomic_thread_fence，它能替代硬件屏障吗
它不能替代硬件屏障，但能告诉编译器和 CPU：此处的内存访问顺序不可重排。C++ 标准不直接暴露 CPU 的 lfence/sfence/mfence 指令，而是通过抽象的内存序（memory_order）让编译器生成等效屏障指令或插入编译器屏障（asm volatile("" ::: "memory"）。
常见误用是以为 std::atomic_thread_fence 本身“执行”了同步——它不读写任何变量，只起约束作用；真正起效依赖它两侧的原子操作或 volatile 访问。
-
std::memory_order_acquire在读操作前加 acquire 栅栏，禁止后续读/写上移 -
std::memory_order_release在写操作后加 release 栅栏，禁止前面读/写下移 -
std::memory_order_seq_cst默认最严格，隐含 acquire + release + 全局顺序保证
为什么只用 volatile 无法实现跨核可见性
volatile 只禁用编译器优化，不阻止 CPU 指令重排，也不触发 cache coherency 协议（如 MESI）。两个线程在不同核心上修改同一 volatile int，仍可能各自缓存旧值，且无同步点通知对方刷新。
典型错误场景：
立即学习“C++免费学习笔记（深入）”；
volatile bool ready = false;
int data = 0;
// 线程 A
data = 42; // 编译器可能把这行移到 ready=true 后面
ready = true; // 无 memory_order_release → 不保证 data 对线程 B 可见
// 线程 B
while (!ready) {} // volatile 读，但无 acquire 语义
printf("%d\n", data); // 可能打印 0
修复方式必须引入原子操作或显式栅栏：
- 把
ready改为std::atomic<bool></bool>，写用.store(true, std::memory_order_release) - 读用
.load(std::memory_order_acquire)，此时data的读就一定能看到线程 A 的写
std::atomic_thread_fence 和原子操作的 fence 参数有何区别
二者语义等价，但适用位置不同：std::atomic_thread_fence 是独立语句，作用于当前线程所有内存访问；而原子操作的 memory_order 参数只约束该操作本身的前后访存顺序。
例如下面两段代码效果相同：
// 方式一：显式 fence flag.store(true, std::memory_order_relaxed); std::atomic_thread_fence(std::memory_order_release); // 此后所有读写都不能被重排到 fence 前
// 方式二：原子操作自带 order flag.store(true, std::memory_order_release); // store 本身已含 release 语义，等效于上面两行
实际中优先用方式二——更紧凑、不易漏掉 fence 调用；仅当需要对非原子变量施加顺序约束时，才用 std::atomic_thread_fence。
- 对非原子变量
data的写，需配合std::atomic_thread_fence(std::memory_order_release)才能确保其对其他线程可见 - 若混用原子与非原子访问，且未配对使用 acquire/release，行为未定义
在 x86-64 上哪些 memory_order 不生成实际 CPU 指令
x86-64 的强内存模型天然满足 acquire 和 release 语义，所以 std::memory_order_acquire / std::memory_order_release / std::memory_order_acq_rel 编译后通常只产生编译器屏障（asm volatile("" ::: "memory")），不插 mfence 等指令。
但 std::memory_order_seq_cst 例外：对 store 操作会生成 mov + mfence（或 xchg），因为要保证全局顺序。
- 这意味着在 x86 上用
acquire/release性能开销极小，但别因此误以为它们“没用”——在 ARM/AArch64 上会生成ldar/stlr或dmb ish - 跨平台代码必须按语义选 memory_order，不能依赖 x86 的宽松表现
真正容易被忽略的是：即使硬件不生成指令，编译器重排仍会发生。哪怕在 x86 上，没有 memory_order 约束的 relaxed 原子操作，也可能导致逻辑错乱。
