关于后端:Java中多线程的ABA问题探讨

前言
  本文是笔者在日常开发过程中遇到的对 CAS 、 ABA 问题以及 JUC（java.util.concurrent）中 AtomicReference 相干类的设计的一些思考记录。
对须要解决 ABA 问题，或有诸如笔者一样的设计疑难摸索好奇心的读者可能会带来一些启发。
本文主体由三局部形成：

首先论述多线程场景数据同步的罕用语言工具
接着论述什么是 ABA 问题，以及产生的起因和可能带来的影响
再摸索 JUC 中官网为解决 ABA 问题而做一些工具类设计

文章的最初会对多线程数据同步罕用解决方案做了简短地经验性总结与概括。

受限于笔者的了解与常识程度，文章的一些术语表述不免可能会失偏颇，对于有了解歧义或争议的局部，欢送大家探讨和斧正。

一、异步场景常用工具
在Java中的多线程数据同步的场景，常会呈现：

关键字 volatile
关键字 synchronized
可重入锁/读写锁 java.util.concurrent.locks.*
容器同步包装，如 Collections.synchronizedXxx()
新的线程平安容器，如 CopyOnWriteArrayList/ConcurrentHashMap
阻塞队列 java.util.concurrent.BlockingQueue
原子类 java.util.concurrent.atomic.*
以及 JUC 中其余工具诸如 CountDownLatch/Exchanger/FutureTask 等角色。

  其中 volatile 关键字用于刷新数据缓存，即保障在 A 线程批改某数据后，B 线程中可见，这外面波及的线程缓存和指令重排因篇幅起因不在本文探讨范畴之内。而不论是 synchronized 关键字下的对象锁，还是基于同步器 AbstractQueuedSynchronizer 的 Lock 实现者们，它们都属于乐观锁。而在同步容器包装、新的线程程平安容器和阻塞队列中都应用的是乐观锁；只是各类的外部应用不同的 Lock 实现类和 JUC 工具，另外不同容器在加锁粒度和加锁策略上别离做了解决和优化。
  这里值得一说的，也是本文聚焦的重点则是原子类，即 java.util.concurrent.atomic.* 包下的几个类库诸如 AtomicBoolean/AtomicInteger/AtomicReference
二、CAS 与 ABA 问题
  咱们晓得在应用乐观锁的场景中，如果有有一个线程领先获得了锁，那么其余想要取得锁的线程就得被阻塞期待，直到占锁线程实现计算开释锁资源。而古代 CPU 提供了硬件级指令来实现同步原语，也就是说能够让线程在运行过程中检测是否有其余线程也在对同一块内存进行读写，基于此 Java 提供了应用忙循环来取代阻塞的系列工具类 AutomicXxx，这属于是一种乐观锁的实现。其惯例应用形式形如：
public class Requester {

private AtomicBoolean isRequesting = new AtomicBoolean(false)public void request() {    // 批改胜利时返回true；compareAndSet 办法由 Native 层调硬件指令实现    if (!isRequesting.compareAndSet(false, true)) {        return;    }    try {        // do sth...    } finally {        isRequesting.set(false)    }}

}
复制代码
  进入到 JDK11 AtomicBoolean 的源码中，能够看到 compareAndSet 最终调用 Native 层的形式如下。其实在旧的版本中 JDK 是应用 Unsafe 类解决的，在入参数中有传入状态变量的字段偏移值，新版本则将两者封装到 VarHandle 中采纳DL形式查找依赖（笔者猜想可能和JDK9模块化革新无关）：
// 旧版
public class AtomicBoolean {

private static final sun.misc.Unsafe U = sun.misc.Unsafe.getUnsafe();private static final long VALUE;static {    try {        VALUE = U.objectFieldOffset            (AtomicBoolean.class.getDeclaredField("value"));    } catch (ReflectiveOperationException e) {        throw new Error(e);    }}private volatile int value;public final boolean compareAndSet(boolean expect, boolean update) {    return U.compareAndSwapInt(this, VALUE, (expect ? 1 : 0), (update ? 1 : 0));}

}

// 新版
public class AtomicBoolean {

private static final VarHandle VALUE;static {    try {        MethodHandles.Lookup l = MethodHandles.lookup();        VALUE = l.findVarHandle(AtomicBoolean.class, "value", int.class);    } catch (ReflectiveOperationException e) {        throw new ExceptionInInitializerError(e);    }}private volatile int value;public final boolean compareAndSet(boolean expectedValue, boolean newValue) {    return VALUE.compareAndSet(this, (expectedValue ? 1 : 0), (newValue ? 1 : 0));}

}
复制代码
  犹如入仓有 this 和 value 的偏移值，则 Native 层可依据此二者值定位到某块栈内存，这样对于根本类型没什么问题。原子类型体系中应用 AtomicReference 来援用复合类型实例，但 Java 中 Object 类型在栈中保留的只是堆中对象数据块的地址，其构造形如下图：

