memory_order 是对编译器和CPU重排序行为的显式约束，非性能开关；选错可能导致陈旧值、乱序或死锁。默认应使用 memory_order_seq_cst，仅在明确需求且验证后才用更弱序。

memory_order 是什么，为什么不能乱选

它不是“性能开关”，而是对编译器和 CPU 重排行为的显式约束。选错不会立刻崩溃，但可能在多核、优化开启（-O2）、或换 CPU 架构后突然出现读到陈旧值、指令乱序执行、甚至死锁——而且极难复现。

关键判断：默认用 memory_order_seq_cst，除非你明确知道为什么需要更弱的顺序，且已验证过所有线程路径。

哪些场景必须用 memory_order_seq_cst

绝大多数日常同步逻辑都属于这一类：计数器增减、标志位设置+后续操作、生产者-消费者中的简单信号量。它的语义最接近“直觉上的原子操作”——所有线程看到的修改顺序一致，且与程序顺序一致。

• 多个 atomic 变量之间有逻辑依赖（比如先写 ready 再写 data，消费者要按此顺序读）
• 与非原子变量混用，且依赖其可见性（如写完 atomic_flag 后更新全局结构体）
• 调试阶段、原型代码、或不确定并发模型时

示例：counter.fetch_add(1, std::memory_order_seq_cst) —— 安全、可预测、开销在现代 x86 上几乎无感。

memory_order_acquire/release 什么时候能用

这是最常被误用也最有价值的一组。它不保证全局顺序，只建立“同步关系”：一个 release 写 + 对应的 acquire 读，构成一个同步点，确保该点之前的所有内存操作对另一个线程可见。

典型适用场景：

C++14

C++14 对 C++11 的修正与增强版本，适合旧系统维护和较老工具链兼容。

下载

• 自旋锁实现：lock() 用 memory_order_acquire 读标志，unlock() 用 memory_order_release 写标志
• 单生产者单消费者无锁队列：生产者 store head 用 release，消费者 load head 用 acquire
• 初始化完成标志：生产者写完数据后用 store(true, memory_order_release)，消费者用 load(memory_order_acquire) 检查

注意：acquire/release 必须成对出现在不同线程的同一变量上；单独用 relaxed 或混搭 seq_cst 会破坏同步语义。

memory_order_relaxed 和 memory_order_consume 的坑

memory_order_relaxed 只保证原子性，不施加任何顺序约束。适合计数器（如引用计数）、状态标记（只要求“最终一致”，不要求其他线程何时看到），但极易误用。

常见错误：

• 用 relaxed 实现“先设 flag 再写 data”，消费者用 relaxed 读 flag 后直接读 data —— data 可能未写入缓存，或被重排到 flag 之后
• 把 relaxed 当作“性能更好所以优先选”，却没意识到它让推理线程交互变得几乎不可能

memory_order_consume 理论上比 acquire 更轻量，但实际支持极差：GCC/Clang 当前将其降级为 acquire，且容易因编译器优化引入意外重排。标准中已标记为“deprecated”，别用。

复杂点在于：即使你选对了 order，不同 CPU 架构（x86 vs ARM/AArch64）对相同 order 的硬件实现强度不同。x86 天然强顺序，ARM 则更依赖显式 barrier。测试必须在目标平台上做，不能只信本地跑通。

C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！