引子

在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的内存模型规定：在多线程情况下，线程操作主内存变量，需要通过线程独有的工作内存拷贝主内存变量副本来进行。此处的所谓内存模型要区别于通常所说的虚拟机堆模型：

多线程下内存操作

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修饰成员变量。