  而理论运行过程中，调用 AtomicReference#compareAndSet() 时，Native层只会比照栈中内存的值，而不会关注其指向的堆中数据。这样说可能有点形象，看一段试验代码：
StringBuilder varA = new StringBuilder("abc");
StringBuilder varB = new StringBuilder("123");

AtomicReference<StringBuilder> ref = new AtomicReference<>(varA);
ref.compareAndSet(varA, varB); // (1)
System.out.println(ref.get()); // (2) varB->123
varB.append('4'); // (3) changed varB->1234
if (ref.compareAndSet(varB, varA)) { // (4)

System.out.println("CAS succeed"); // (5) CAS succeed

}
System.out.println(ref.get()); // abc
复制代码

喜爱入手的读者能够尝试自定义一个类，察看下 Compare 过程是否真的没有调用对象的 equals 办法。

  ref 在通过解决后再 (2) 处援用变量B，而在正文 (3) 处将 B 值批改了，但因为原子类不会查看堆中数据，所以还是能通过正文 (4) 处的相等比拟走到正文 (5) 。这也就引入了 所谓的 ABA 问题：

假如，线程 1 的工作心愿将变量从 A 变为 C ，但执行到一半被线程 2 抢走 CPU
线程 2 将变量从 A 改成了 B ，此时 CPU 工夫片又被零碎分给了线程 3
线程 3 讲变量从 B 又设置成一个新的 A 。
线程 1 获取工夫片，查看变量发现其依然是 A（但 A 对象外部的数据曾经扭转了），查看通过将变量置为 C 。

  若业务场景中，线程 1 不在意变量通过了一轮变动，也不在意 A 中数据是否有变动，则该问题无关痛痒。而若线程 1 对这两个变动敏感，则将变量置为 C 的操作就不合乎预期了。用维基百科的例子来表述，其粗心是:

你提着有很多现金的包去机场，这时来了个辣妹撩拨你，并趁你不留神时用一个看起来一样的空包换了你的现金包，而后她就走了；此时你查看了下发现你的包还在，于是就匆忙拿着包赶飞机去了。

换个角度看这几个关键字:

有现金的包：指向堆中数据的栈援用
辣妹撩拨：其余线程抢占 CPU
看起来一样空包：其余线程批改堆中数据
发现包还在：仅查看栈中内存的地址值是否统一

三、用 JUC 工具解决 ABA 问题
  为解决 ABA 问题，JDK 提供了另外两个工具类：AtomicMarkableReference 和 AtomicStampedReference 他们除了比照栈中对象的援用地址外，另外还保留了一个 boolean 或 int 类型的标记值，用于 CAS 比拟。
StringBuilder varA = new StringBuilder("abc");
StringBuilder varB = new StringBuilder("123");

AtomicStampedReference<StringBuilder> ref = new AtomicStampedReference<>(varA, varA.toString().hashCode());
ref.compareAndSet(varA, varB, varA.toString().hashCode(), varB.toString().hashCode());
System.out.println(ref.get(new int[1]));
varB.append('4');
// CAS失败，因为Stamp值对不上
if (ref.compareAndSet(varB, varA, varB.toString().hashCode(), varA.toString().hashCode())) {

System.out.println("compareAndSet: succeed");

}
System.out.println(ref.get(new int[1]));
复制代码
注：这种设计和为疾速判断文件是否雷同，而比拟文件摘要值（MD5、SHA值）和预期是否统一的思维倒有殊途同归之妙。
总结
  通常在多线程场景中，这些工具的利用场景具备各自的实用特色：

若各线程读写数据没有竞争关系，则可思考仅应用 volatile 关键字；
若各线程对某数据的读写须要去重，则可优先思考应用乐观锁实现，即用原子类型；
若各线程有竞争关系且不去重必须按程序抢占某资源，即必须用锁阻塞，若没有多条件队列的诉求则可先思考应用 synchronized 增加对象锁（但需注意锁对象的不可变和私有化），否则思考用 Lock 实现类，但特地的如需读写分锁以实现共享锁则只能用 Lock 了。
若需应用线程平安容器，出于性能思考优先思考 java.util.concurrent.* 类，如 ConcurrentHashMap、CopyOnWriteArrayList；再思考应用容器同步包装 Collections.synchronizedXxx()。而阻塞队列则多用于生产-生产模型中的工作容器，典型如用在线程池中。