memory_order是控制原子操作可见性与执行顺序约束的机制，用于防止编译器/CPU重排并协调多线程间内存访问，而非保证原子性本身。
std::atomic 的内存序（memory_order）控制的是原子操作在多线程环境下的**可见性**和**执行顺序约束**，它不改变原子操作本身的原子性，而是决定该操作如何与其它读写（包括非原子的）交互——尤其是编译器优化和 CPU 指令重排的边界。
memory_order 是什么？为什么需要它？
C++ 编译器和现代 CPU 为了性能，会做两件事：一是编译期指令重排（reordering），二是运行时乱序执行（out-of-order execution）。对单线程来说这没影响，但多线程下，如果没有显式约束，一个线程写的值可能迟迟不被另一个线程看到，或者读写顺序看起来“错乱”。
memory_order 就是告诉编译器和 CPU：“在这个原子操作前后，哪些读写不能越过它”，从而在性能和正确性之间做精细取舍。不是越强越好，选错会导致性能下降甚至死锁；也不是越弱越安全，选太弱可能引发数据竞争或逻辑错误。
六种 memory_order 及典型用途
memory_order_relaxed 最弱约束。只保证当前操作是原子的，不施加任何同步或顺序要求。适合计数器、句柄生成等“不依赖其它内存状态”的场景。
- 比如：原子自增一个全局统计量，仅用于日志或监控，不作为同步信号
- 注意：两个 relaxed 操作之间无顺序保证，也不能用来实现锁或 barrier
memory_order_consume 已基本被弃用（C++20 中标记为 deprecated）。它试图建立“数据依赖顺序”，但语义复杂且硬件支持差，实践中极少使用。建议直接用 acquire/release 替代。
memory_order_acquire 用于读操作（load）。它保证：该 load 之后的所有读写（包括非原子的），不能被重排到该 load 之前。常与 release 配对，构成“获取-释放同步”（acquire-release synchronization）。
- 典型场景：读取一个原子 flag，若为 true，则后续访问它保护的数据是安全的
- 例如：
if (ready.load(memory_order_acquire)) { use(data); }—— data 的读取不会被提前到 ready.load 之前
memory_order_release 用于写操作（store）。它保证：该 store 之前的所有读写（包括非原子的），不能被重排到该 store 之后。必须和 acquire 配对使用才能建立同步。
- 典型场景：先初始化数据，再设置就绪标志
- 例如：
data = 42; ready.store(true, memory_order_release);—— data 赋值一定发生在 store 之前
memory_order_acq_rel 用于读-修改-写操作（如 fetch_add、compare_exchange_weak）。它同时具备 acquire 和 release 的语义：操作前的读写不能后移，操作后的读写不能前移。
- 常见于自旋锁的 unlock / lock 实现、引用计数的增减
- 例如：
ref_count.fetch_sub(1, memory_order_acq_rel)—— 既防止前面的资源访问被拖到减计数之后，也防止后面的释放动作被提到之前
memory_order_seq_cst 最强默认序（所有 atomic 操作的默认行为）。它要求：所有线程看到的原子操作顺序是一致的，并且每个操作都具有 acquire + release 语义，还额外插入全局顺序约束（类似全屏障 full barrier）。
- 适合逻辑简单、对正确性要求极高、且性能不是瓶颈的场景（如教学示例、关键开关）
- 性能开销最大，尤其在 ARM/PowerPC 等弱一致性架构上；x86 因其强内存模型，开销相对小，但仍存在编译器屏障成本
acquire-release 同步是怎么工作的？
它不靠“全局时间”，而靠“同步关系”。当线程 A 执行了 store(..., memory_order_release)，线程 B 执行了 load(..., memory_order_acquire) 并读到了 A 写入的值，那么 A 在 store 之前做的所有内存操作（包括非原子的），对 B 来说在 load 之后都是可见的。
立即学习“C++免费学习笔记（深入）”；
这个关系叫“synchronizes-with”，是 C++ 内存模型中构建 happens-before 的核心机制。它比 seq_cst 更轻量，又比 relaxed 安全得多，是高性能并发编程的主力工具。
怎么选？几个实用建议
- 不确定时，先用
memory_order_seq_cst验证逻辑正确性，再逐步降级 - 读标志位（flag）、进临界区 →
acquire - 写标志位、出临界区 →
release - 单纯计数、ID 分配 →
relaxed（但确保不依赖其它变量状态） - 锁的 try_lock/unlock、引用计数变更 →
acq_rel - 永远不要对同一个原子变量混用不同 memory_order 做无意义的“加强”——它不会提升安全性，只会拖慢性能
基本上就这些。理解 memory_order 的关键是：它不是描述“这个操作本身怎么执行”，而是描述“这个操作像一堵墙，挡住哪些其它读写”。不复杂，但容易忽略。
