在java中，为了保证某种资源只被初始化一次，我们通常会将其放入同步代码块中，如:
public synchronized Resource getResource(){
if (resource == null){
resource = new Resource();
}
return resource;
}
上面的代码可以保证正确性，但是执行效率上似乎还有优化的空间：无论resource是否已经被初始化，都会对getResource方法加锁。聪明如你一定很快就会想到使用"double check"的方式提高效率：
private Resource resource;
public Resource getResource() {
Resource tmp = this.resource;
if (tmp == null) {
synchronized(this){
tmp = this.resource
if (tmp == null) {
this.resource = tmp = new Resource();
}
}
}
return tmp;
}
ok，看起来很完美，然而，上面的代码是有问题的。不过，在jdk 5 以后，只要给成员变量resource加上volatile就可以解决这个问题了。
private volatile Resource resource;
public Resource getResource() {
Resource tmp = this.resource;
if (tmp == null) {
synchronized(this){
tmp = this.resource
if (tmp == null) {
this.resource = tmp = new Resource();
}
}
}
return tmp;
}
那么，volatile有什么作用，第一个版本的代码问题在哪里，为何加上volatile后就可以正常使用？下面我们就从java的内存模型开始，分析这些问题。
volatile的作用
volatile有两大作用：
保证内存可见性
防止指令重排
一、内存可见性
java的内存模型规定：在多线程情况下，线程操作主内存变量，需要通过线程独有的工作内存拷贝主内存变量副本来进行。此处的所谓内存模型要区别于通常所说的虚拟机堆模型：
[图片上传失败...(image-8d0241-1528615679687)]
Java内存模型也规定了工作内存与主内存之间交互的协议，定义了8种原子操作：
(1) lock:将主内存中的变量锁定，为一个线程所独占
(2) unclock:将lock加的锁定解除，此时其它的线程可以有机会访问此变量
(3) read:将主内存中的变量值读到工作内存当中
(4) load:将read读取的值保存到工作内存中的变量副本中。
(5) use:将值传递给线程的代码执行引擎
(6) assign:将执行引擎处理返回的值重新赋值给变量副本
(7) store:将变量副本的值存储到主内存中。
(8) write:将store存储的值写入到主内存的共享变量当中。
从上面的描述可以看出，当一个线程修改了某个共享变量的值并同步到主线程时，在其它线程从主内存将变量同步回自己的工作内存之前，共享变量的改变对其是不可见的。所以其他线程的本地内存中的变量已经是过时的，并不是更新后的值。
为了解决上面的问题，可以使用volatile关键字：
线程中每次use变量时，都需要连续执行read->load->use几项操作，即所谓的每次使用都要从主内存更新变量值，这样其它线程的修改对该线程就是可见的。
线程每次assign变量时，都需要连续执行assign->store->write几项操作，即所谓每次更新完后都会回写到主内存，这样使得其它线程读到的都是最新数据。
二、指令重排
什么是指令重排？指令重排是指JVM为了优化指令，提高程序运行效率，在不影响单线程程序执行结果的前提下，尽可能地提高并行度。编译器、处理器也遵循这样一个目标。在单线程的情况下，指令重排不会对程序执行结果造成影响，然而在多线程的情况下，指令重排就会出现问题，看下面的代码：
public class PossibleReordering {
static int x = 0, y = 0;
static int a = 0, b = 0;
public static void main(String[] args) throws InterruptedException {
Thread a = new Thread(new Runnable() {
public void run() {
a = 1;
x = b;
}
});
Thread b = new Thread(new Runnable() {
public void run() {
b = 1;
y = a;
}
});
a.start();
b.start();
a.join();
b.join();
System.out.println(“(” + x + “,” + y + “)”);
}
上面这段代码的结果是什么？考虑线程的执行顺序，可能为 (0,1) 、(1,0)或者是(1,1)。但是如果运行上面的程序若干次，还有可能出现第四种情况(0,0)，这就是由于指令重排改变了执行顺序导致的。
看下面的语句：
double r = 2.3d;
double pi =3.1415926;
double area = r * r * pi;
这个语句有如下步骤：
- 将2.3赋值给r
- 将π赋值给pi
- 读取r的值
- 读取pi的值
- 计算area的值
jvm为了保证语义的正确性，操作1可能会和2、4交换次序，操作2可能会和1、3交换次序，但是1、3、5和2、4、5之间的执行顺序肯定不会改变，这样就保证了执行结果的一致性。但是，如上面的例子所示，在多线程情况下乱序执行可能会导致一些出乎意料之外的结果。
那么如果防止指令重排呢？可以使用内存屏障。内存屏障是一种CPU指令，用于控制特定条件下的重排序和内存可见性问题。Java编译器也会根据内存屏障的规则禁止重排序。
内存屏障可以被分为以下几种类型
- LoadLoad屏障：对于这样的语句Load1; LoadLoad; Load2，在Load2及后续读取操作要读取的数据被访问前，保证 Load1要读取的数据被读取完毕。
- StoreStore屏障：对于这样的语句Store1; StoreStore; Store2，在Store2及后续写入操作执行前，保证Store1的写入操作对其它处理器可见。
- LoadStore屏障：对于这样的语句Load1; LoadStore; Store2，在Store2及后续写入操作被刷出前，保证Load1要读取的数据被读取完毕。
- StoreLoad屏障：对于这样的语句Store1; StoreLoad; Load2，在Load2及后续所有读取操作执行前，保证Store1的写入对所有处理器可见。
在使用了volatile后：
在每个volatile写操作的前面插入一个StoreStore屏障。
在每个volatile写操作的后面插入一个StoreLoad屏障。
在每个volatile读操作的后面插入一个LoadLoad屏障。
在每个volatile读操作的后面插入一个LoadStore屏障。
这样就可以防止指令重排导致的问题。
三、版本一 "double check" 的问题
有了上面的知识，我们就可以来分析第一个 "double check" 的问题了：
private Resource resource;
public Resource getResource() {
Resource tmp = this.resource;
if (tmp == null) {
synchronized(this){
tmp = this.resource
if (tmp == null) {
this.resource = tmp = new Resource();
}
}
}
return tmp;
}
new Resource() 可以分解为:
memory =allocate(); //1：分配对象的内存空间
ctorInstance(memory); //2：初始化对象
instance =memory; //3：设置instance指向刚分配的内存地址
如果被重排为
memory = allocate(); //1：分配对象的内存空间
instance = memory; //2：设置instance指向刚分配的内存地址
ctorInstance(memory); //3：初始化对象
就会出现线程A中执行这段赋值语句，在完成对象初始化之前就已经将其赋值给resource引用，恰好另一个线程进入方法判断instance引用不为null，然后就将其返回使用，导致出错。将resource设置为volatile之后，可以保证对相关操作的顺序。
另外，对于final，也有其独特的作用，例如在如下语句中，构建方法边界前后的指令都不能重排序：
x.finalField = v;
... ;
构建方法边界
sharedRef = x;
v.afield = 1;
x.finalField = v;
... ;
构建方法边界
sharedRef = x;
总结
volatile在jdk 5 以后有双重语义：1. 保证内存可见性 2.防止语句重排。不过这样也会使编译器放弃对相关代码的优化，因此，如无必要，不要使用volatile修饰成员变量。
