前言
本文是笔者在日常开发过程中遇到的对 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
- 看起来一样空包:其他线程修改堆中数据
- 发现包还在:仅检查栈中内存的地址值是否一致