AtomicStampedReference未自动解决ABA问题，需每次CAS前重新读取最新stamp并正确计算新值，否则仍会失效；其compareAndSet强制四参数以原子比对引用与版本号，分开读取或固定stamp将导致竞态或漏判。
AtomicStampedReference 不是“引入版本戳就自动解决 ABA”，它只是把检测 ABA 的责任交给你——你必须每次 compareAndSet 都基于刚读到的最新 stamp 计算新值，否则照样掉坑里。
为什么 compareAndSet 必须传四个参数，缺一不可
compareAndSet 方法签名强制要求 expectedReference、newReference、expectedStamp、newStamp 四个参数，是因为底层靠 Pair<V> 原子封装引用和版本号。只比值或只比 stamp 都会漏判。
- 如果只靠
AtomicReference，compareAndSet("A", "B")在 A→B→A 后仍会成功 - 这里哪怕
newReference == expectedReference（比如改回原值），只要newStamp != expectedStamp，CAS 就失败 - 编译器不会让你少传参数——少一个就报错，这是 API 层面的硬约束
get() 和 getReference()/getStamp() 的区别与陷阱
调用 get(int[] stampHolder) 是唯一能**原子读取“值+stamp”快照**的方式；而分开调用 getReference() 和 getStamp() 会产生竞态：两次读之间 stamp 可能已被其他线程更新。
- 正确写法：
int[] stamp = new int[1]; String current = ref.get(stamp); int oldStamp = stamp[0]; - 错误写法：
String current = ref.getReference(); int oldStamp = ref.getStamp();—— 这两行之间可能已有线程完成了一次 CAS -
getStamp()和getReference()是独立 volatile 读，不构成原子对
stamp 递增必须基于当前值，不能硬编码或固定偏移
常见翻车点：多个线程同时读到 stamp == 1，都执行 +1 写回 2，导致版本号“撞车”，ABA 检测失效。
- 这不是理论风险——在高并发下真实发生，尤其当业务逻辑中
compareAndSet失败后没重读就重试时 - 必须每次循环都重新
get()获取最新stamp，再计算oldStamp + 1 - 初始化时
new AtomicStampedReference("A", 0)没问题，但后续绝不能在别处写死compareAndSet("A", "B", 0, 1) - 如果需要更强的唯一性，可用
AtomicInteger单独管理全局序列号，但要确保它和引用更新是原子绑定的（AtomicStampedReference本身不提供这种能力）
Android 低版本和 stamp 溢出这两个坑容易被忽略
API 兼容性和整型溢出不是“理论上存在”，而是上线后才暴露的线上故障点。
- Android API 24 以下不支持
getStamp()等方法，调用直接抛NoSuchMethodError；必须用get(int[])回退方案 -
stamp是int，最大值2147483647。虽然日常极难溢出，但若用在高频计数器或长周期服务中，得考虑是否 wrap-around 后行为可接受（Integer.MAX_VALUE + 1 == Integer.MIN_VALUE） - 别假设“反正用不到那么多次”，关键路径上应加日志或监控，比如在
newStamp < oldStamp时告警
真正卡住人的从来不是 API 怎么写，而是“以为读了一次 stamp 就够了”或者“忘了 Android 24 以下没有 getStamp”。版本号机制本身很朴素，但把它嵌进真实线程调度节奏里，每一步都得对齐内存可见性边界。
