但愿是volatile的最后一次理解

第一次理解：

刚学java时，对于volatile的记忆就是：

• volatile保证可见性
• volatile防止指令重排序
• volatile不保证原子性

没过脑的背了一下，写代码的时候也没用到过，觉得不重要，而后就不了了之。

第二次理解

一段代码引发好奇

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

上图为比较经典的dcl（dubbo check lock）单例模式，双重if判断是为了防止多线程屡次建立，可是instance属性为何还要加个volatile关键字呢，有什么做用么？
其实它的做用主要体如今禁止指令重排序。

首先先理解下什么叫指令重排序？
指令重排序能够说是jvm对程序执行的一个优化，他能够保证普通的变量在方法执行的过程当中全部依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操做的顺序与程序代码中写的顺序保持一致。如

x = 1;
y = 2;

这两条赋值语句之间没有依赖关系，因此在具体执行时可能会先赋值y在赋值x，发生了指令重排。
而上述DCL代码中虽然表面只有这instance = new Singleton();一条语句，可是这个赋值操做编译成字节码文件后是分为3个步骤来完成的：

1. 为对象开辟内存空间并赋默认值
2. 调用构造函数为对象赋初始值
3. 将instance引用指向刚开辟的内存地址

而程序在执行这三步时，会有可能先执行3再执行2，若是发生这种状况，线程一先将引用指向地址，还没来得及执行构造方法，线程二进来判断instance！=null 直接拿这半初始化的对象去使用，就出现了问题。
因此此处须要用volatile关键字来修饰变量，禁止指令重排序状况的发生。那么volatile是如何作到禁止重排序的呢？
《深刻理解java虚拟机》中这样写道：

咱们对volatile修饰的变量进行编译后发现，在赋值操做后多执行了一个“lock addl $0x0,(%esp)”,这个操做至关于一个内存屏障（Memory Barrier 或 Memory Fence，指重排序时不能把后面的指令重排序到内存屏障以前的位置）

也有别的博主这样写道：

JMM为volatile加内存屏障有如下4种状况：
在每一个volatile写操做的前面插入一个StoreStore屏障，防止写volatile与后面的写操做重排序。
在每一个volatile写操做的后面插入一个StoreLoad屏障，防止写volatile与后面的读操做重排序。
在每一个volatile读操做的后面插入一个LoadLoad屏障，防止读volatile与后面的读操做重排序。
在每一个volatile读操做的后面插入一个LoadStore屏障，防止读volatile与后面的写操做重排序。

第三次理解

那么保证可见性又是指什么东东？
要想理解这可见性，须要先了解java内存模型（jmm）。学过计算机的同窗都知道多核cpu中每一个cpu都有本身的高速缓存，如L1,L2,L3，且每一个cpu之间的缓存是隔离的，即数据不可见。而多个cpu又共享一个主内存，数据通常会从磁盘读取到主内存当中，当cpu须要处理数据时，须要从主内存读取数据到本身的缓存当中而后进行运算，运算结束后将最新数据同步回内存之中。固然这种模型也伴随这缓存一致性问题的出现。
其实java内存模型和cpu模型很是的相似：
每一个线程拥有本身的工做内存，而后共享的变量会存放在主内存（jvm的内存）当中，线程之间工做内存互相隔离。如图：

上图来源于《深刻理解java虚拟机363页》

咱们再来看个容易理解的图：

再回到咱们的保证可见性的探讨：
如上图所示，若线程A和B都操做主内存的共享变量时，AB会将共享变量先拷贝会本身的工做内存，在A率先完成修改完以后再同步刷回到主内存当中，此时线程B本地内存的数据仍是最早拷贝的旧数据，没有及时的获取到已修改的最新数据，最后会形成数据不一致问题。
而volatile修饰变量时，它会保证修改的值会当即被更新到主存，并通知其余线程当前缓存的变量已失效，须要从新到主内存中读取。
底层也是经过内存屏障来保证的。
针对这个特性，常见的使用的场景为状态标记量

public class VolatileTest1 {
    volatile static boolean flag = false;

