结论：应使用 std::atomic 配合恰当 memory_order（如 release/acquire）实现跨线程同步，而非手写汇编；用错内存序等同于未同步，release+acquire 通过约束重排序建立 happens-before 关系，适用于单 flag 控制单 data 场景，多变量依赖或需全局顺序时才用 seq_cst。
直接说结论：靠 std::atomic 配合恰当的 memory_order，而不是手写汇编栅栏或依赖平台指令。用错内存序，和不用一样。
为什么 release + acquire 能堵住重排序漏洞
典型场景是“生产者-消费者”模式：一个线程写数据后设标志，另一个线程轮询标志再读数据。若无同步，编译器或 CPU 可能把写数据操作拖到设标志之后，或把读数据提前到检查标志之前。
用 ready.store(true, std::memory_order_release) 保证它前面所有内存写入（比如 data = 42）不会被重排到它后面；ready.load(std::memory_order_acquire) 保证它后面所有读写不会被重排到它前面。二者合起来构成“发布-获取”同步关系，跨线程建立 happens-before。
- 不能只用
memory_order_relaxed：它只保原子性，不约束顺序，重排序照常发生 - 不要在同一个原子变量上混用
acquire和release以外的语义来配对：比如用seq_cst写、acquire读，虽能工作但语义过强且可能掩盖设计意图 - x86 架构下
acquire/release实际不生成额外指令，但 ARM/AArch64 必须插入 dmb 指令——别因为 x86 看似“没效果”就误判其必要性
什么时候必须用 memory_order_seq_cst
当你需要多个原子变量之间也保持全局一致的执行顺序时。seq_cst 是唯一能保证“所有线程看到相同操作顺序”的选项，比如实现自定义锁、计数器广播、或者调试竞态问题时做保守兜底。
- 它隐式包含
acquire和release语义，但开销比二者组合略高（尤其在弱一致性架构上） - 如果只是单个 flag 控制单个 data，
acquire/release足够；但若涉及多个 flag 交叉依赖（如双检查锁定 DCLP），seq_cst更安全 -
std::atomic_flag的test_and_set()默认就是seq_cst，改用relaxed需显式传参，别漏掉
容易被忽略的陷阱：非原子变量 + 原子 flag 不等于自动同步
很多人以为只要用了 std::atomic<bool></bool> 就万事大吉，其实不然。关键点在于：只有被 acquire/release 保护的内存操作才被纳入同步范围。普通变量（如 int data）本身不带任何顺序约束。
- 必须确保写线程中，所有要“发布”的数据写入都发生在
store(release)之前；读线程中，所有要“消费”的读取都发生在load(acquire)之后 - 不能把
data声明为std::atomic<int></int>却仍用relaxed读写——那只是避免了数据竞争，但不解决顺序问题 - 编译器在
-O2或更高优化级别下会积极重排，Debug 版本不重排只是巧合，不能当依据
真正难的不是记住六种 memory_order，而是判断哪些读写必须被串在一起、哪些可以松动。多数 bug 来自“以为已同步”，实则同步范围漏了一行赋值或一个函数调用。每次加原子操作前，先问自己：这个变量的修改，需要被谁、在什么时机、以什么顺序看到？
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
