std::atomic 默认使用 memory_order_seq_cst，最严格但性能最低；未配对内存序（如一端 relaxed 一端 seq_cst）易引发可见性 bug；fence 用于非原子变量的顺序约束；-o2 暴露未定义行为；arm 需显式指令保障 acquire/release 语义。
为什么 std::atomic 默认不保证顺序，而你又没显式加 memory_order？
多数人写 std::atomic<int></int> 时只当它是“线程安全的 int”，但它的读写默认用的是 memory_order_seq_cst——最重、最慢的顺序，且容易掩盖真实问题。真正出可见性 bug 的时候，往往不是因为没用 std::atomic，而是用了却没配对约束：比如一个线程用 store() 写，另一个用普通指针读，或者两个都用 std::atomic 但一个用 memory_order_relaxed、另一个没指定（实际是 seq_cst），导致编译器/CPU 乱序超出预期。
- 所有
std::atomic<t></t>成员函数（如load()、store()）都接受可选的memory_order参数；不传就默认seq_cst -
memory_order_relaxed不提供同步或顺序保证，仅保证原子性——适合计数器累加这类无依赖场景 - 想让写操作对其他线程“可见”，至少得用
memory_order_release（写端） +memory_order_acquire（读端）配对 - 别在
relaxed上做“等待某值出现”的逻辑，它不阻止重排，可能永远等不到
std::atomic_thread_fence 在什么情况下比 atomic::store/load 更合适？
当你需要对**非原子变量**施加顺序约束时，std::atomic_thread_fence 是唯一选择。比如：一个线程先初始化一块内存（写普通指针 data_ptr），再设置标志位（ready_flag.store(true, memory_order_relaxed)）；另一个线程看到标志为 true 后去读 data_ptr 指向的内容。这时光靠 ready_flag 的原子性不够，必须用 fence 阻止重排：
thread A:
data_ptr = new int[100];
// 初始化 data_ptr 所指内存...
std::atomic_thread_fence(std::memory_order_release);
ready_flag.store(true, std::memory_order_relaxed);
<p>thread B:
while (!ready_flag.load(std::memory_order_relaxed)) { /<em> spin </em>/ }
std::atomic_thread_fence(std::memory_order_acquire);
// 此时读 data_ptr 是安全的-
std::atomic_thread_fence不绑定任何变量，只影响当前线程的内存访问顺序 -
memory_order_releasefence 确保它之前的读写不会被重排到 fence 之后 -
memory_order_acquirefence 确保它之后的读写不会被重排到 fence 之前 - 不要滥用：fence 是全局屏障，开销通常高于带 acquire/release 的原子操作
Clang/GCC 编译时加 -O2 后多线程行为突变，是不是编译器在搞鬼？
不是“搞鬼”，是暴露了未定义行为（UB）。C++ 标准规定：对同一内存位置的非原子读写，若无同步（如 mutex、acquire-release 配对、fence），就是数据竞争，属于 UB。优化级别越高，编译器越敢把代码重排、合并、甚至删掉看似“冗余”的读——比如循环里反复读一个非原子 flag，-O2 可能直接提升为一次读并缓存结果，导致永远看不到变化。
- 检查所有跨线程访问的变量：是否全为
std::atomic？是否用了恰当的memory_order？ - 用
std::atomic<bool></bool>替代volatile bool：后者不解决 CPU 重排，也不提供同步语义 - TSAN（ThreadSanitizer）能捕获大部分数据竞争，但无法检测纯 relaxed 原子操作导致的逻辑错误
- 不要依赖“我本地跑着没问题”——不同 CPU 架构（x86 vs ARM）对重排容忍度差异极大
ARM/AArch64 上 memory_order_acquire 生成的指令比 x86 多，怎么理解？
x86 的强内存模型天然保证了大多数顺序（如 store-store、load-load 不重排），所以 acquire 和 release 在 x86 上常编译为空操作（no-op），只靠 CPU 自身行为保证。ARM 则不同，它允许更激进的重排，因此 acquire 会插入 ldar（load-acquire）指令，release 插入 stlr（store-release）指令——这些是语义级指令，不是编译器“加的屏障”，而是架构要求。
立即学习“C++免费学习笔记（深入）”；
- 这意味着：同样一段 C++ 代码，在 ARM 上更可能暴露因漏写
memory_order导致的问题 - 别在 x86 上验证“不需要 fence 就行”，切到 ARM 可能立刻崩溃或死锁
- 如果必须手写汇编或调用底层 API（如 Linux futex），要查对应架构的内存屏障文档，不能套用 x86 的
mfence思维
实际写多线程代码时，最容易被忽略的不是“怎么加 barrier”，而是“哪几行内存访问必须构成一个同步单元”。一个 store 和一个 load 单独看都合法，但它们之间若存在逻辑依赖，就必须用 acquire-release 或 fence 显式建立 happens-before 关系——否则编译器和 CPU 都有权按各自规则重排。
