volatile CAS 原子类 的重要知识点，短小精练

volatile 是一种轻量级的同步机制。

volatile 具有三个特点

1. 可以保证可见性
2. 无法保证原子性
3. 可以防止指令重排 

JMM（Java内存模型）

Java内存模型并非是一种实际存在的东西，它是一个概念。

Java内存模型需要保证三个特点：

1. 可见性
2. 原子性
3. 有序性 

1，3特点，都可以依靠volatile实现，第二个特点可以通过JUC包下的原子类来实现。

可见性 

      即当主内存中的共享变量发生改变时，让其它线程可以立即得知该变化，并更新各自工作内存变量的值。

原子性 

        即volatile 无法对i++这种看似是一条语句，实际上在底层是三条语句 （1、获取 i 变量的值；2、将 i 的值加1 ； 3、将值写回）

的语句实现同步。

指令重排 

      即在底层，编译器和处理器为了提高程序的性能，通常会对指令进行重排。在单线程中这种重排不会造成结果的不一致，但是在多线程环境下，就可以出现问题。指令的重排会受限于变量之间的逻辑关系，例如i 变量的声明不会被重排到使用之后。

volatile 实现防止指令重排的原理简单讲解

volatile 为了防止指令重排，会在volatile变量操作语句的前后，分别加上内存屏障（Memory  Barrier）

内存屏障可以让屏障上下的语句禁止重排。

volatile 的使用----单例模式（DCL实现）

DCL---double check lock 双端检测锁

代码说明：

1. volatile 防止指令重排的体现
   1. 由于new Singleton() 这句语句，在底层实际上是分为下面三个部分的。
      1. 第一个是，给对象分配空间
      2. 第二个是，对对象进行初始化
      3. 第三个是，让instance 指向刚刚分配的空间 ---- 在这一步，才算是完成了对象创建，instance ！= null
   2.  正是由于存在三个操作，并且三个操作在单线程的情况下顺序不会影响结果，因此就会出现指令重排的情况。在多线程情况下， 指令重排就可能导致下面的问题出现
      1. A线程执行的顺序是1 3 2，结果在第3步执行完，instance ！= null 
      2. 此时B线程进行if判断，发现不为空，就return instance，结果发现并未初始化，导致线程安全问题。
   3. 因此在这种情况下，需要将instance声明为 volatile，防止指令重排。

public class Singleton {
    private static volatile Singleton instance = null;

    private Singleton(){
        System.out.println(Thread.currentThread().getName() + "\t 构造方法" );
    }

    private static Singleton getInstance(){
        if(instance == null){
            synchronized (Singleton.class){
                if(instance == null){
                    instance =  new Singleton();
                }
            }
        }
        return instance;
    }

    public static void main(String[] args) {
        for(int i = 0; i < 10; i++){
            new Thread(() -> {
                Singleton.getInstance();
            },String.valueOf(i)).start();
        }
    }
}

 

原子类实现原子性的原理（CAS + 自旋锁）

CAS

比较并交换（compare and swap）

AtomicInteger atomicInteger = new AtomicInteger(5);  --------声明一个原子累
atomicInteger.compareAndSet(5, 2019)    ---------在操作前，比较当前值与5是否相等，如果相等，就进行赋值，如果不相等就更新值。

原子自增 atomicInteger.getAndIncrement() 的源码分析

public final int getAndIncrement() {
    return unsafe.getAndAddInt(this, valueOffset, 1);
}

对本代码，有几个问题需要说明

1. unsafe 类是什么
2. valueOffset 是什么
3. 是如何实现原子性的

unsafe 类

是CAS的核心类，由于Java无法直接访问底层，需要通过native方法访问。

unsafe 类可以直接操作特定内存的数据，通过valueOffset 获取数据

valueOffset 是内存偏移地址

下面的getAndAddInt 就是具体实现

可以看出，该方法的底层是用来一个do-while循环，也就是自旋锁的方式。

 

 假设线程A和线程B两个线程同时执行getAndAddInt操作(分别在不同的CPU上):
 
1.AtomicInteger里面的value原始值为3,即主内存中AtomicInteger的value为3,根据JMM模型,线程A和线程B各自持有一份值为3的value的副本分别到各自的工作内存.
 
2.线程A通过getIntVolatile(var1,var2) 拿到value值3,这是线程A被挂起.
 
3.线程B也通过getIntVolatile(var1,var2) 拿到value值3,此时刚好线程B没有被挂起并执行compareAndSwapInt方法比较内存中的值也是3 成功修改内存的值为4 线程B打完收工 一切OK.
 
 4.这是线程A恢复,执行compareAndSwapInt方法比较,发现自己手里的数值和内存中的数字4不一致,说明该值已经被其他线程抢先一步修改了,那A线程修改失败,只能重新来一遍了.
 
 5.线程A重新获取value值,因为变量value是volatile修饰,所以其他线程对他的修改,线程A总是能够看到,线程A继续执行compareAndSwapInt方法进行比较替换,直到成功.

CAS的缺点

1、 循环时间带来的开销比较大，占用CPU的资源多

2、 只能解决一个共享变量的原子性，当需要保证多个变量时，就使用锁

3、 会出现ABA的问题。

ABA问题

CAS算法的核心 就是比较并交换。但是会存在下列问题，被称为ABA问题

1. 即，当A将内容v1修改为v2后，又重新修改回v1
2. 此时当 B对内容进行CAS时，就会发现当时内容的值等于v1，因此操作成功
3. 但是这种方式是存在问题的，虽然结果看起来一致。

ABA问题解决的核心思路：

1. 就是利用一个版本号，记录下每次操作的版本号 （时间戳）AtomicStampedReference，

2. 然后当执行操作时需要比对value和stamp，只有当两者都相等时，才能执行操作。

原子引用 AtomicReference

AtomicReference是作用是对”对象”进行原子操作。 
提供了一种读和写都是原子性的对象引用变量。原子意味着多个线程试图改变同一个AtomicReference(例如比较和交换操作)将不会使得AtomicReference处于不一致的状态。

AtomicReference和AtomicInteger非常类似，不同之处就在于AtomicInteger是对整数的封装，底层采用的是compareAndSwapInt实现CAS，比较的是数值是否相等，而AtomicReference则对应普通的对象引用，底层使用的是compareAndSwapObject实现CAS，比较的是两个对象的地址是否相等。也就是它可以保证你在修改对象引用时的线程安全性。