std::memory_order选错会直接导致数据竞争，它不是性能开关而是安全边界；必须按同步需求配对使用acquire/release，relaxed仅用于无依赖场景，seq_cst最安全但最慢。
std::memory_order 选错会直接导致数据竞争
无锁代码里，std::memory_order 不是性能调优开关，而是安全边界。选错顺序——比如该用 std::memory_order_acquire 却用了 std::memory_order_relaxed——编译器和 CPU 都可能重排指令，让本该看到的写入“看不见”，结果就是读到脏值、状态不一致、偶发崩溃。
- 只在确认无依赖关系时才用
std::memory_order_relaxed（如计数器累加，且不靠它同步其他变量） -
std::memory_order_acquire必须配对std::memory_order_release：前者读 flag，后者写 flag，才能保证 flag 之后的读写不被重排到 flag 操作之前/之后 -
std::memory_order_seq_cst最安全但最慢，x86 上隐含全屏障，ARM/AArch64 上要插额外指令；别默认选它，除非你真需要全局顺序一致性
load/store 分开指定 memory_order 容易漏掉配对
原子操作分 load、store、read-modify-write 三类，每类可独立设 memory_order。常见错误是只改了 store 的序，忘了 load 端也要匹配——比如用 flag.store(true, std::memory_order_release) 发信号，但接收方却用 flag.load(std::memory_order_relaxed)，那 signal 后的内存操作就可能被乱序执行。
- release-store 必须搭配 acquire-load 才能建立 happens-before 关系
- acquire-load 不能和 relaxed-store 配对；relaxed-store + relaxed-load = 无同步语义
- 像
fetch_add这类 RMW 操作，若没显式指定 order，默认是std::memory_order_seq_cst，容易误以为轻量
std::atomic_thread_fence 的作用常被高估
std::atomic_thread_fence 是全局屏障，但它不绑定任何原子变量，仅约束当前线程的内存访问顺序。很多人想用它替代 acquire/release 配对，结果发现没用——fence 本身不参与跨线程同步，必须配合原子操作的语义才能生效。
- 单用
std::atomic_thread_fence(std::memory_order_acquire)不会等待其他线程的写入，它只阻止本线程后续读写越过这个点 - 真正起同步作用的是原子变量上的 acquire/release，fence 只是补丁，比如在非原子变量访问前后加 fence 来约束顺序
- 在 x86 上
memory_order_acquire和memory_order_release几乎零开销，而std::atomic_thread_fence即使是std::memory_order_acquire也可能触发 mfence（尤其在旧 CPU 上）
调试时怎么验证 memory_order 是否生效
编译器不会报错，CPU 也不会抛异常，问题只在特定调度下暴露。最直接的办法是看生成的汇编：relaxed 操作通常编译为普通 mov 或 ldr，acquire/load 应带 ldar（ARM）或 mov+lfence（x86），release/store 应带 stlr 或 sfence。更可靠的是用 ThreadSanitizer：
立即学习“C++免费学习笔记（深入）”；
clang++ -O2 -fsanitize=thread -g lockfree.cpp -lpthread
TSan 能捕获未配对的 acquire/release、relaxed 访问共享非原子变量等典型错误。注意：它无法检测纯重排逻辑错误（比如顺序理解反了），只能抓数据竞争。
真正难的不是记住六种枚举值，而是每次写原子操作时，都得问一句：这个操作要同步哪些内存、依赖哪些前序写入、是否需对其他线程可见——答案决定了 order，而不是反过来。
