acquire-release仅在成对操作间建立局部happens-before关系，不保证全局顺序；seq_cst强制所有线程观察到完全一致的全局操作顺序，代价更高。
acquire-release 语义和 memory_order_seq_cst 的本质区别在于：前者只在成对的原子操作之间建立局部的 happens-before 关系，不强求全局顺序；后者要求所有线程看到**完全一致的全局操作顺序**，代价更高。
acquire-release 只同步相关操作，不约束无关原子变量
当你用 flag.store(1, std::memory_order_release) 和 flag.load(std::memory_order_acquire) 配对时，仅保证「release 前的所有写」对「acquire 后的所有读」可见——但这个约束只作用于这两个操作涉及的变量（比如 flag）以及它们所“携带”的数据（比如你提前写入的 data）。其他未参与该同步链的原子变量（比如另一个 counter）的操作顺序，在不同线程中可能被观察到不同。
常见错误现象：
- 线程 A 写 data = 42 → flag.store(1, std::memory_order_release)
- 线程 B flag.load(std::memory_order_acquire) == 1 → 读 data 正确
- 但线程 B 同时观察到 counter.load() 的值，可能比线程 A 中 counter++ 的执行顺序更早或更晚，且不同线程间对该顺序的感知不一致
- 适用场景：保护一组关联数据（如指针 + 所指对象），不需要跨多个独立原子变量维持统一视图
- 性能影响：编译器/CPU 可保留大量重排自由度，x86 上通常无额外 fence 指令，ARM/AArch64 需
ldar/stlr类指令，开销可控
seq_cst 强制所有线程共享同一操作全序
memory_order_seq_cst 不仅提供 acquire/release 的同步能力，还额外要求：任意两个 seq_cst 操作，在所有线程看来，都必须服从同一个全局执行顺序。这意味着即使两个操作完全不相关（比如对 flag1 和 flag2 的 store），它们的相对顺序也必须被所有线程一致观察到。
使用场景：
- 实现锁-free 的全局计数器（需严格单调递增）
- 构建多生产者多消费者队列中跨 slot 的顺序依赖
- 调试时临时替换内存序以排除重排干扰（但不可用于性能敏感路径）
- 容易踩的坑：混用
seq_cst和acquire/release会破坏全局顺序预期——只要有一个seq_cst操作存在，整个系统就必须满足其全序约束，其他非seq_cst操作仍可乱序，但会被“拖进”该全序的某个位置 - 性能影响：x86 上多数
seq_cststore 需mfence，ARM 上需 full barrier，吞吐下降明显；在弱一致性架构上尤为显著
acquire-release 无法替代 seq_cst 的典型反例
考虑两个线程同时执行：
线程 A：a.store(1, std::memory_order_seq_cst); b.store(1, std::memory_order_relaxed);
线程 B：while (!a.load(std::memory_order_seq_cst)); assert(b.load(std::memory_order_relaxed) == 1);
这段代码在 seq_cst 下断言永不会失败；但如果把 A 中的 a.store 改成 std::memory_order_release，B 中的 a.load 改成 std::memory_order_acquire，则断言可能失败——因为 b.store 是 relaxed，它和 a 的 release-acquire 链无同步关系，B 完全可能先看到 a==1，再读到旧的 b 值。
立即学习“C++免费学习笔记（深入）”；
关键点：acquire-release 是“定向通道”，seq_cst 是“公共时间轴”。你不能靠拼接多个 acquire-release 链来模拟 seq_cst 的全局一致性——那需要显式插入额外的同步点或改用 seq_cst。
