AtomicStampedReference并非消除ABA问题，而是通过“引用+版本号”双校验机制识别并拦截ABA：每次CAS需同时匹配当前引用和stamp，若中间发生A→B→A，stamp已变，CAS即失败。
AtomicStampedReference 不是让 ABA 消失，而是让 ABA 可被识别和拦截。它通过“值 + 版本号”双校验机制，在 CAS 失效前就主动暴露中间修改，从而避免误判。
ABA 问题的本质不是值变了没，而是状态是否可信
当一个线程读到值 A 后被挂起，另一线程把 A → B → A，表面看值没变，但背后可能已发生资源释放、节点复用、链表结构重排等不可逆操作。CAS 单纯比对数值，会放行这种“假静止”，导致逻辑错乱（比如无锁栈 pop 出悬空节点）。
AtomicStampedReference 的设计出发点很明确：不阻止修改，只确保每次 CAS 都基于最新且未被覆盖的快照。
关键在于正确读取与更新版本号
版本号不会自动递增，必须由你显式管理。常见错误是硬编码 newStamp = oldStamp + 1，却忽略了“oldStamp”必须来自刚读到的当前状态。
- 用 get(int[] stampHolder) 一次性拿到当前引用和版本号，不能分开调用 getReference() 和 getStamp()
- 每次 compareAndSet 都要基于这次读出的 stamp 值计算 newStamp，例如 oldStamp + 1
- 在循环重试场景中，每次失败后必须重新 get() 获取最新 stamp，否则用过期 stamp 会导致 CAS 总是失败
典型使用模式：带版本号的原子状态跃迁
以“仅允许从 INIT 切换到 PROCESSED”为例：
- 初始化：new AtomicStampedReference
("INIT", 0) - 尝试更新时先读：String cur = ref.get(stamp); int s = stamp[0];
- 执行 CAS：ref.compareAndSet("INIT", "PROCESSED", s, s + 1)
- 若返回 false，说明要么值已被改，要么版本号已变（即发生过 ABA），需重试或放弃
即使其他线程把状态从 INIT → TEMP → INIT，版本号也从 0 → 1 → 2，原始线程拿着 s=0 去 CAS 必然失败。
注意它不是银弹，适用边界要清楚
AtomicStampedReference 解决的是“引用被复用”类 ABA，比如对象池中的节点、链表指针、缓存 key 等。如果业务上 A→B→A 是合法且无害的状态迁移（如开关反复 toggling），那加版本号反而增加开销。
性能上，它比 AtomicReference 多一次字段读写，实测吞吐量低约 5%–15%；Android 平台需 API 24+ 才完整支持；stamp 溢出虽极少见，但若系统生命周期超长，可考虑 AtomicMarkableReference 或自定义 long 版本号。
