AtomicStampedReference不能根治ABA，而是通过“引用+版本号”原子绑定实现可靠检测：每次结构性修改必须更新stamp，CAS要求二者同时匹配，值同但stamp变则失败，迫使重读最新状态；安全读取必须用get(int[]),stamp须基于本次读取值即时计算，不可硬编码或复用。
ABA 问题无法被“彻底根治”，但可以通过 AtomicStampedReference 的版本戳机制实现可靠检测与安全拦截——它不阻止 ABA 发生，而是让每次 CAS 都能明确感知中间是否被修改过。
为什么“根治”是误解？
ABA 是多线程下物理状态演化的自然结果（如节点被弹出→复用→压回），任何无锁算法都无法禁止其他线程对共享资源的合法操作。AtomicStampedReference 的目标不是消灭 ABA，而是打破“值相同 = 状态未变”的错误假设。
只要 stamp 在每次结构性修改时严格变更，哪怕值回到原样，CAS 也会因 stamp 不匹配而失败，迫使调用方重新读取最新状态再决策。
关键：stamp 必须与引用构成原子二元组
AtomicStampedReference 内部将引用和 int 类型的 stamp 封装为一个不可分割的 Pair
立即学习“Java免费学习笔记（深入）”；
- get(int[] stampHolder) 是唯一安全读取方式：一次 volatile 读同时拿到当前引用和对应 stamp，避免分开调用 getReference() 和 getStamp() 引发的竞态
- compareAndSet() 要求四参数：必须同时校验 expectedReference == 当前引用 且 expectedStamp == 当前 stamp，二者缺一不可
- 构造时传入初始值和初始 stamp（如 new AtomicStampedReference("A", 0)），后续所有更新都需主动管理 stamp 变更
正确使用 stamp 的三个硬性规则
stamp 本身无业务含义，只作“修改指纹”。它的有效性完全依赖业务逻辑的正确维护：
- 每次结构性变更都必须 bump stamp：例如无锁栈的 push/pop、链表指针重连、状态机跃迁等，即使新旧引用相同（如又压回 A），也要执行 stamp + 1
- newStamp 必须基于本次 get() 刚读到的 stamp 计算：不能硬编码（如写死 0→1），也不能跨操作复用同一 oldStamp；高并发下多个线程若同时基于 stamp==1 执行 +1，会写入相同 newStamp==2，导致漏判
- 绝不单独缓存或猜测 stamp：每个 compareAndSet 尝试前，都必须调用 get(int[]) 重新获取最新 pair；while 循环中，失败后要立即重读，而不是沿用上一轮的 stamp
常见翻车点与规避方式
很多“用了 AtomicStampedReference 却仍出现 ABA 误判”的问题，根源不在 API，而在使用方式：
- ❌ 错误：分开读 reference 和 stamp → getReference() + getStamp() 中间可能已被其他线程更新
- ✅ 正确：统一用 get(int[]) 获取原子快照
- ❌ 错误：在别处定义 static AtomicInteger stampSeq，然后 compareAndSet(..., stampSeq.get(), stampSeq.incrementAndGet()) → stamp 更新与引用更新不同步，非原子绑定
- ✅ 正确：所有更新都走 AtomicStampedReference 自身的 compareAndSet，stamp 增量由业务逻辑在 get 后即时计算
- ⚠️ 注意：stamp 是 32 位 int，溢出后变为 Integer.MIN_VALUE，长期超高频服务需评估 wrap-around 是否可接受（绝大多数场景无需干预）
