民工解惑——java中volatile关键字的作用

volatile关键字的作用、原理
在只有双重检查锁，没有volatile的懒加载单例模式中，由于指令重排序的问题，我确实不会拿到两个不同的单例了，但我会拿到“半个”单例。
而发挥神奇作用的volatile，可以当之无愧的被称为Java并发编程中“出现频率最高的关键字”，常用于保持内存可见性和防止指令重排序。
内存可见性
内存可见性：所有线程都能看到共享内存的最新状态。
如何保持内存可见性
volatile的特殊规则就是：
read、load、use动作必须连续出现。
assign、store、write动作必须连续出现。
所以，使用volatile变量能够保证:
每次读取前必须先从主内存刷新最新的值。
每次写入后必须立即同步回主内存当中。
也就是说，volatile关键字修饰的变量看到的随时是自己的最新值。线程1中对变量v的最新修改，对线程2是可见的。
以下是一个简单的可变整数类：

public class MutableInteger {
	private int value;
	public int get(){
		return value;
	}
	public void set(int value){
		this.value = value;
	}
}

MutableInteger不是线程安全的，因为get和set方法都是在没有同步的情况下进行的。如果线程1调用了set方法，那么正在调用的get的线程2可能会看到更新后的value值，也可能看不到。
解决方法：将value 声明为volatile变量：

private volatile int value;

volatile关键字还解决了失效数据问题
Java变量的读写
Java通过几种原子操作完成工作内存和主内存的交互：
lock：作用于主内存，把变量标识为线程独占状态。
unlock：作用于主内存，解除独占状态。
read：作用主内存，把一个变量的值从主内存传输到线程的工作内存。
load：作用于工作内存，把read操作传过来的变量值放入工作内存的变量副本中。
use：作用工作内存，把工作内存当中的一个变量值传给执行引擎。
assign：作用工作内存，把一个从执行引擎接收到的值赋值给工作内存的变量。
store：作用于工作内存的变量，把工作内存的一个变量的值传送到主内存中。
write：作用于主内存的变量，把store操作传来的变量的值放入主内存的变量中。
防止指令重排
在基于偏序关系的Happens-Before内存模型中，指令重排技术大大提高了程序执行效率，但同时也引入了一些问题。
示例：

class Singleton {
	private static Singleton instance;
	private Singleton(){}
	public static Singleton getInstance() {
		if ( instance == null ) { //这里存在竞态条件
			instance = new Singleton();
		}
		return instance;
	}
}

导致instance引用被多次赋值，使用户得到两个不同的单例。
DCL和被部分初始化的对象
解决这个问题，可以使用synchronized关键字将getInstance方法改为同步方法；但这样串行化的单例是不能忍的。所以我猿族前辈设计了DCL（Double Check Lock，双重检查锁）机制，使得大部分请求都不会进入阻塞代码块：

class Singleton {
	private static Singleton instance;
	private Singleton(){}
	public static Singleton getInstance() {
		if ( instance == null ) { //当instance不为null时，仍可能指向一个“被部分初始化的对象”
			synchronized (Singleton.class) {
				if ( instance == null ) {
					instance = new Singleton();
				}
			}
		}
		return instance;
	}
}

“看起来”非常完美：既减少了阻塞，又避免了竞态条件。不错，但实际上仍然存在一个问题——当instance不为null时，仍可能指向一个"被部分初始化的对象"。
问题出在这行简单的赋值语句：

instance = new Singleton();

解决这个该问题，只需要将instance声明为volatile变量：

private static volatile Singleton instance;

也就是说，在只有DCL没有volatile的懒加载单例模式中，仍然存在着并发陷阱。我确实不会拿到两个不同的单例了，但我会拿到“半个”单例（未完成初始化）。
然而，许多面试书籍中，涉及懒加载的单例模式最多深入到DCL，却只字不提volatile。这“看似聪明”的机制，曾经被我广大初入Java世界的猿胞大加吹捧——我在大四实习面试跟谁学的时候，也得意洋洋的从饱汉、饿汉讲到Double Check，现在看来真是傻逼。对于考查并发的面试官而言，单例模式的实现就是一个很好的切入点，看似考查设计模式，其实期望你从设计模式答到并发和内存模型。