C++ std::atomic::compare_exchange_weak处理并发冲突逻辑 _ 源码【详解】

✅ 所以，正确的写法是这样的：

int expected = atomic_var.load();
while (!atomic_var.compare_exchange_weak(expected, desired)) {
    // 循环体：此时 expected 已被自动更新为 atomic_var 的当前值
    // 可以根据需要在这里进行一些计算，或者直接空循环重试
}

❌ 而下面这两种写法，则是典型的错误示范：

错误一：单次调用，失去重试能力

int expected = 0;
atomic_var.compare_exchange_weak(expected, 1); // 如果失败或伪失败，操作就结束了

错误二：绑定到const引用，阻塞了更新通道

const int exp = atomic_var.load();
atomic_var.compare_exchange_weak(exp, 1); // 编译可能通过，但失败时无法更新exp，逻辑错误

compare_exchange_weak 还是 compare_exchange_strong？这不是一道单选题

面对这两个孪生兄弟，很多人的第一反应是：“强的肯定比弱的好”。其实不然，选择的关键在于你对失败行为的容忍度以及对性能的敏感度。

• compare_exchange_weak：允许伪失败。在x86这种强内存模型的平台上，它的性能通常与strong版本无异。但在ARM平台上，它能够生成更轻量级的指令序列（比如LDAXR/STLXR），代价就是可能出现伪失败。
• compare_exchange_strong：保证仅在原子变量的值真实不等于expected时才失败。这消除了伪失败的不确定性，但代价是可能需要在内部进行额外的原子读操作，重试成本略高。

那么，实践中该如何选择呢？这里有一些经验性的策略：

• 优先使用weak的场景：所有包含显式循环重试的逻辑。比如无锁栈的push/pop操作、计数器递增、状态机状态跃迁。在这些场景下，伪失败无非就是让循环多跑一次，而换取的可能是指令级性能提升。
• 必须使用strong的场景：单次尝试、不容忍任何伪失败的逻辑。例如，初始化一个标志位，如果失败需要触发昂贵的错误处理流程（记录日志、发送告警），或者伪失败会直接破坏业务语义（比如金融交易中的事务提交）。
• 混合策略：一种折中的高级用法是，在循环的前N次尝试中使用weak版本以追求性能，如果连续失败次数过多，则切换到strong版本，以避免在极端高并发争用下，伪失败堆积导致活锁。

小心那个“failure”参数：双内存序版本的重重限制

当使用功能更强大的双内存序重载版本时——即compare_exchange_weak(expected, desired, success, failure)——需要格外小心failure内存序参数的设置。它不是可以随意指定的：

• failure参数指定的内存序不能强于success参数。这是为了保证内存屏障语义的合理性。
• failure不能是memory_order_release或memory_order_acq_rel。道理很简单，失败路径上没有写操作，自然不需要“释放”语义。
• 存在隐式转换规则：如果success设为memory_order_acq_rel，那么failure会被隐式地当作memory_order_acquire。如果success是memory_order_release，则failure会被当作memory_order_relaxed。

对于大多数应用场景，使用单参数版本（默认采用最严格的memory_order_seq_cst）是更安全、更省心的选择。除非你确实在进行极致的底层性能优化，并且对目标硬件平台的内存模型以及代码的同步语义了如指掌，否则不要为了节省几条指令而引入潜在的重排序Bug。

最后，值得反复强调的是：compare_exchange_weak的伪失败不是Bug，而是其设计特性；失败时更新expected也不是副作用，而是接口契约的一部分。因循环结构写错或引用类型传错而导致的问题，往往不会在低并发或单元测试中立刻暴露。它们像潜伏的暗礁，只在高并发压力测试、跨平台移植，或生产环境流量高峰时，才会突然让你“触礁沉船”。理解并尊重这些契约，是写出健壮并发代码的第一步。