关于java:volatile详解

volatile 的 3 个个性：

• 保障了各个线程之间的可见性
• 不能保障原子性
• 避免重排序

可见性：

首先，每个线程都有本人的工作内存，除此之外还有一个 cpu 的主存，工作内存是主存的正本。线程工作的时候，不能间接操作主内存中的值，而是要 将主存的值拷贝到本人的工作内存中；在批改变量是，会先在工作内存中批改，随后刷新到主存中。

留神： 什么时候线程须要将主存中的值拷贝到工作内存

• 线程中开释锁的时
• 线程切换时
• CPU 有闲暇工夫时（比方线程休眠时）

假如有一个共享变量 flag 为 false，线程 a 批改为 true 后，本人的工作内存批改了，也刷新到了主存。这时候线程 b 对 flag 进行对应操作时，是不晓得 a 批改了的，也称 a 对 b 不可见。所以咱们须要一种机制，在主存的值批改后，及时地告诉所有线程，保障它们都能够看到这个变动。

public class ReadWriteDemo {
    
    // 对于 flag 并没有加 volatile
    public boolean flag = false;
    public void change() {
        flag = true;
        System.out.println("flag has changed:" + flag);
    }

    public static void main(String[] args) {ReadWriteDemo readWriteDemo = new ReadWriteDemo();
        // 创立一个线程，用来批改 flag，如下面形容的 a 线程
        new Thread(new Runnable() {
            @Override
            public void run() {
                try {Thread.sleep(3000);
                    readWriteDemo.change();} catch (InterruptedException e) {e.printStackTrace();
                }
            }
        }).start();

        // 主线程，如下面形容的 b 线程
        while(!readWriteDemo.flag) { }
        System.out.println("flag:" + readWriteDemo.flag);
    }

}

依照剖析，没有加 volatile 的话，主线程（b 线程）是看不到子线程（a 线程）批改了 flag 的值。也就是说，在主线程看来，在没有非凡状况下，flag 永远为 false， while(!readWriteDemo.flag) {}的判断条件为 true，零碎不会执行到System.out.println("flag:" + readWriteDemo.flag);

为了防止必然性，我让程序跑了 6 分钟。能够看到，子线程的确批改了 flag 的值，主线程也和咱们预期一样，看不到 flag 的变动，始终在死循环。如果给 flag 变量加一个 volatile 呢，预期后果是，子线程批改变量对主线程来说是可见的，主线程会退出循环。

能够看到，都不到一分钟，在子线程批改 flag 的值后，主线程随即就退出循环，阐明立即感知到了 flag 变量的变动。

乏味的是什么呢：如果 ab 两个线程间隔时间不长，当 b 线程也提早 10s 读（不是下面的立即读），你会发现两个线程之间的批改 也是可见的，为什么呢，stakc overflow 上有解答，执行该线程的 cpu 有闲暇时，会去主存读取以下共享变量来更新工作内存中的值。更乏味的是，在写这篇文章的时候，cpu 及内存是这样的，反而能失常执行，然而能呈现问题就能阐明 volatile 的作用。

如何保障可见性：

首先要先讲一下 java 内存模型，java 的的内存模型规定了工作内存与主存之间交互的协定，定义了 8 中原子操作：

1. lock：将主内存的变量锁定，为一个线程所独占。
2. unlock：将 lock 加的锁定解除，此时其余线程能够有机会拜访此变量。
3. read：将主内存中的变量值读到工作线程中。
4. load：将 read 读取到的值保留到工作内存中的变量正本中。
5. use：将值传递给线程的代码执行引擎。
6. assign：将执行引擎解决返回的值从新赋值给变量正本。
7. store：将变量正本的值存储到主内存中。
8. write：将 store 存储的值写入到主内存的共享变量中。

我上网查了下材料，也看了不同的博客，有讲到 volatile 其实在底层就是加了一个 lock 的前缀指令。lock 前缀的指令要干什么下面也有写。如果对带有 volatile 的变量进行写操作会怎么呢。JVM 会像处理器发送一条 lock 前缀的指令，a 线程就锁定主存内的变量，批改后再刷新到主存。b 线程同样会锁定主存内的变量，然而会发现主存内的变量和工作内存的值不一样，就会从主存中读取最新的值。从而保障了每个线程都能对变量的扭转可见。

原子性：

在编程世界外面，原子性是指不能宰割的操作，一个操作要么全副执行，要么全副不执行，是执行的最小单元。

public class TestAutomic {
    volatile int num = 0;
    void add() {num++;}

    public static void main(String[] args) throws InterruptedException {TestAutomic testAutomic = new TestAutomic();
        for (int i = 0; i < 1000; i++) {new Thread(new Runnable() {
                @Override
                public void run() {
                    try {Thread.sleep(10);
                        testAutomic.add();} catch (InterruptedException e) {e.printStackTrace();
                    }
                }
            }).start();}
        // 期待 12 秒，让子线程全副执行完
        Thread.sleep(12000);
        System.out.println(testAutomic.num);
    }

}

