并发基石—CAS机制
a. 什么是CAS机制
CAS的全称为 Compare-And-Swap,它是一条CPU并发原语。
它的功能是判断内存某个位置的值是否为预期值 如果是则更改为新的值,这个过程是原子的。
CAS并发原语体现在JAVA语言中就是 sun.misc.Unsafe类中的各个方法。调用 UnSafe类中的CAS方法,JVM会帮我们实现出CAS汇编指令。这是一种完全依赖于硬件的功能, 通过它实现了原子操作。再次强调,由于CAS是一种系统原语,原语属于操作系统用语范畴,是由若干条指令组成的,用于完成某个功能的一个过程,并且原语的执行必须是连续的,在执行过程中不允许被中断,也就是说CAS是一条CPU的原子指令,不会造成所谓的数据不一致问题。
假设线程A和线程B两个线程同时执行 getAndAddInt操作(分别跑在不同CPU上):
1.AtomicInteger里面的vaue原始值为3,即主内存中 AtomicInteger的vaue为3,根据JMM模型,线程A和线程B各自持有份值为3的vaue的副本分别到各自的工作内存。
2.线程A通过 getIntVolatile(var1,var2)拿到vaue值3,这时线程A被挂起。
3.线程B也通过 getintVolatile(var1,var2)方法获取到vaue值3,此时刚好线程B没有被挂起并执行 compareAndSwaplnt方法比较内存值也为3,成功修改内存值为4,线程B打完收工,一切○K。
4.这时线程A恢复,执行 compareAndSwaplnt方法比较,发现自己手里的值数字3和主内存的值数字4不一致,说明该值已经被其它线程抢先一步修改过了,那A线程本次修改失败,只能重新读取重新来一遍了。
5线程A重新获取 value值,因为变量 value被 volatile修饰,所以其它线程对它的修改,线程A总是能够看到,线程A继续执
行 compareAndSwapInt进行比较替换,直到成功。
b. CAS机制优缺点
1.循环时间长开销很大
2.只能保证一个共享变量的原子操作
3.可能发生ABA问题
c. Java提供的CAS操作类—Unsafe类
1.Unsafe类是CAS的核心类,由于Java方法无法直接访问底层系统, 需要通过本地( native)方法来访问, Unsafe相当于一个后门,基于该类可以直接操作特定内存的数据。Unsafe类存在于sun.misc包中,其内部方法操作可以像C的指针一样直接操作内存,因为Java中CAS操作的执行依赖于 Unsafe类的方法。
注意 Unsafe类中的所有方法都是 native修饰的,也就是说 Unsafe类中的方法都直接调作系统底层资源行相应任务
2 变量 valueoffset, 表示该变量值在内存中的偏移地址, 因为 Unsafe就是根据内存偏移地址获取数据的。
/**
* Atomically increments by one the current value.
*
* @return the previous value
*/
public final int getAndIncrement() {
return unsafe.getAndAddInt(this, valueOffset, 1);
}
3.变量value用volatile修饰,保证了多线程之间的内存可见性
d. Unsafe类的使用
unsafe类一般作为一个静态变量存储在一个类里面,他可以类中某个属性的内存偏移地址,需要修改属性是传入类对应对象的实例,从而修改指定对象实例的属性值1.操纵对象属性
public native long objectFieldOffset(Field f);
通过此方法,可以获取类中某个属性的内存偏移地址,然后可根据偏移地址直接对对象的属性进行修改,属性是否可读都无所谓,都能修改。
2.操作数组元素public native int arrayBaseOffset(Class arrayClass);public native int arrayIndexScale(Class arrayClass);
3.线程挂起与恢复
将一个线程进行挂起是通过park方法实现的,调用 park后,线程将一直阻塞直到超时或者中断等条件出现。
unpark可以终止一个挂起的线程,使其恢复正常。整个并发框架中对线程的挂起操作被封装在 LockSupport类中,LockSupport类中有各种版本pack方法,但最终都调用了Unsafe.park()方法。
[
](https://blog.csdn.net/qi531621028/article/details/111121047)
e. CAS使用场景
- 使用一个变量统计网站的访问量;
- Atomic类操作;
- 数据库乐观锁更新。
f. ABA问题
CAS会导致“ABA问题”。
CAS算法实现一个重要前提需要取出内存中某时刻的数据并在当下时刻比较并替换,那么在这个时间差类会导致数据的变化。
比如说一个线程one从内存位置Ⅴ中取出A,这时候另一个线程two也从内存中取出A,
并且线程two进行了一些操作将值变成了B,然后线程two又将V位置的数据变成A,
这时候线程one进行CAS操作发现内存中仍然是A,然后线程one操作成功。
尽管线程one的CAS操作成功,但是不代表这个过程就是没有问题的。
原子引用
/*** 原子类引用*/@Data@AllArgsConstructorclass User {String userName;int age;}public class AtomicReferenceDemo {public static void main(String[] args) {User aaa = new User("aaa", 20);User bbb = new User("bbb", 30);// 创建原子引用包装类AtomicReference<User> atomicReference = new AtomicReference<>();// 现在主物理内存的共享变量,为aaaatomicReference.set(aaa);// 比较并交换,如果现在主物理内存的值为aaa,那么交换成bbbSystem.out.println(atomicReference.compareAndSet(aaa, bbb) + "\t " + atomicReference.get().toString());// 比较并交换,现在主物理内存的值是bbb了,但是预期为aaa,因此交换失败System.out.println(atomicReference.compareAndSet(aaa, bbb) + "\t " + atomicReference.get().toString());}}

解决ABA问题
新增一种机制,也就是修改版本号,类似于时间戳的概念
T1: 100 1 2020 2
T2: 100 1 127 2 100 3
如果T1修改的时候,版本号为2,落后于现在的版本号3,所以要重新获取最新值,这里就提出了一个使用时间戳版本号,来解决ABA问题的思路
AtomicStampedReference
时间戳原子引用,来这里应用于版本号的更新,也就是每次更新的时候,需要比较期望值和当前值,以及期望版本号和当前版本号
/*** 基于CAS引出ABA问题并采用AtomicStampedReference解决*/public class ABADemo {static AtomicReference<Integer> atomicReference = new AtomicReference<Integer>(100);static AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(100, 1);public static void main(String[] args) {System.out.println("============以下是ABA问题的产生==========");new Thread(() -> {// 把100 改成 101 然后在改成100,也就是ABAatomicReference.compareAndSet(100, 127);atomicReference.compareAndSet(127, 100);}, "t1").start();new Thread(() -> {try {// 睡眠一秒,保证t1线程,完成了ABA操作TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}// 把100 改成 101 然后在改成100,也就是ABASystem.out.println(atomicReference.compareAndSet(100, 2020) + "\t" + atomicReference.get());}, "t2").start();//main线程和gc线程之外如果还有线程就处于等待while (Thread.activeCount() > 2) {Thread.yield();}System.out.println("============以下是ABA问题的解决==========");new Thread(() -> {// 获取版本号int stamp = atomicStampedReference.getStamp();System.out.println(Thread.currentThread().getName() + "\t 第一次版本号" + stamp);// 暂停t3一秒钟try {TimeUnit.SECONDS.sleep(1);} catch (InterruptedException e) {e.printStackTrace();}// 传入4个值,期望值,更新值,期望版本号,更新版本号atomicStampedReference.compareAndSet(100, 127, atomicStampedReference.getStamp(), atomicStampedReference.getStamp()+1);System.out.println(Thread.currentThread().getName() + "\t 第二次版本号" + atomicStampedReference.getStamp());atomicStampedReference.compareAndSet(127, 100, atomicStampedReference.getStamp(), atomicStampedReference.getStamp()+1);System.out.println(Thread.currentThread().getName() + "\t 第三次版本号" + atomicStampedReference.getStamp());}, "t3").start();new Thread(() -> {// 获取版本号int stamp = atomicStampedReference.getStamp();System.out.println(Thread.currentThread().getName() + "\t 第一次版本号" + stamp);// 暂停t4 3秒钟,保证t3线程也进行一次ABA问题try {TimeUnit.SECONDS.sleep(3);} catch (InterruptedException e) {e.printStackTrace();}boolean result = atomicStampedReference.compareAndSet(100, 2020, stamp, stamp+1);System.out.println(Thread.currentThread().getName() + "\t 修改成功否:" + result + "\t 当前最新实际版本号:" + atomicStampedReference.getStamp());System.out.println(Thread.currentThread().getName() + "\t 当前实际最新值" + atomicStampedReference.getReference());}, "t4").start();}}

我们能够发现,线程t3,在进行ABA操作后,版本号变更成了3,而线程t4在进行操作的时候,就出现操作失败了,因为版本号和当初拿到的不一样
