什么是CAS
CAS(compareAndSwap),中文名称比较和替换,是一种无锁原子算法。
CAS过程
它包含3个参数CAS(V、E、N)
- V 代表要更新变量的值
- E 代表预期值
- N 代表新值
仅当V值等于E值时,才会将V的值设为N;
如果V值和E值不同,则说明已经有其他线程做了更新,则当前线程则什么都不做。最后,CAS返回当前V的真实值。
CAS操作时抱着乐观的态度进行的,它总是认为自己可以成功完成操作。
CAS的全称为Compare And Swap,是一条CPU的原子指令,作用就是让CPU先进行比较两个值是否相等,然后原子性地更新某个位置的值,实现方法就是基于硬件平台的汇编指令,在intel的CPU中,使用的是cmpxchg指令,就是说CAS 是考硬件实现的,从而在硬件层面提升效率。
当多个线程同时使用CAS操作一个变量时,只有一个会胜出,并成功更新,其余均会失败。失败的线程不会挂起,仅是被告知失败,并且允许再次尝试,当然也允许运行的线程放弃操作,基于这样的原理,CAS操作即使没有锁,也可以发现其他线程对当前线程的干扰。
CAS 底层原理
这样归功于硬件指令集的发展,实际上,我们可以使用同步将两个操作变成原子的,但是这么做就没有意义。所以我们只能靠硬件来完成,硬件保证一个从语义上看起来需要多次操作的行为,只通过一个处理器指令就能完成。
CPU实现原子指令的方法
1、通过总线锁定来保证原子性
总线锁定其实就是处理器使用了总线锁,所谓总线锁就是使用处理器提供的一个LOCK#信号,当一个处理器在总线上输出此信号时,其他处理器的请求将被阻塞住,那么该处理器可以独占共享内存。但是该方法成本太大。因此有了缓存锁定的方式。
2、通过缓存锁来保证原子性
缓存锁定就是指内存区域如果被缓存在处理器的缓存行中,并且在Lock操作期间被锁定,那么当他执行锁操作写回内存时,处理器不在总线上发出LOCK#信号,而是修改内存的内存地址,并允许他的缓存一致性机制来保证操作的原子性,因为缓存一致性机制会阻止同时修改两个以上处理器缓存的内存区域,当其他处理器回写已被缓存行锁定的数据时,会是缓存行失败,就无法写回数据至主内存中。
**注意**,一下情况不会市缓存行锁定:
1、当操作的数据不能被缓存在处理器内部,或操作的数据跨多个缓存行时,则处理器会使用总线锁定
2、有些处理器不支持缓存锁定,对于Intel486和Pentium处理器,就是锁定的内存区域在处理器的缓存行也会调用总线锁定。
CAS 举例
public class CASTest1 {
private static volatile int index = 0;
private static AtomicInteger m = new AtomicInteger(0);
public static void increace1() {
index++;
}
public static void increase2() {
m.incrementAndGet();
}
public static void main(String[] args) throws InterruptedException {
Thread[] tf1 = new Thread[20];
for (int i = 0; i < 20; i++) {
tf1[i] = new Thread(() -> {
CASTest1.increace1();
});
tf1[i].start();
tf1[i].join();//join方法加入,join会让其他线程等待自身执行完毕 再去执行其他线程
}
System.out.println(index);
Thread[] tf = new Thread[20];
for (int i = 0; i < 20; i++) {
tf[i] = new Thread(() -> {
CASTest1.increase2();
});
tf[i].start();
tf[i].join();
}
System.out.println("AtomicInteger=" + m.get());
}
}
CAS原理分析
javap -c 反编译字节码得出,两个自增操作的底层实现方式不同。
CAS源码分析
AtomicInteger类
//Unsafe类为 后门类,用来调用CPU指令
private static final Unsafe unsafe = Unsafe.getUnsafe();
//地址偏移量
private static final long valueOffset;
static {
try {
valueOffset = unsafe.objectFieldOffset
(AtomicInteger.class.getDeclaredField("value"));
} catch (Exception ex) { throw new Error(ex); }
}
// 要修改的值,保证可见性,
private volatile int value;
incrementAndGet() 自增方法
public final int incrementAndGet() {
return unsafe.getAndAddInt(this, valueOffset, 1) + 1;
}
/**
* var1: 要修改的值
* var2: 期望值
* var4: 最终目标值
*
* 举例 10=》12,要修改的值为10,期望值为10,最终目标值为12
* CAS 先检验修改的值是否与期望值相同,如果不同则其他线程进行过修改,如果相同,继续执行。
*/
public final int getAndAddInt(Object var1, long var2, int var4) {
int var5;
do {
var5 = this.getIntVolatile(var1, var2);
} while(!this.compareAndSwapInt(var1, var2, var5, var5 + var4));
return var5;
}
//这里进行JVM底层调用
@CallerSensitive
public static Unsafe getUnsafe() {
Class var0 = Reflection.getCallerClass();
if (!VM.isSystemDomainLoader(var0.getClassLoader())) {
throw new SecurityException("Unsafe");
} else {
return theUnsafe;
}
}
//最终调用本地方法
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
hotspot底层的CAS
Unsafe是CAS的核心类,Java无法直接访问底层操作系统,而是通过本地(native)方法来访问。不过尽管如此,JVM还是开了一个后门:Unsafe,它提供了硬件级别的原子操作。
ABA问题
CAS需要检查操作值有没有发生改变,如果没有发生改变则更新。但是存在这样一种情况:如果一个值原来是A,变成了B,然后又变成了A,那么在CAS检查的时候会发现没有改变,但是实质上它已经发生了改变,这就是所谓的ABA问题。对于ABA问题其解决方案是加上版本号,即在每个变量都加上一个版本号,每次改变时加1,即A —> B —> A,变成1A —> 2B —> 3A。
使用JDK提供的AtomicStampedReference类,解决ABA问题
public class CASTestABA {
//版本号解决ABA问题
//两个参数 初始值 版本号
private static AtomicStampedReference m = new AtomicStampedReference(100, 1);
public static void main(String[] args) {
Thread thread1 = new Thread(() -> {
try {
TimeUnit.SECONDS.sleep(2);
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("A result=" + m.compareAndSet(100, 110, m.getStamp(), m.getStamp() + 1));
System.out.println("B result=" + m.compareAndSet(110, 100, m.getStamp(), m.getStamp() + 1));
});
thread1.start();
Thread thread2 = new Thread(() -> {
int stamp = m.getStamp();//获取版本号
System.out.println("stamp=" + stamp);
try {
TimeUnit.SECONDS.sleep(3);
} catch (InterruptedException e) {
e.printStackTrace();
}
//ABA问题重现
// System.out.println("t2 result=" + m.compareAndSet(100, 120, stamp, stamp + 1));
//解决ABA问题
System.out.println("t2 result=" + m.compareAndSet(100, 120, m.getStamp(), m.getStamp() + 1));
});
thread2.start();
}
}
CAS优点
无锁,提升性能,CPU的吞吐量
与锁相比,使用CAS会使程序看起来更加复杂一些,但由于非阻塞,它对死锁问题天生免疫,并且,线程间的相互影响也非常小。更为重要的是,使用无锁方式完全没有锁竞争带来的系统开销,也没有线程间频繁调度带来的开销,因此,它要比基于锁的方式拥有更优越的性能。
简单的说,CAS需要你额外给出一个期望值,也就是你认为这个变量现在应该是什么样子的。如果变量不是你想象的那样,那就说明被别的线程修改过了,你就需要重新读取,再次尝试修改就好了。
CAS缺点
CAS虽然高效地解决了原子操作,但是还是存在一些缺陷,主要表现在三个方法:循环时间太长,只能保证一个共享变量的原子操作,ABA问题
- 循环时间太长
如果CAS一直不成功呢?如果自旋CAS长时间不成功,则会给CPU带来非常大的开销。在JUC中有些地方就限制了CAS自旋的次数,例如BlockingQueue的SynchronousQueue。
- 只能保证一个共享原子操作
CAS只能保证一个共享原子的操作,如果是多个共享变量就只能使用锁了,当然如果有办法把多个变量变成一个变量,利用CAS也不错,例如读写锁中state的高地位。
CAS应用场景
- 应用于简单的数据计算,jdk提供了很多Atomic类
- 适合线程冲突的场景,冲突多的时候,自旋CAS比较消耗性能资源