深入理解JVM之CAS原子操作(九)

在准备进入concurrentHashMap的源码世界中的时候,发现很多方法是基于CAS原子操作的,之前在看JVM的时候确实看过CAS,但是并没有仔细的去研究,所以决定先一探究竟,经过网上查阅一些资料,对CAS还是有了一些理解。

如果说在只有一个线程的时候,资源不会出现竞争,也不会存在所谓的共享资源的说法,很多问题可以避免,也无需讨论原子性操作的问题。但是当出现多个线程协调运行的时候,很多问题就会出现了,怎么提高多个线程访问共享资源的效率,如何避免多个线程并发读写共享资源时不出现数据混乱,这些问题都是在各个领域很经典的问题。

乐观锁与悲观锁

我们都知道,cpu是时分复用的,也就是把cpu的时间片,分配给不同的thread/process轮流执行,时间片与时间片之间,需要进行cpu切换,也就是会发生进程的切换。切换涉及到清空寄存器,缓存数据。然后重新加载新的thread所需数据。当一个线程被挂起时,加入到阻塞队列,在一定的时间或条件下,在通过notify(),notifyAll()唤醒回来。

在某个资源不可用的时候,就将cpu让出,把当前等待线程切换为阻塞状态。等到资源(比如一个共享数据)可用了,那么就将线程唤醒,让他进入runnable状态等待cpu调度。这就是典型的悲观锁的实现。独占锁是一种悲观锁,synchronized就是一种独占锁,它假设最坏的情况,认为一个线程修改共享数据的时候其他线程也会修改该数据,因此只在确保其它线程不会造成干扰的情况下执行,会导致其它所有需要锁的线程挂起,等待持有锁的线程释放锁。

但是,由于在进程挂起和恢复执行过程中存在着很大的开销。当一个线程正在等待锁时,它不能做任何事,所以悲观锁有很大的缺点。举个例子,如果一个线程需要某个资源,但是这个资源的占用时间很短,当线程第一次抢占这个资源时,可能这个资源被占用,如果此时挂起这个线程,可能立刻就发现资源可用,然后又需要花费很长的时间重新抢占锁,时间代价就会非常的高。

所以就有了乐观锁的概念,他的核心思路就是,每次不加锁而是假设修改数据之前其他线程一定不会修改,如果因为修改过产生冲突就失败就重试,直到成功为止。在上面的例子中,某个线程可以不让出cpu,而是一直while循环,如果失败就重试,直到成功为止。所以,当数据争用不严重时,乐观锁效果更好。比如CAS就是一种乐观锁思想的应用。

synchronized与volatile

在JDK 5之前Java语言是靠synchronized关键字保证同步的,这会导致有锁。既然说到了synchronized关键字,很容易会被拿来比较的就是volatile关键字,但是volatile并不是用来保证同步的,它的一个最大的最突出的特性就是「内存可见性」,意思就是当其他线程更改了一个值之后,这个值对其他线程是立即可见的,也就是说线程能自动读到volatile变量的最新值。但是,它并不能保证操作的原子性,比如计数器里面的典型的自增操作,自增操作中包含读-修改-写,这个操作显然需要具备原子性。如果用volatile变量作为共享字段当做计数器绝大可能是会出错的。所以,volatile与synchronized关键字不能相提并论,使用场景不同,具体volatile的详细可以参见这篇文章

CAS

概念理解

先上一张图,说明CAS的基本思想:

上图的解释:CPU(此处也可以是线程)去更新一个值,但如果想改的值不再是原来的值,操作就失败,因为很明显,有其它操作先改变了这个值。

CAS 操作包含三个操作数 —— 内存位置(V)、预期原值(A)和新值(B)。执行CAS操作的时候,将内存位置的值与预期原值比较,如果相匹配,那么处理器会自动将该位置值更新为新值。否则,处理器不做任何操作。

举个CAS操作的应用场景的一个例子,当一个线程需要修改共享变量的值。完成这个操作,先取出共享变量的值赋给A,然后基于A的基础进行计算,得到新值B,完了需要更新共享变量的值了,这个时候就可以调用CAS方法更新变量值了。

基于CAS的计数器

基于 CAS 的并发算法称为无阻塞算法,因为线程不必再等待阻塞。无论CAS操作成功还是失败,在任何一种情况中,它都在可预知的时间内完成。如果 CAS 失败,调用者不会被挂起而是可以重试CAS操作或采取其他适合的操作。用CAS实现一个计数器代码如下:

1
2
3
4
5
6
7
8
9
10
11
12
public class CasCounter {
private SimulatedCAS value;//假设SimulatedCAS实现了累加的CAS方法,如compareAndSwap(oldValue, oldValue + 1)
public int getValue() {
return value.getValue();
}
public int increment() {
int oldValue = value.getValue();
while (value.compareAndSwap(oldValue, oldValue + 1) != oldValue)
oldValue = value.getValue();
return oldValue + 1;
}
}

CAS伪代码实现

类似于 CAS 的指令允许算法执行读-修改-写操作,而无需害怕其他线程同时修改变量,因为如果其他线程修改变量,那么 CAS 会检测它(并失败),算法可以对该操作重新计算。下面代码说明了CAS操作的行为(而不是性能特征),但是CAS的价值是它可以在硬件中实现,并且是极轻量级的(在大多数处理器中)

1
2
3
4
5
6
7
8
9
10
public class SimulatedCAS {
private int value;
public synchronized int getValue() { return value; }
public synchronized int compareAndSwap(int expectedValue, int newValue) {
int oldValue = value;
if (value == expectedValue)
value = newValue;
return oldValue;
}
}

CAS的问题

CAS虽然很高效的解决原子操作,但是CAS仍然存在三大问题。ABA问题,循环时间长开销大和只能保证一个共享变量的原子操作。

  1. ABA问题。因为CAS需要在操作值的时候检查下值有没有发生变化,如果没有发生变化则更新,但是如果一个值原来是A,变成了B,又变成了A,那么使用CAS进行检查时会发现它的值没有发生变化,但是实际上却变化了。ABA问题的解决思路就是使用版本号。在变量前面追加上版本号,每次变量更新的时候把版本号加一,那么A-B-A 就会变成1A-2B-3A。从Java1.5开始JDK的atomic包里提供了一个类AtomicStampedReference来解决ABA问题。这个类的compareAndSet方法作用是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值。
  2. 循环时间长开销大。自旋CAS如果长时间不成功,会给CPU带来非常大的执行开销。
  3. 只能保证一个共享变量的原子操作。当对一个共享变量执行操作时,我们可以使用循环CAS的方式来保证原子操作,但是对多个共享变量操作时,循环CAS就无法保证操作的原子性,这个时候就可以用锁,或者有一个取巧的办法,就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量i=2,j=a,合并一下ij=2a,然后用CAS来操作ij。从Java1.5开始JDK提供了AtomicReference类来保证引用对象之间的原子性,你可以把多个变量放在一个对象里来进行CAS操作。

结束语

JDK 5.0 是开发高性能并发类的巨大进步。通过内部公开新的低级协调原语,和提供一组公共原子变量类,现在用 Java 语言开发无等待、无锁定算法首次变为可行。然后, java.util.concurrent 中的类基于这些低级原子变量工具构建,为它们提供比以前执行相似功能的类更显著的可伸缩性优点。虽然您可能永远不会直接使用原子变量,还是应该为它们的存在而欢呼。(摘自参考3)

参考

Java 多线程:CAS 与 AtomicInteger(乐观锁)
非阻塞同步算法与CAS(Compare and Swap)无锁算法
Java 理论与实践: 流行的原子

-EOF-