    public static void main(String[] args) {
        new Thread(() -> {
            System.out.println("t1 start");
            while (!flag){
                System.out.println("doing something");
            }
        },"t1").start();

        try {
            TimeUnit.SECONDS.sleep(1);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        flag = true;
    }
}

和咱们指望的同样，1秒后，程序正常中止。
可是好奇的我开始思考，那是否是只要不加volatile，程序就不会中止？当即更新的反义词是什么？正常状况下，线程会不会，何时会把修改的值写会主内存，别的线程又会何时会去从新读取？
带着好奇我把上诉代码中的volatile去掉，运行结果如图：

没错 程序竟然正常停掉了！
而后我又把while循环里的system输出去掉后，再次运行：

此次又没有中止！！
难道就是由于一句输出语句的问题么？我又尝试换成i++试试：

此次也没有中止！！！
很神奇，搞得我也很懵逼！！！
我不知道是否是由于环境的缘由，我用的jdk11和8，idea2020.1.2，
我的初步猜想：不加volatile，即正常状况下，本地线程更新值后，会很快的写回主内存，而其余线程何时从新从主内存中读取是不肯定的。
上述while代码里面执行点稍微费时的操做（如输出，sleep 1s），都是能够中止的，若是循坏太快，它可能没时间去从新读取flag的值。
（但愿有大佬看到小弟的这篇文章，并指点一二。）

第四次理解

那不保证原子性又是什么鬼？
原子性：保证指令不会受到线程上下文切换的影响，即一个操做不会被cpu切换所打断。
咱们举一个最多见的案列来讲明：
多个线程对同一个数字进行++操做：

public class VolatileDemo {
    public volatile int inc = 0;

    public void increase() {
        inc++;
    }

    public static void main(String[] args) {
        final VolatileDemo test = new VolatileDemo();
        System.out.println("start");

        for (int i = 0; i < 20; i++) {
            new Thread(() -> {
                for (int j = 0; j < 10000; j++) {
                    test.increase();
                }
            }).start();
        }

        while (Thread.activeCount() > 2) {
            Thread.yield();
        }
        System.out.println(test.inc);
    }
}

咱们启动了20个线程对inc进行++操做，每一个线程＋10000，理想结果应该为200000，可是实际运行结果却小于这个值，并且结果每次都不同（能够多运行几回观察）：

这是为何呢，程序中inc已经加了volatile修饰，保证了线程的可见性，可是为何结果仍是会比预想的小呢？
这是由于++操做并非简单的一步操做，即他不是原子性的，查看编译后的字节码文件，++的实际操做为：
（实事求是地说，使用字节码来分析并发问题仍然是不严谨的，由于即便编译出来只有一条字节码指令，也并不意味执行这条指令就是一个原子操做。一条字节码指令在解释执行时，解释器要运 行许多行代码才能实现它的语义。若是是编译执行，一条字节码指令也可能转化成若干条本地机器码 指令。）

public void increase();
    Code:
       0: aload_0
       1: dup
       2: getfield      #2                  // Field inc:I
       5: iconst_1
       6: iadd
       7: putfield      #2                  // Field inc:I
      10: return

inc++操做分红了2.获取字段 5.准备常数1 6.进行加1操做 7.赋值 四步
不保证原子性，即没法确保这四步操做不会被cpu切换打断：

如图cpu在线程1修改完以后还未写入内存时，切换到线程2，执行完了++操做，此时cpu切换回线程1又把inc=1 写回去，形成了inc的值被覆盖。
咱们再看下普通的赋值操做的字节码文件 如：x=1

public void fun1(){
        inc = 1;
    } 
// 编译后
 public void fun1();
    Code:
       0: aload_0
       1: iconst_1
       2: putfield      #2                  // Field inc:I
       5: return

他没有getfield和add的操做，直接赋值，因此赋值操做算是原子性的。

而synchronized是如何保证原子性的呢？
经过字节码文件咱们能够发现，用synchronized修饰真的代码块在先后会执行monitorenter和monitorexit指令，这minitor指令底层则是经过lock和unlock来知足原子性的，他只容许同时只有一个线程来操做资源。

推荐一篇很详细很全面的文章，此篇部分文字也有参考以下文章：

https://www.cnblogs.com/bangi...