还记得上一篇文章当中提到的内存屏障（Memory Fence）吗？其实Volatile的实现原理就是通过内存屏障来实现的。
-
对于volatile修饰的变量：
- 在该变量的写指令后，会加入写屏障
- 在该变量的读指令前，会加入读屏障
上面先放个结论，后面我们逐步的看它是什么意思。
我们看下有如下的代码，主要是为了理解写屏障和读屏障是如何添加，且填在的位置在何处：
public class VolatileTest {
/**
* 定义一个volatile修饰的共享变量
*/
volatile static boolean flag = false;
/**
* 定义全局变量num
*/
static int num = 0;
public static void test1() {
num = 2;
// 此处修改数据ready，会增加一个写屏障，从而num、ready在修改数据后，都会添加到主存当中
flag = true;
}
public static void test2() {
// 此处读取数据ready，会增加一个读屏障，保证后面的ready和num都会从主存当中获取数据
if (flag) {
System.out.println(num);
}
}
public static void main(String[] args) {
new Thread(() -> {
test1();
}, "t1").start();
new Thread(() -> {
test2();
}, "t2").start();
}
}
如上所示，有volatile修饰的变量flag，假设上述代码t1先执行，t2后执行，会有如下过程：
t1执行test1方法，此时将num赋值称为2，num此时可能没有推送到主存当中。之后又执行了对flag赋值的操作，因为flag是volatile修饰的，所以一定会将flag更新到主存，同时将num也会更新到主存。
t2执行test2方法时，首先会读取flag的值，由于flag是有volatile修饰，此时会从主存拉取flag的值，同时num也会从主存获取。
一、可见性如何保证？
前文说到，写屏障对于共享变量的所有修改，在写屏障前的所有共享变量，都需要同步到主内存当中。
读屏障对于共享变量的所有修改，在读屏障后的所有共享变量，都需要同从主存当中获取。
在文章开始的例子当中已经阐述了流程：
在修改flag的值时，所依靠的是写屏障，会在flag被修改后的位置添加一个写屏障，在写屏障之前的的num、和flag修改后的值都会同步到主存当中。
在读取flag的值时，所依靠的是读屏障，在flag读取之前增加一份读屏障，在读屏障后读取的flag和num都会从主存当中获取。
二、有序性如何保证？
写屏障保证在发生指令重排序时，不会将写屏障之前的代码放在写屏障之后。
读屏障会确保指令重排序时，不会将读屏障后的代码放在读屏障之前。
假设在volatile关键字之前有多个变量被修改的语句，那么volatile是不能保证其执行的顺序，能保证的仅仅是在写屏障前的所有代码都执行完毕，并且写屏障前的修改对于读屏障后代码一定是可见的。
假如读取在写屏障之前，那么则不能保证了。
另外需要注意的是，有序性只保证在当前线程内的代码不被重排序。
三、happens-before原则
happens-before 规定了对共享变量的写操作对其它线程的读操作可见，可以说它是可见性与有序性的一套规则总结。
JMM（java memory model，java内存模型）在以下的情况可以保证，线程对共享变量的写，对于其他线程是读可见的，最常见的有以下两种：
-
使用synchronized关键字
前面的文章提到过，当使用重量级锁时，对于共享变量的修改时要同步到主存的。
使用volatile修饰的共享变量
还有以下场景（更多的不在下面举例了）：
当线程修改共享变量的值，其结束后，其他线程对于修改后的值是可见的。
线程start()之前，对于变量修改后的值，对其是可见的。
线程t1修改变量的值，随后对正在读取该变量的t2进行打断，此时t1打断线程t2，则t2对于修改后的变量读可见。
四、Double-Checked Locking
相信同学们都学习过单例模式，应该都知道其有很多种实现方式，其中有一种就是double-checked locking（双重检查锁）的方式，如下所示：
public class Singleton {
/**
* volatile 解决指令重排序导致的问题
*/
private static volatile Singleton instance;
public static Singleton getInstance() {
if (instance == null) {
synchronized (Singleton.class) {
if (instance == null) {
instance = new Singleton();
}
}
}
return instance;
}
private Singleton() {
}
}
通过我们的尝试知道DCL一定要加上volatile关键字去修饰实例变量instance，那么是为什么呢？
我们先假设没有加volatile关键字的情况，这种情况下砸多线程情况下是会存在问题的。
如下所示，是在没有添加volatile关键字时的字节码文件：
public class com.cloud.bssp.designpatterns.singleton.lazy.dcl.Singleton {
public static com.cloud.bssp.designpatterns.singleton.lazy.dcl.Singleton getInstance();
Code:
0: getstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
3: ifnonnull 37
6: ldc #2 // class com/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton
8: dup
9: astore_0
10: monitorenter
11: getstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
14: ifnonnull 27
17: new #2 // class com/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton
20: dup
21: invokespecial #3 // Method "<init>":()V
24: putstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
27: aload_0
28: monitorexit
29: goto 37
32: astore_1
33: aload_0
34: monitorexit
35: aload_1
36: athrow
37: getstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
40: areturn
Exception table:
from to target type
11 29 32 any
32 35 32 any
}
我们需要了解的是，jvm创建一个完整的对象实例需要两个步骤：
实例化一个对象，即new 出来的对象，此时是一个默认的空对象，其属性等并没有赋值，只是创建了引用，我们可以认为此时是一个半初始化对象。
初始化步骤，此时需要去调用对象的构造方法，完成属性的赋值等操作，只有经过此步骤才是一个完成的对象。
对应到上面的字节码文件，分别是以下的代码：
- 17：创建一个引用，将引用入栈
- 20：复制地址引用，用于后面使用
- 21：通过前面复制的地址引用，调用对象的构造方法
- 24：将引用赋值到静态变量instance上
相信同学们应该能够对应的上的。
在jvm中呢，如果完全按照上面的步骤执行则不会有问题，但是jvm会优化为先执行24步骤，再执行21步骤，那么结果可想而知，此时静态变量是一个半初始化的对象。
当另外的线程来执行getInstance方法时，获取静态实例对象instance，即字节码文件的第0行，此行代码是在锁synchronized（管程monitorenter）之外，谁来都可以执行，那么获取到了就是半初始对象，不是null，那么一定是有问题的。
通过我们前面的学习，就可以用volatile来解决DCL的这个问题：
这个volatile关键字在字节码是体现不出来的，但是手动标记一下它的位置，只保留主要位置：
0: getstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
--------------------- 此处加入读屏障 --------------------
3: ifnonnull 37
6: ldc #2 // class com/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton
8: dup
9: astore_0
10: monitorenter
11: getstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
14: ifnonnull 27
17: new #2 // class com/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton
20: dup
21: invokespecial #3 // Method "<init>":()V
24: putstatic #1 // Field instance:Lcom/cloud/bssp/designpatterns/singleton/lazy/dcl/Singleton;
--------------------- 此处加入写屏障 --------------------
27: aload_0
28: monitorexit
但是根据我们前面学习的，写屏障似乎并不能保证21和24的顺序不变啊，因为都是在写屏障之前，它只能保证写屏障之前的代码不会被放到写屏障后。那么它是如何解决的呢？
其实在更加底层volatile转成汇编语言，是在该代码上增加了lock前缀，此时会将其之前的代码锁住，直到执行到这个lock，此时前面的代码都一定执行完了。
从根本说volatile的实现是是一条CPU原语 lock addl。
太过底层就不多赘述了，毕竟我也没学到位呢！！！！
