结论：compare_exchange_strong并非默认更安全的选择，仅适用于必须区分伪失败且禁止重试的场景；多数自旋等待应使用compare_exchange_weak配合do-while循环。
直接说结论：在无锁编程中，std::atomic::compare_exchange_strong 不是“更安全的默认选择”，而是有明确适用边界的工具——它只在你**必须拒绝伪失败、且不能重试**的场景下才该用；绝大多数自旋等待逻辑，应该配 compare_exchange_weak + do-while 循环。
为什么 compare_exchange_strong 在循环里反而可能拖慢性能
表面上看，compare_exchange_strong “不伪失败”听起来更可靠，但它的实现策略因平台而异：在 ARM 上，它常被编译为内部带隐式重试的小循环（比如反复调用 compare_exchange_weak 直到成功或确认真实不匹配）；x86 上虽常映射到单条 cmpxchg，但若配合宽松内存序（如 memory_order_relaxed），它仍无法规避编译器重排带来的逻辑错误。
常见误用现象：compare_exchange_strong 被塞进一个外层 while 循环，结果变成“循环套循环”，指令路径变长，cache line 争用加剧，尤其在高竞争下吞吐下降明显。
- 真正需要 strong 的典型场景：实现无锁队列的
pop操作中，要严格区分「队列空」和「CAS 瞬间被抢占」两种语义，不能靠重试掩盖状态歧义 - 如果你只是想把新节点插到链表头，或者更新计数器，
weak+ 显式循环才是标准写法 - MSVC 和 GCC 对
strong的展开策略不同，跨编译器时行为不一致风险比想象中高
compare_exchange_strong 的正确签名与 memory_order 陷阱
它的完整签名是：bool compare_exchange_strong(T& expected, T desired, memory_order success, memory_order failure) noexcept。最容易出错的是两个 memory_order 参数的约束关系：failure 的强度必须 ≤ success。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
典型错误配置：success = std::memory_order_acq_rel，但 failure = std::memory_order_seq_cst —— 这会触发未定义行为，Clang/GCC 可能静默忽略或生成错误指令。
- 读写同步场景（如发布/订阅模式）：success 至少用
memory_order_release，failure 可用memory_order_relaxed（因为失败时无需同步其他变量） - 仅原子变量自身顺序敏感（如引用计数递减）：两个都可用
memory_order_relaxed，但务必确认没有其他共享数据依赖 - 初学者可先统一用
std::memory_order_acq_rel（适用于 CAS 本身既是读也是写），等压测暴露瓶颈后再细化
一个真实的 compare_exchange_strong 使用案例：无锁队列 pop 的状态分离
在无锁单生产者/单消费者队列中，pop 需返回三种结果：成功取值、队列为空、中间态冲突（如 head 已变但 tail 还没追上）。这时必须用 compare_exchange_strong，因为你要靠「单次尝试失败」来触发状态检查分支，而不是无脑重试。
Node* old_head = head.load(std::memory_order_acquire);
Node* next = old_head ? old_head->next : nullptr;
if (old_head == head.load()) { // double-check
if (next && head.compare_exchange_strong(old_head, next,
std::memory_order_acq_rel, std::memory_order_acquire)) {
// 成功：old_head 是待弹出节点
} else {
// 失败：不是因伪失败，而是真实被其他线程改过 → 需重新评估队列状态
}
}
注意这里没用循环包裹 compare_exchange_strong；失败后直接跳转到状态重判逻辑，避免掩盖并发时的真实竞争信号。
真正难的不是记住 weak 和 strong 的区别，而是判断你的业务逻辑是否允许重试、是否需要从失败中提取额外状态信息。多数人卡在这一步：把 strong 当成“保险丝”乱用，结果既没获得语义优势，又丢了性能。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
