重排无法彻底避免，但可通过明确 memory_order、合理使用 atomic_thread_fence 及 TSan 工具精准建序与检测；volatile 不能替代内存序。
不能“彻底避免”，但能用确定性手段封住所有重排路径——关键不是堵，而是建序。
std::atomic 的 memory_order 不是可选项，是必填项
很多人写 std::atomic<int> flag{0}</int>，然后只调用 flag.load() 和 flag.store(1)，以为默认的 std::memory_order_seq_cst 就万事大吉。其实这等于把所有线程都塞进同一根独木桥：性能掉得明显，而且掩盖了真正的问题边界。
真正要防重排，得明确每一对操作之间的同步意图：
- 如果只是想让一个线程的写对另一个线程“可见”，且不关心与其他变量的顺序，用
std::memory_order_relaxed+ 显式屏障（比如std::atomic_thread_fence）更轻量也更可控 - 如果写操作要“发布”一组非原子数据（比如初始化完结构体再设标志），必须配对使用
store(std::memory_order_release)和load(std::memory_order_acquire) - 如果两个线程通过不同原子变量协同（如生产者改
head、消费者读tail），单靠seq_cst无法保证跨变量顺序，必须用acquire-release构建同步点
volatile 不能替代 memory_order
有人在共享变量前加 volatile，以为能阻止编译器重排。这是严重误解：volatile 只禁止编译器对该变量的读写优化，完全不管 CPU 乱序执行，也不提供任何跨线程可见性保证。
立即学习“C++免费学习笔记（深入）”；
典型错误现象：
- 线程 A 写
volatile int ready = 1之前，先写了普通变量data = 42，但线程 B 读到ready == 1后，仍可能看到data是旧值（因为 CPU 可能先刷ready，后刷data） - 在 ARM64 或 RISC-V 上，
volatile甚至不生成任何内存屏障指令，纯属“自我安慰”
正确做法：用 std::atomic + 明确 memory_order，或者至少用 std::atomic_thread_fence(std::memory_order_seq_cst) 插在关键位置。
std::atomic_thread_fence 是最易被低估的工具
很多人只盯着原子变量本身的 order，却忘了 fence 才是真正“切开执行流”的手术刀。它不绑定任何变量，只作用于当前线程的内存访问序列。
常见使用场景：
- 初始化一大块内存后，用
std::atomic_thread_fence(std::memory_order_release)确保所有写入对其他线程可见，再设置发布标志 - 读取发布标志后，用
std::atomic_thread_fence(std::memory_order_acquire)确保后续读取能看到之前所有被 release 的写入 - 在无锁栈 pop 操作中，用
std::atomic_thread_fence(std::memory_order_acquire)防止后续指针解引用被提前到 load head 之前
注意：seq_cst fence 开销比 acquire/release 大得多，x86 上虽便宜（基本是空操作），但在 ARM64 上会生成 dmb ish，务必按需选用。
TSan 是唯一能帮你揪出重排 Bug 的实用工具
重排 bug 的最大特点是“有时正常、有时崩溃、加个 std::this_thread::yield() 就消失”。靠肉眼或 log 几乎无法定位。这时候必须依赖 ThreadSanitizer（TSan）。
启用方式很简单：
- Clang/GCC 编译时加
-fsanitize=thread和-g - 运行时设置环境变量
TSAN_OPTIONS="halt_on_error=1"让它一报错就停 - 它能精确指出哪两个线程、哪两行内存访问、因缺少何种同步而构成 data race
但要注意：TSan 本身会插入大量检查逻辑，导致程序变慢、调度行为改变，它不会复现所有重排路径，但只要它报了，100% 是真实 bug。没报 ≠ 没问题，但报了就必须修。
最难缠的点往往藏在看似无关的地方：比如一个全局 std::atomic<bool></bool> 用来控制开关，但它和后面几十行非原子日志写入之间没有 acquire-release 关系，TSan 就会标红那几行日志——因为它们的执行顺序在逻辑上依赖那个开关，但代码里没建序。
