memory_order_consume已被C++17弃用，因硬件不支持且编译器降级为acquire；其与acquire的关键区别在于仅通过数据依赖链传播同步，而acquire无条件禁止重排。
memory_order_consume 为什么几乎没人用
它理论上用于建立数据依赖关系的轻量级同步，但实际中基本被弃用。C++17 标准已明确标注为“deprecated”，主流编译器（GCC、Clang）在生成代码时会自动降级为 memory_order_acquire，且不提供独立的硬件指令支持。
它和 memory_order_acquire 的关键区别在哪
区别只存在于「依赖链传播」的语义上：memory_order_consume 要求后续读操作必须通过**数据依赖**（如指针解引用、数组索引、结构体成员访问）才能看到前序 memory_order_release 写入的值；而 memory_order_acquire 是无条件禁止重排，不管有没有依赖。
例如：
// 假设 p 是原子指针，由其他线程用 store(..., memory_order_release) 写入 T* p = atomic_load(&ptr, memory_order_consume); int x = p->data; // ✅ 合法：data 是 p 的依赖项，能保证看到 release 写入的值 int y = global_flag; // ❌ 不保证：global_flag 和 p 无数据依赖，可能读到旧值
哪些场景曾试图用 consume，现在该换成什么
典型误用是想“省点开销”去同步单个指针及其所指对象——比如 lock-free 链表节点遍历、RCU 风格读取。但现实是：
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 所有现代 CPU 架构（x86、ARM64、AArch64）都不区分 consume 和 acquire 的指令语义
- 编译器无法可靠追踪复杂依赖链（如间接函数调用、虚函数、模板实例化后的数据流）
- 一旦依赖链断裂（比如把
p->data存到局部变量再用），consume 就失效，且无编译警告
正确做法：统一用 memory_order_acquire 替代 memory_order_consume，语义清晰、行为可预测、性能差异在绝大多数场景下可忽略。
如果你真在旧代码里见到 consume，要注意什么
它不是 bug，但属于过时约定。迁移时需检查两点：
- 确认所有依赖路径确实是直接的、编译器可静态分析的数据流（不含 cast、union、memcpy 等破坏依赖的操作）
- 替换为
memory_order_acquire后，观察是否有意外的性能回退（极少见，除非在极端高频的无锁循环里）
更关键的是：别指望靠 consume 实现“比 acquire 更快”的同步——它既没更快，也不更安全，只是更难写对。
