AtomicStampedReference通过绑定值与版本号（stamp）解决ABA问题，仅当值和stamp均匹配时CAS才成功；stamp需手动维护，初始化、读取和compareAndSet必须配套使用int[]数组传递stamp值。
为什么 AtomicStampedReference 能解决 ABA 问题
因为普通 compareAndSet 只比对值是否相等，而 ABA 发生时值“看起来没变”，但中间被改过又改回——这会骗过 CAS 判断。AtomicStampedReference 把值和一个版本号（stamp）绑定在一起，只有两者都匹配才成功，相当于给每次修改打上不可伪造的“时间戳”。
注意：这个 stamp 不是时间戳，也不是自增序列，它只是你手动维护的一个整数标记；Java 不帮你自动递增，你得自己管。
- 典型误用：只更新值、忘了更新 stamp，导致 stamp 始终为 0，等于没加锁
- 常见场景：链表栈/队列的无锁实现、资源池中对象的复用判断
- 性能影响：多一次 int 比较，几乎可忽略；但内存占用略高（额外存一个 int）
AtomicStampedReference 的正确初始化与读取方式
初始化时必须同时提供初始值和初始 stamp，不能只传值；读取当前值和 stamp 必须用 get(int[]) 方法，靠传入的数组接收 stamp，而不是 getter 分开拿。
示例：
立即学习“Java免费学习笔记（深入）”；
AtomicStampedReference<String> ref = new AtomicStampedReference<>("init", 0);
int[] stampHolder = new int[1];
String currentVal = ref.get(stampHolder); // stampHolder[0] 现在存着当前 stamp
- 错误写法：
ref.getStamp()不存在 —— 这个方法根本不存在，别瞎猜 - 常见坑：重用同一个
int[]数组多次调用get()，结果被覆盖，后续 compareAndSet 用错 stamp - 建议每次读取都新建数组或明确重置，避免隐式状态污染
怎么写安全的 compareAndSet 循环
和 AtomicReference 类似，但参数多两个：旧值、旧 stamp、新值、新 stamp。关键在于：旧 stamp 必须是刚刚读到的那个，不能硬编码或缓存太久。
典型结构是“读–改–比”三步闭环：
int[] stamp = new int[1]; String oldVal = ref.get(stamp); int oldStamp = stamp[0]; String newVal = oldVal + "_processed"; boolean success = ref.compareAndSet(oldVal, newVal, oldStamp, oldStamp + 1);
- 如果失败，说明期间有其他线程改过，需要重试（通常包在 while 循环里）
- 不要把 stamp + 1 写成 ++oldStamp —— 那会改变原值，下次循环读不到最新 stamp
- stamp 增量不强制为 1，按业务逻辑定；比如资源池中“已使用→已释放”可以 +2，避免单步误判
ABA 问题真被彻底解决了吗？几个容易被忽略的点
用了 AtomicStampedReference 并不等于 ABA 绝对消失，它只是把问题从“值是否变过”转移到“stamp 是否合理”。如果你的 stamp 设计本身有漏洞，照样翻车。
- stamp 溢出：int 最大值后变负，可能意外匹配旧值 —— 生产环境建议用
long或带溢出检查的封装 - stamp 语义不清：比如用时间戳但没处理时钟回拨，或用随机数却没保证全局唯一
- 业务逻辑绕过：CAS 成功只代表引用和 stamp 匹配，不代表对象内部状态合法 —— 比如 Node.next 被改过两次，但 stamp 恰好回到原值，这时你仍要校验 next 是否真实可达
真正难的从来不是换一个类，而是想清楚：你的 stamp 代表什么，谁负责更新它，以及失败后怎么恢复一致状态。
