Thread线程安全之CAS 与 ABA 问题

CAS 与 ABA 问题

CAS（Compare and Swap）比较并交换，是一种『乐观锁』的实现，是用非阻塞算法来代替锁定，其中 java.util.concurrent 包下的 AtomicInteger 就是借助 CAS 来实现的。

但 CAS 也不是没有任何副作用，比如著名的 ABA 问题就是 CAS 引起的。

1. ABA 问题描述

小王去银行取钱，余额有 200 元，小王取 100 元，但因为程序的问题，启动了两个线程，线程一和线程二进行比对扣款，线程一获取原本有 200 元，扣除 100 元，余额等于 100 元。此时，小涂给小王转账 100 元，于是启动了线程三抢先在线程二之前执行了转账操作，把 100 元又变成了 200 元，而此时线程二对比自己事先拿到的 200 元和此时经过改动的 200 元值一样，就进行了减法操作，把余额又变成了 100 元。这显然不是我们要的正确结果，我们想要的结果是余额减少了 100 元，又增加了 100 元，余额还是 200 元，而此时余额变成了 100 元，显然有悖常理，这就是著名的 ABA 的问题。

执行流程如下。

• 线程一：取款，获取原值 200 元，与 200 元比对成功，减去 100 元，修改结果为 100 元。
• 线程二：取款，获取原值 200 元，阻塞等待修改。
• 线程三：转账，获取原值 100 元，与 100 元比对成功，加上 100 元，修改结果为 200 元。
• 线程二：取款，恢复执行，原值为 200 元，与 200 元对比成功，减去 100 元，修改结果为 100 元。

最终的结果是 100 元。

2. ABA 问题的解决

常见解决 ABA 问题的方案加版本号，来区分值是否有变动。以小王取钱的例子为例，如果加上版本号，执行流程如下。

• 线程一：取款，获取原值 200_V1，与 200_V1 比对成功，减去 100 元，修改结果为 100_V2。
• 线程二：取款，获取原值 200_V1 阻塞等待修改。
• 线程三：转账，获取原值 100_V2，与 100_V2 对比成功，加 100 元，修改结果为 200_V3。
• 线程二：取款，恢复执行，原值 200_V1 与现值 200_V3 对比不相等，退出修改。

最终的结果为 200 元，这显然是我们需要的结果。

---

在程序中，要怎么解决 ABA 的问题呢？

在 JDK 1.5 的时候，Java 提供了一个 AtomicStampedReference 原子引用变量，通过添加版本号来解决 ABA 的问题，具体使用示例如下：

String name = "小王";
String newName = "小涂";
AtomicStampedReference<String> as = new AtomicStampedReference<String>(name, 1);

log.debug("值：{} | Stamp：{}", as.getReference(), as.getStamp());

as.compareAndSet(name, newName, as.getStamp(), as.getStamp() + 1);

log.debug("值：{} | Stamp：{}",  as.getReference(), as.getStamp());

以上程序执行结果如下：

值：小王 | Stamp：1
值：小涂 | Stamp：2