Java中多线程的ABA问题探讨

转载

测评员老杜 2022-12-26 16:19:24

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 问题

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)
        }
    }
}
复制代码

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 类型在栈中保存的只是堆中对象数据块的地址，其结构形如下图：

Java中多线程的ABA问题探讨_java_02

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
复制代码