预期景象：都说不能保障原子性了，所以，应该后果是不等于 1000

不同电脑执行的后果不一样，我的是 886，可能你们的不是，然而都阐明了 volatile 都无奈保障操作的原子性。

为什么不能保障原子性：

这要从 num++ 操作开始讲起，num++ 操作能够分为三步：

• 读取 i 的值，装载进工作内存
• 对 i 加 1 操作
• 将 i 的值写回工作内存，刷新到主存中

咱们晓得线程的执行具备随机性，假如 a 线程和 b 线程中的工作内存中都是 num=0，a 线程先抢了 cpu 的执行权，在工作内存进行了加 1 操作，还没刷新到主存中；b 线程这时候拿到了 cpu 的执行权，也加 1；接着 a 线程刷新到主存 num=1，而 b 线程刷新到主存，同样是 num=1，然而两次操作后 num 应该等于 2。

解决方案：

• 应用 synchronized 关键字
• 应用原子类

重排序：

对于咱们写的程序，cpu 会依据如何让程序更高效来对指令经行重排序，什么意思呢

a = 2;
b = new B();
c = 3;
d = new D();

通过优化后，可能实在的指令程序是：

a = 2;
c = 3;
b = new B();
d = new D();

并不是所有的指令都会重排序，重排序与否全是看能不能使得指令更高效，还有上面一种状况。

a = 2;
b = a;

这两行代码无论什么状况下都不会重排序，因为第二条指令是依赖第一条指令的，重排序是建设在排序后最终后果依然放弃不变的根底上。上面将给出 volatile 避免重排序的例子：

public class TestReorder {
    private static int a = 0, b = 0, x = 0, y = 0;

    public static void main(String[] args) throws InterruptedException {while (true) {
            a = 0; b = 0; x = 0; y = 0;
            // a 线程
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {Thread.sleep(10);
                        a = 1;
                        x = b;
                    } catch (InterruptedException e) {e.printStackTrace();
                    }

                }
            }).start();

            // b 线程
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {Thread.sleep(10);
                        b = 1;
                        y = a;
                    } catch (InterruptedException e) {e.printStackTrace();
                    }

                }
            }).start();

            // 主线程睡 100ms，以保障子线程全副执行完
            Thread.sleep(100);
            System.out.println("a=" + a + ";b=" + b + ";x=" + x + ";y=" + y);

        }
    }

}

还记得下面说过两个线程如果沉睡工夫差不多，它们之间是可见

预期后果：

• 如果先执行 完 a 线程（a = 1, x = b = 0），再执行 完 b 线程（b = 1, y = a = 1），最终后果 a = 1; b = 1; x = 0; y = 1
• 如果先执行 完 b 线程（b = 1, y = a = 0），再执行 完 a 线程（a = 1, x = b = 1），最终后果 a = 1; b = 1; x = 1; y = 0
• 如果执行 a 线程 过程 （a = 1），接着执行了 b 线程（b = 1，y = a = 1）【为什么 y = a 肯定等于1，因为它们两个之间的扭转是可见的】，最初执行了 a 线程（x = b = 1），最终后果 a = 1；b = 1; x = 1; y = 1

能够发现除了下面预期的三种状况，还呈现了一种 a = 1; b = 1; x = 0; y = 0的状况，置信大家也晓得了，这种状况就是因为重排序造成的。要么是 a 线程重排序先执行 x = b; 再执行 a = 1;，要么是 b 线程重排序先执行了y = a; 再执行了b = 1;；要么是两个线程都重排序了。

如果 private volatile static int a = 0, b = 0, x = 0, y = 0; 加了 volatile 关键字会怎么样呢？

为了保障正确性，又继续跑了 5 分钟，能够发现，的确不会再呈现 x=0;y=0 的状况。

如何避免重排序

先来讲讲 4 个内存屏障的作用

可能看作用比拟形象，间接举例子叭

• 对于S1; StoreStore; S2，在 S2 及后续写入操作之前，保障 S1 的写入操作对其它线程可见。
• 对于S; StoreLoad; L，在 L 及后续读 / 写操作之前，保障 S 的写入对其它线程可见。
• 对于L1; LoadLoad; L2，在 L2 及后续读操作之前，保障 L1 读取数据结束。
• 对于L; LoadStore; S，在 S 及后续操作之前，保障 L 读取数据结束。

那么 volatile 是如何保障有序性的呢？

• 在每个 volatile 写操作前插入 StoreStore 屏障，每个写操作前面加一个 StoreLoad 屏障。
• 在每个 volatile 读操作前插入 LoadLoad 屏障，在读操作后插入 LoadStore 屏障。

举例，有个对 volatile 变量的写 S，有个对 volatile 变量的读 L，会怎么样呢。

• 对于写：S1; StoreStore; S ;StoreLoad L这样可能把 S（对 volatile 变量爱护在两头）避免重排序。
• 对于读一样的情理：L1; LoadLoad; L ; LoadStore S，一样把 volatile 变量爱护的好好的。

无关 volatile 的解说就到这里了。