AtomicStampedReference 不自动解决 ABA，而是通过版本号使 ABA 可检测；必须用 get(int[]) 原子获取最新引用与 stamp，每次 compareAndSet 前重读，不可硬编码或缓存 stamp，否则 CAS 因 stamp 不匹配而失败。
AtomicStampedReference 不是自动解决 ABA，而是让 ABA 可被检测——你必须显式管理版本号，否则和 AtomicReference 没区别。
为什么 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，但逻辑一致性完全依赖它。
