Java中多线程的ABA问题探讨

缺乏、安全感 2023-09-26 17:26 33阅读 0赞

### 前言 ###

本文是笔者在日常开发过程中遇到的对 CAS 、 ABA 问题以及 JUC（`java.util.concurrent`）中 `AtomicReference` 相关类的设计的一些思考记录。 对需要处理 ABA 问题，或有诸如笔者一样的设计疑问探索好奇心的读者可能会带来一些启发。

本文主体由三部分构成：

1.  首先阐述多线程场景数据同步的常用语言工具
2.  接着阐述什么是 ABA 问题，以及产生的原因和可能带来的影响
3.  再探索 JUC 中官方为解决 ABA 问题而做一些工具类设计

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

> 受限于笔者的理解与知识水平，文章的一些术语表述难免可能会失偏颇，对于有理解歧义或争议的部分，欢迎大家探讨和指正。

### 一、异步场景常用工具 ###

在Java中的多线程数据同步的场景，常会出现：

1.  关键字 `volatile`
2.  关键字 `synchronized`
3.  可重入锁/读写锁 `java.util.concurrent.locks.*`
4.  容器同步包装，如 `Collections.synchronizedXxx()`
5.  新的线程安全容器，如 `CopyOnWriteArrayList/ConcurrentHashMap`
6.  阻塞队列 `java.util.concurrent.BlockingQueue`
7.  原子类 `java.util.concurrent.atomic.*`
8.  以及 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 类型在栈中保存的只是堆中对象数据块的地址，其结构形如下图：

![89d72ce6f56bcfb1130910fbc950657f.png][]

而实际运行过程中，调用 `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.  假设，线程 1 的任务希望将变量从 A 变为 C ，但执行到一半被线程 2 抢走 CPU
2.  线程 2 将变量从 A 改成了 B ，此时 CPU 时间片又被系统分给了线程 3
3.  线程 3 讲变量从 B 又设置成一个新的 A 。
4.  线程 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值）和预期是否一致的思想倒有异曲同工之妙。

### 总结 ###

通常在多线程场景中，这些工具的应用场景具有各自的适用特征：

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

[89d72ce6f56bcfb1130910fbc950657f.png]: https://img-blog.csdnimg.cn/img_convert/89d72ce6f56bcfb1130910fbc950657f.png