Volatile

volatile是Java虚拟机提供轻量级的同步机制

1保证可见性

2不保证原子性

3禁止指令重排

• 什么是JMM？Java内存模型，并不存在，约定俗成

  一些约定：计算机中有主存，线程把变量读取到自己的工作内存

  1、线程解锁前，必须把共享变量刷回主存

  2、线程加锁前，必须读取主存中的最新值到工作内存中

  3、加锁解锁是同一把锁

  问题：当线程B把flag值修改刷回主内存时，线程B的工作内存的变量还是旧的

  volatile是Java虚拟机提供轻量级的同步机制

1保证可见性

2不保证原子性

3禁止指令重排

• 什么是JMM？Java内存模型，并不存在，约定俗成

  一些约定：计算机中有主存，线程把变量读取到自己的工作内存

  1、线程解锁前，必须把共享变量刷回主存

  2、线程加锁前，必须读取主存中的最新值到工作内存中

  3、加锁解锁是同一把锁

  问题：当线程B把flag值修改刷回主内存时，线程B的工作内存的变量还是旧的
  

不保证原子性，不可分割

小于20000
​
使用原子类解决原子性问题。原子类底层unsafe方法，CAS比较地址值

##指令重排：计算机并不一定会按照我们写的程序那样去运行
加了volatile会在上面下面加一层内存屏障，禁止指令重排
##单例模式

如果这样写，运行顺序就成了：

检查变量是否被初始化(不去获得锁)，如果已被初始化则立即返回。

获取锁。

再次检查变量是否已经被初始化，如果还没被初始化就初始化一个对象。

执行双重检查是因为，如果多个线程同时了通过了第一次检查，并且其中一个线程首先通过了第二次检查并实例化了对象，那么剩余通过了第一次检查的线程就不会再去实例化对象。

这样，除了初始化的时候会出现加锁的情况，后续的所有调用都会避免加锁而直接返回，解决了性能消耗的问题。

隐患
上述写法看似解决了问题，但是有个很大的隐患。实例化对象的那行代码（标记为error的那行），实际上可以分解成以下三个步骤：

分配内存空间
初始化对象
将对象指向刚分配的内存空间
但是有些编译器为了性能的原因，可能会将第二步和第三步进行重排序，顺序就成了：

分配内存空间
将对象指向刚分配的内存空间
初始化对象
现在考虑重排序后，两个线程发生了以下调用：

Time Thread A Thread B
T1 检查到uniqueSingleton为空
T2 获取锁
T3 再次检查到uniqueSingleton为空
T4 为uniqueSingleton分配内存空间
T5 将uniqueSingleton指向内存空间
T6 检查到uniqueSingleton不为空
T7 访问uniqueSingleton（此时对象还未完成初始化）
T8 初始化uniqueSingleton
在这种情况下，T7时刻线程B对uniqueSingleton的访问，访问的是一个初始化未完成的对象。

正确的双重检查锁

public class Singleton {
    private volatile static Singleton uniqueSingleton;

    private Singleton() {
    }

    public Singleton getInstance() {
        if (null == uniqueSingleton) {
            synchronized (Singleton.class) {
                if (null == uniqueSingleton) {
                    uniqueSingleton = new Singleton();
                }
            }
        }
        return uniqueSingleton;
    }
}

为了解决上述问题，需要在uniqueSingleton前加入关键字volatile。使用了volatile关键字后，重排序被禁止，所有的写（write）操作都将发生在读（read）操作之前。

至此，双重检查锁就可以完美工作了。

其实是因为枚举类型里面并没有无参构造器，所以没法通过反射破坏

通过乐观锁版本号解决ABA问题