什么是 Java 中的 ABA 问题？

【核心定义】 ABA 问题是指在并发编程中，一个共享变量的值从 A 变为 B，然后又变回 A，而使用 CAS（Compare-And-Swap）操作的线程会误认为该变量从未被修改过，从而导致逻辑错误的一种现象。

【关键要点】

1. 问题根源在于 CAS 的“值匹配”机制：CAS 操作仅比较变量的当前值与预期值是否相等，而不关心其变化历史。当值从 A -> B -> A 时，CAS 会认为“没有变化”，从而成功更新，但这可能掩盖了中间发生过其他操作的事实。
2. 典型场景是链表/栈的节点复用：例如，一个线程从链表中弹出节点 A（头节点变为 B），此时另一个线程先弹出 A，又将一个新节点（地址与 A 相同）压入，使头节点变回 A。第一个线程执行 CAS 比较头节点时，会误认为链表未被修改，导致数据错乱或丢失。
3. 解决方案是引入版本号或标记：通过为共享状态附加一个单调递增的版本号（如 AtomicStampedReference）或布尔标记（如 AtomicMarkableReference），在 CAS 时同时比较值和版本号，确保状态未被“轮回”。

【深度推导/细节】

• 逻辑拆解（以栈为例）：
  • 初始状态：栈顶为节点 A（版本号 1）。
  • 线程 T1：准备弹出 A，读取到当前栈顶 A（版本号 1），然后被挂起。
  • 线程 T2：成功弹出 A（栈顶变为 B，版本号递增为 2），随后又压入一个新节点 C（巧合地复用 A 的内存地址，栈顶变回“A”，但版本号递增为 3）。
  • 线程 T1：恢复执行，执行 CAS 操作，预期栈顶为“A”（版本号 1），实际栈顶为“A”（版本号 3）。若仅比较值，CAS 成功，栈顶被设置为 T1 预期的下一个节点，导致线程 T2 压入的节点 C 丢失。若同时比较版本号，CAS 失败，T1 需重试，从而避免问题。

【关联/对比】

• 与普通并发问题对比：ABA 不是数据不一致（如脏读），而是逻辑一致性问题。它发生在即使数据最终一致，但中间状态的变化对业务逻辑有影响的场景。
• AtomicInteger vs AtomicStampedReference：AtomicInteger 等原子类仅基于值进行 CAS，无法解决 ABA；AtomicStampedReference 通过封装 [reference, stamp] 配对，提供基于版本号的 CAS，是解决 ABA 的标准工具。

『面试官追问』

1. 在实际开发中，哪些场景必须考虑 ABA 问题？
   • 无锁数据结构：如自己实现的无锁栈、队列、链表等。
   • 内存回收系统：某些语言或框架（如 JVM 的偏向锁撤销）中，对象地址可能被复用。
   • 涉及“状态-资源”绑定的业务：如使用一个整数状态机表示订单流程（如 1->2->1），如果仅用 CAS 更新状态，可能忽略中间已处理过的关键步骤。
2. 除了 AtomicStampedReference，还有其他解决方案吗？
   • 使用不可变对象：如果共享变量指向的对象是不可变的（如 String、Integer），每次修改都创建新对象，引用地址必然不同，ABA 在值层面就不会发生（因为 A 和后来的 A 不是同一个对象）。
   • 使用互斥锁：彻底放弃 CAS，用锁保证整个操作的原子性，但会牺牲性能。
   • “Hazard Pointers”等高级无锁算法：用于 C++等系统编程，跟踪正在被访问的指针，防止其被复用。

【直击痛点】

• 为什么 AtomicStampedReference 能解决？ 其核心是 Pair 内部类，将 V reference 和 int stamp 捆绑为一个不可变对象。每次 CAS 都是对这个 Pair 整体的原子替换。版本号 stamp 单调递增，确保了状态历史的唯一性。
• ABA 一定会导致 bug 吗？ 不一定。如果业务逻辑只关心最终值，不关心中间变化过程（例如，一个简单的计数器），那么 ABA 是无害的。是否需要解决取决于业务语义。

【逻辑复现（解决版）】 以 AtomicStampedReference 解决上述栈的 ABA 问题：

1. 初始：栈顶引用 = Pair(A, stamp=1)。
2. T1：读取当前 Pair(A, stamp=1)，准备弹出。
3. T2：执行弹出，成功将栈顶 CAS 为 Pair(B, stamp=2)。随后压入新节点，成功 CAS 为 Pair(A, stamp=3)（注意，stamp 已变为 3）。
4. T1：尝试 CAS，预期 Pair(A, stamp=1)，实际 Pair(A, stamp=3)。值相同但 stamp 不同，CAS 失败。T1 重试读取最新状态，从而安全地继续操作。