compare_exchange_weak必须置于do-while/while循环中，且expected必须为可修改的非const引用；否则因伪失败和expected未更新导致逻辑错误或死循环。
直接说结论：compare_exchange_weak 必须写在 do-while 或 while 循环里，且 expected 必须是可修改的非 const 引用——漏掉任一条件，代码大概率逻辑错误或死循环。
为什么 compare_exchange_weak 总是返回 false？
常见现象：刚初始化一个 std::atomic<int></int>，expected = 0，调一次 compare_exchange_weak(expected, 1) 就返回 false，但值明明没被其他线程改过。
原因有两个：
-
compare_exchange_weak允许伪失败（spurious failure），尤其在 ARM 等弱内存模型平台； - 它会**覆写
expected为当前实际值**——如果expected是字面量、临时变量或const引用，函数无法更新它，下次重试仍用旧值，导致无限失败。
✅ 正确写法：
int expected = atomic_var.load();<br>
while (!atomic_var.compare_exchange_weak(expected, desired)) {<br>
// expected 已被更新为当前值，可继续用<br>
}
❌ 错误写法：
int expected = 0;<br> atomic_var.compare_exchange_weak(expected, 1); // 只调一次，且 expected 初始值固定
❌ 危险写法：
const int exp = atomic_var.load();<br> atomic_var.compare_exchange_weak(exp, 1); // 引用绑定到 const，函数无法更新它
compare_exchange_weak 和 compare_exchange_strong 怎么选？
不是“强就一定好”，而是看场景对失败容忍度和性能敏感度：
立即学习“C++免费学习笔记（深入）”；
-
compare_exchange_weak在 x86 上通常和strong性能一致，但在 ARM 上生成更轻量指令（如LDAXR/STLXR），代价是可能伪失败； -
compare_exchange_strong保证仅当值真实不等才失败，但重试成本更高（底层可能隐式循环调用weak）。
优先用 weak 的场景：
- 所有循环重试逻辑（无锁栈 push/pop、计数器递增、状态机跃迁）
考虑用 strong 的场景：
- 单次尝试逻辑（如初始化标志位）
- 失败需触发昂贵回退（如日志 + 告警）
- 伪失败会破坏业务语义（如金融事务原子提交）
混合策略可行：
- 循环中前 N 次用 weak，失败后切 strong，避免极端争用下伪失败堆积
内存序（memory_order）参数选错会导致什么问题？
最常踩的坑是把 memory_order_relaxed 用在需要同步的场景里——比如多个线程分别更新不同字段，但期望某次 CAS 成功后，其他线程能立刻看到之前写入的非原子变量。这时仅靠 relaxed 无法建立 happens-before 关系。
典型错误模式：
std::atomic<int> flag{0};<br>
int data = 42;<br>
// 线程 A<br>
data = 100;<br>
flag.compare_exchange_strong(expected=0, desired=1, std::memory_order_relaxed, std::memory_order_relaxed); // ❌ data 修改对线程 B 不可见
正确做法是至少用 memory_order_release（写端）配 memory_order_acquire（读端）：
// 线程 A<br>
data = 100;<br>
flag.compare_exchange_strong(expected=0, desired=1, std::memory_order_release, std::memory_order_relaxed);<br>
// 线程 B<br>
if (flag.load(std::memory_order_acquire) == 1) {<br>
// 此时 data == 100 一定可见<br>
}
初学者可默认用 std::memory_order_acq_rel（对 CAS 本身），兼顾读写同步需求；若只关心原子变量自身顺序，且无其他共享数据依赖，relaxed 是安全的。
注意：failure 的 memory_order 必须不能比 success 更强（如 success=acq_rel 时，failure 只能是 relaxed）。
指针类型 CAS 容易踩的 ABA 问题怎么防？
用 std::atomic<node></node> 实现无锁链表时，典型错误是节点 A 被弹出、析构、新节点又恰好分配到同一地址，CAS 误判“还是原来的 A”，导致数据损坏或崩溃。
这不是 compare_exchange_weak 的 bug，而是裸指针 CAS 的固有缺陷。解决思路包括：
- 用带版本号的指针（如
std::atomic<:pair size_t>></:pair>） - 用
std::shared_ptr配合引用计数（但注意标准库未特化std::atomic<:shared_ptr>></:shared_ptr>，需用std::atomic<:shared_ptr>></:shared_ptr>的专用接口或自定义封装） - 使用 Hazard Pointer 或 RCU 等更高级的无锁内存管理机制
真正容易被忽略的是：ABA 不是并发竞争的“异常情况”，而是在任意长时间运行、频繁分配释放内存的无锁结构中必然出现的问题——只要没处理，就不是“可能出错”，而是“早晚出错”。
