AtomicStampedReference如何有效解决并发更新中的ABA问题？

本文共计797个文字，预计阅读时间需要4分钟。

AtomicStampedReference 并非自动解决 ABA 问题，而是允许 ABA 发生，但可以通过显式管理版本号来检测 ABA 事件。与 AtomicReference 相比，AtomicStampedReference 在功能上没有区别。

为什么 compareAndSet 会失败？因为 stamp 不匹配

常见错误现象：compareAndSet 总是返回 false，即使值没变；或第一次就失败，调试发现 expectedStamp 和当前 stamp 对不上。

根本原因：你没用 get(int[]) 读取最新 stamp，而是靠“猜”或硬编码（比如写死 0 或 oldStamp + 1 而不重读）。

• get(int[] stampHolder) 是唯一能原子获取「当前引用 + 当前 stamp」的方法；getReference() 和 getStamp() 是分开调用的，中间可能被其他线程修改
• 每次 compareAndSet 前，必须先调用 get 拿到最新 pair，再基于那个 stamp 计算 newStamp
• stamp 溢出（从 Integer.MAX_VALUE 回绕到 Integer.MIN_VALUE）极少见，但若业务对“绝对单调”有强要求，需额外防护

怎么写一个安全的循环重试更新逻辑

典型使用场景：多个线程竞争更新同一个状态（如订单从 "PENDING" → "PROCESSED"），且要防止因 ABA 导致重复处理。

错误写法：while (!ref.compareAndSet(oldRef, newRef, 0, 1)) —— stamp 写死，第二轮就卡死。

• 正确结构必须包含：声明 int[] stamp = new int[1] → ref.get(stamp) → 提取 oldStamp = stamp[0] → compareAndSet(..., oldStamp, oldStamp + 1)
• 若失败，直接继续循环，**不要缓存 oldStamp**；每轮都重新 get，确保 stamp 是实时的
• 避免在 compareAndSet 成功后还用旧 stamp 做后续判断——成功意味着 pair 已更新，旧 stamp 失效

和 AtomicReference 的性能与兼容性差异

实测吞吐量低 5%–15%，不是理论开销，而是真实代价。别只看“加了个 int”，它影响缓存行对齐和内存访问次数。

• 底层仍是 Unsafe.compareAndSwapObject，但操作的是 Pair 对象（含 reference + stamp），比单字段多一次字段读取
• Android API 小于 24 时，get(int[]) 可能抛 NoSuchMethodError；老版本只能用反射或降级为 AtomicReference + 手动同步
• 如果你的场景里“值复用”极少（比如对象永不回收、ID 全局唯一不重用），那 ABA 风险本身就很低，强行上 AtomicStampedReference 只是徒增复杂度

最容易被忽略的点：stamp 初始值参与所有首次 CAS 判断，它不是“随便设个 0 就行”，而是整个版本链的起点。一旦初始化为 100，所有后续 CAS 都得基于这个基线递增——业务语义不绑定 stamp，但逻辑一致性完全依赖它。