compareAndSet不等于绝对线程安全，因其仅校验值是否变化而忽略修改过程，导致ABA问题；AtomicStampedReference通过版本号防ABA，AtomicMarkableReference仅适用于二元状态切换。
为什么 compareAndSet 不等于“绝对线程安全”
因为 compareAndSet 只校验值是否被改过，不关心“怎么被改的”。比如一个 Integer 对象从 100 → 200 → 100，CAS 看起来没变，就允许更新，但中间可能已发生业务语义上的覆盖。这就是 ABA 问题的根源——它不是并发失败，而是逻辑错误。
常见错误现象：AtomicInteger 在循环计数或状态机中反复重置时，出现意料外的更新成功；用 AtomicReference 管理链表节点时，删除-重插导致结构错乱。
- 使用场景：适合简单数值变更（如计数器）、无状态标志位（如
isInitialized）；不适合带生命周期或引用关系的数据结构 - 参数差异：
compareAndSet(expected, updated)中expected是按引用比较（==），对包装类必须注意缓存（如Integer.valueOf(100)在 -128~127 范围内复用对象） - 性能影响：无锁，避免阻塞，但高竞争下自旋重试会浪费 CPU；比
synchronized在低争用时快，高争用时未必
AtomicStampedReference 怎么加“时间戳”防 ABA
它把变量值和一个整型版本号（stamp）打包成一对，compareAndSet 同时校验二者。哪怕值变回原样，只要 stamp 不同，操作就被拒绝。
关键点不是“时间戳”，而是“每次修改都递增的版本标识”。JVM 不保证 stamp 是时间相关，只保证你主动更新它。
立即学习“Java免费学习笔记（深入）”；
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 必须自己维护 stamp：每次调用
compareAndSet前，要读当前值 + stamp，计算新值和新 stamp（通常stamp + 1） - 不能直接暴露内部 stamp：
getStamp()返回的是快照值，多线程下可能已失效；应配合get(int[] stampHolder)原子读取值与 stamp - 示例中常见错：只更新值、忘了递增 stamp，结果跟裸
AtomicReference行为一致
为什么 AtomicMarkableReference 只适合“标记切换”场景
它只带一个布尔标记（mark），不是数字版本号。适用于“开/关”“已处理/未处理”这类二元状态，无法区分多次翻转。
比如实现一个懒加载的单例：用 mark 标记“是否已初始化”，首次设为 true 后，后续 CAS 就不会再成功——这正是需要的；但如果要记录“第几次初始化”，它就不够用了。
- 适用场景：资源开关、一次性状态流转（如
isClosed）、带标记的指针（如并发跳表中的逻辑删除） - 不适用场景：需要追踪修改次数、恢复到某次历史状态、或要求严格顺序编号的场合
- 性能略优于
AtomicStampedReference：布尔值占空间小，CPU 缓存更友好；但语义窄，别硬套
ABA 真正难搞的地方不在 API，而在业务建模
用 AtomicStampedReference 能堵住 ABA 漏洞，但前提是：你知道哪一步操作该升版、哪一步不该升、升多少。比如链表节点删除时，是删节点本身升版，还是整个链表头升版？不同选择会导致完全不同的并发行为。
很多问题不是 CAS 不够强，而是把“业务状态变化”错误映射成了“内存值变化”。比如用 AtomicInteger 表示订单状态（1=待支付、2=已支付、3=已发货），一旦状态回滚（如发货失败退回到待支付），ABA 就悄悄发生了。
- 真正要检查的，不是“值有没有变过”，而是“变的过程是否符合业务约束”
- 复杂状态建议用显式状态机 +
synchronized或ReentrantLock，别强行上原子类 - 如果非要用原子引用，务必把业务版本（如订单版本号、更新时间戳）作为 stamp 的来源，而不是随便 ++
