乐观锁 & 悲观锁
在正式讲解之前,我们先了解一下这两个概念
悲观锁
顾名思义,假使情况是最糟糕的,在程序中的提现就是对资源的抢夺。对于悲观锁来说,它总是认为每次访问共享资源时会发生冲突,所以必须对每次数据操作加上锁,以保证临界区的程序同一时间只能有一个线程在执行。
乐观锁
与其相反,乐观锁总是假设对共享资源的访问没有冲突,线程可以不停地执行,无需加锁也无需等待。而一旦多个线程发生冲突,乐观锁通常是使用一种称为CAS
的技术来保证线程执行的安全性。
因为没有锁,所以就不存在死锁
的情况。大家不放试想一下,他们分别适合什么样的场景
-
乐观锁多用于
读多写少
的环境,避免频繁加锁影响性能 -
悲观锁多用于
写多读少
的环境,避免频繁失败和重试影响性能
CAS
概述
CAS的全称是:比较并交换(Compare And Swap)。在CAS中,有这样三个值
- V:要更新的变量(var)
- E:预期值(expected) (也称为旧值)
- N:新值(new)
有没有很熟悉,上节我们讲源码的时候有提到过~ 大致过程如下:
判断更新的变量
是否等于预期值
,如果等于,将该值设置为新的值
;如果不等,说明已经有其它线程更新了变量
,则当前线程放弃更新,什么都不做。
那么会不会出现我即将要更新的值被其它线程更新了呢❓
不会的,原因在于CAS是一种原子操作。
原子操作
原子操作(atomic operation)
是指不被线程调度打断的操作,通常有一系列操作组合而成,该操作开始到执行结束,期间不会有任何线程切换,从而保证了cpu资源不会被其它线程争夺。简单的来说这种操作不会中断,要么成功,要么失败,可以保证线程的安全性。
当多个线程同时使用CAS操作一个变量时,只有一个成功更新,其余都失败,但失败的线程并不会被挂起,仅是被告知失败,并且允许再次尝
Java中的CAS操作具体实现
在Java中,通常使用sun.misc.Unsafe
类,该类下的方法都是native
方法,所以Java本身不负责具体实现,通常由底层的jvm,c,c++
来实现
public final native boolean compareAndSwapObject(Object o, long offset,
Object expected,
Object x);
public final native boolean compareAndSwapInt(Object o, long offset,
int expected,
int x);
public final native boolean compareAndSwapInt(Object o, long offset,
int expected,
int x);
这些操作都是和底层cpu以及操作系统
有关的,所以不同的操作系统下,它们的底层实现可能不太一样。在之前的学习中,我们遇到的一些源码,底层也是都有调用它的,这个大家了解一下就行。
既然它不是Java来实现,那么Java本身有没有借助它们实现一些好用的CAS
操作呢❓下面我们一起看一下
原子操作类
有时候大家可能注意到了,在java.util.concurrent.atomic
包下,JDK提供了一些好用的原子操作类,包名展开下面都是Atomic
开头的类名,从字面意思可以大致知道它们是操作不同类型,这里以比较常用的类AtomicInteger
为例
public final int getAndAdd(int delta) {
return unsafe.getAndAddInt(this, valueOffset, delta);
}
这个方法可以用原子方式将给定值添加到当前值。我们可以看到调用了unsafe
下的一个方法
private static final Unsafe unsafe = Unsafe.getUnsafe();
下面我们接着看 unsafe.getAndAddInt(this, valueOffset, delta);
public final int getAndAddInt(Object o, long offset, int delta) {
int v;
do {
v = getIntVolatile(o, offset);
// 以原子方式更新
} while (!compareAndSwapInt(o, offset, v, v + delta));
return v;
}
这里可以看到,如果CAS
操作失败,会自旋,直到成功,最后返回。猜一下,这里为什么用do
❓这个也很好理解,我们需要返回的是被其他线程改变之后的旧值了,因此放在了do循环体内。
CAS产生的问题
同样的,CAS
操作也会产生问题,下面一起看下有哪些问题
ABA问题
ABA问题,就是一个值原来是A,变成了B,又变回了A。这个时候使用CAS是检查不出变化的,但实际上却被更新了两次。
ABA问题的解决思路是在变量前面追加上版本号或者时间戳。从JDK 1.5开始,JDK的atomic包里提供了一个类AtomicStampedReference
类来解决ABA问题。
这个类的compareAndSet
方法的作用是首先检查当前引用是否等于预期引用,并且检查当前标志是否等于预期标志,如果二者都相等,才使用CAS设置为新的值和标志。
public boolean compareAndSet(V expectedReference,
V newReference,
int expectedStamp,
int newStamp) {
Pair<V> current = pair;
return
expectedReference == current.reference &&
expectedStamp == current.stamp &&
((newReference == current.reference &&
newStamp == current.stamp) ||
casPair(current, Pair.of(newReference, newStamp)));
}
循环时间长开销大
CAS多与自旋结合。如果自旋CAS长时间不成功,会占用大量的CPU资源。
我们可以通过JVM支持处理器提供的pause指令, 能让自旋失败时cpu睡眠一小段时间再继续自旋,从而使得读操作的频率低很多
只能保证一个共享变量的原子操作
给大家介绍两种方式:
-
使用提供的
AtomicReference
-
使用锁
结束语
本节主要给大家介绍了CAS和原子操作
,有些部分大家了解一下就好。下一节,带大家学习线程池
的基本使用 ~
关注关注,主页更多的java课程学习路线,笔记,面试等架构资料