compare_exchange_strong总失败是因为它要求当前值等于预期值才交换，否则将当前值写回预期变量；典型错误是未在循环中重试或未更新预期值，导致比较持续失败。
compare_exchange_strong 为什么总失败？
它不是“设置新值”，而是“比较并交换”：只有当前值等于预期值时才更新，否则把当前值写回预期变量。很多人误以为传个旧值就能改，结果 compare_exchange_strong 一直返回 false，还发现预期变量被悄悄改了。
典型错误写法：
std::atomic<int> counter{0};
int expected = 0;
counter.compare_exchange_strong(expected, 1); // ✅ 成功，expected 不变
counter.compare_exchange_strong(expected, 2); // ❌ 失败，expected 变成 1！</int>
- 第二次调用时
expected还是 0，但原子变量已是 1 → 比较失败 →expected被赋为当前值 1 - 必须在循环里重试，或确保每次传入的是最新快照
- 如果只做一次尝试且不关心失败，记得检查返回值，别假设一定成功
怎么写一个安全的自增原子操作？
用 compare_exchange_strong 实现 CAS 自增，核心是循环重试直到成功。它比 fetch_add 更底层，适合需要精确控制或复合逻辑的场景（比如加完还要判断是否达到阈值）。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
std::atomic<int> counter{0};
int old_val, new_val;
do {
old_val = counter.load();
new_val = old_val + 1;
} while (!counter.compare_exchange_strong(old_val, new_val));</int>
-
old_val必须在循环内读取，不能提出来 —— 否则可能被其他线程改过，导致无限重试 - 循环体里不要放耗时操作，否则降低吞吐；CAS 本身是轻量级的，但重试多了也伤性能
- 注意
compare_exchange_strong的两个参数顺序：(expected, desired)，和很多 API 相反，容易写反
strong 和 weak 版本到底选哪个？
compare_exchange_weak 允许“虚假失败”（spurious failure），即值没变也返回 false；compare_exchange_strong 保证只在真实不匹配时失败。但在 x86 上二者生成的指令几乎一样，ARM 等平台 weak 版本可能更高效。
- 只要你在循环里用，选
weak更合理 —— 它允许硬件优化，且循环天然处理虚假失败 - 如果只尝试一次（比如初始化场景），必须用
strong，否则可能莫名其妙失败 - 别为了“听起来更强”就默认用
strong；标准明确说 weak 是“推荐用于循环”，strong 是“语义更严格但不一定更快”
bool 返回值和 expected 参数的联动关系
返回 true 表示交换成功，此时 expected 不变；返回 false 表示失败，此时 expected 已被更新为原子变量当前值 —— 这是它最易被忽略的副作用。
- 如果你用同一个
expected变量连续调用多次，它会不断被覆盖，变成“最新已知值” - 想保留原始期望值？得用不同变量，或每次重新赋值：
expected = counter.load() - 调试时打印
expected值，常能快速定位为什么失败：是真被别人改了，还是自己没及时刷新
expected 会被修改，或者在循环里没重读原子值。这两个点踩中一个，逻辑就静默出错。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
