volatile

提到volatile，立马涌现出三段很经典的代码，当然也会涉及到JMM

第一点：可见性

在JMM定义里面有一个主内存，堆内存栈内存什么的都可认为是主内存，每一个线程在执行过程之中，有一个线程自己的内存。实际上不能认为这块就是线程私有的内存，它也有可能是cpu上的缓冲区，这也被JMM称为是线程自己的内存，就是线程存放自己变量的内存。如果有两个cpu在运行两个不同的线程的时候，那么每个cpu上面都有一个缓冲区，缓冲区就是把主内存里面的数据读过来。读过来之后在缓冲区里面修改。比如是加一加一加一然后再写回去。

import java.util.concurrent.TimeUnit;

public class volatileTest implements Runnable{

	volatile boolean running = true;
	@Override
	public void run() {
		// TODO Auto-generated method stub
		System.out.println("myThread start...");
		while(running){
			//doSomething();
		}
		System.out.println("myThread end...");
	}
	
	public static void main(String[] args) {
		volatileTest vt = new volatileTest();
		new Thread(vt).start();
		try {
			TimeUnit.SECONDS.sleep(1);
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		vt.running = false;
	}
}

现在主内存中有一个running的值，这个值是true。实际上这个true占一个字节。cpu在处理这个running的时候，它会从主内存中把这一个字节的数据拷贝到它自己的缓冲区中。然后cpu在处理的过程中就不在去主内存中读这个一个字节了，不读了。这就产生问题了，比如第一个线程，在这个cpu里面运行或者在这个cpu的核里面运行，它把这个running的值读到自己的缓冲区，这时候是true，然后它就开始运行这个run方法，在运行这个方法的过程之中，由于这个cpu非常的忙，一直在循环中，它就没空去主内存中去刷一下，一直就读自己缓存里面的内容，缓存里一直是true。说另外一个线程 就是主线程 它也是首先把这个running读到自己的缓存区，读到之后，改为false，然后他发现改了，就把这个值写回到主内存中。但是写完之后，第一个线程一直在忙于自循环，没有去读这个写之后的值，所以第一个线程就一直结束不了了。但是如果cpu有一段空闲的值，它就有可能去主内存刷这个新值，这时候就不会出问题，比如说在while循环中是这样的代码：

while(running){
    try {
	    TimeUnit.SECONDS.sleep(1);
	} catch (InterruptedException e) {
		// TODO Auto-generated catch block
		e.printStackTrace();
	}
}

这就有可能不会出现问题。但是你也不能保证线程A会有空闲时间，况且就算保证了有空闲时间，它到底去不去主内存中去刷新这个新值，也不一定，完全随自己高兴。所以从本质上解决问题就是加volatile（当然还有其他解决办法，比如synchronized），保证线程之间的可见性。

加了volatile之后，不是说每次循环的时候都必须从主内存中刷这个值，而是说一旦这个值发生改变之后 ，会通知其他的缓存了这个字节的线程说，你们的缓冲区里的值过期了，请你们去主内存中在读一下。然后第一个线程就读到了这个新值，这时候就结束了。

这就是volatile的可见性

可见性的底层实现原理：如果对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。

第二点：禁止指令重排序

懒汉式的单例模式是线程不安全的，其中有一种解决方案是双重检索机制的单例模式。

public class DoubleCheckedLocking { // 1
    private static Instance instance; // 2
    public static Instance getInstance() { // 3
        if (null == instance) { // 4:第一次检查
            synchronized (DoubleCheckedLocking.class) { // 5:加锁
                if (instance == null) // 6:第二次检查
                    instance = new Instance(); // 7:问题的根源出在这里
            } // 8
        } // 9
        return instance; // 10
    } // 11
}

 如果第一次检查instance不为null，那么就不需要执行下面的加锁和初始化操作，直接返回已创建好的对象。 这种方案看起来似乎很完美，但是这是一个错误的优化。

在线程执行到第4行，代码读取到instance不为null时，instance引用的对象有可能还没有完成初始化。 这样的话就直接返回了一个没有完成初始化的对象。

前面的双重检查锁定示例代码的第7行（instance=new Singleton();）创建了一个对象。这一行代码可以分解为如下的3行伪代码。

memory = allocate(); // 1：分配对象的内存空间
ctorInstance(memory); // 2：初始化对象
instance = memory; // 3：设置instance指向刚分配的内存地址

上面3行伪代码中的2和3之间，可能会被重排序。 

memory = allocate(); // 1：分配对象的内存空间
instance = memory; // 3：设置instance指向刚分配的内存地址
// 注意，此时对象还没有被初始化！
ctorInstance(memory); // 2：初始化对象

如果发生重排序，另一个并发执行的线程B就有可能在第4行判断instance不为null。线程B接下来将 访问instance所引用的对象，但此时这个对象可能还没有被A线程初始化

至于为什么会发生重排序，JMM中定义了一条语义as-if-serial语义,意思是：不管怎么重排序（编译器和处理器为了提高并行度），（单线程）程序的执行结果不能被改变。

这里2和3虽然重排序了，但Java内存模型将确保2一定会排在return语句前面执行。因此，线程A的结果没有改变。因此会发生重排序。

两个办法来解决这个问题

1）不允许2和3重排序。

2）允许2和3重排序，但不允许其他线程“看到”这个重排序。

方案一：基于volatile的解决方案

public class DoubleCheckedLocking { // 1
    private volatile static Instance instance; // 2
    public static Instance getInstance() { // 3
        if (null == instance) { // 4:第一次检查
            synchronized (DoubleCheckedLocking.class) { // 5:加锁
                if (instance == null) // 6:第二次检查
                    instance = new Instance(); // 7:问题的根源出在这里
            } // 8
        } // 9
        return instance; // 10
    } // 11
}

当声明对象的引用为volatile后，2和3之间的重排序，在多线程环境中将会被禁止

原子性的底层实现原理：在第7行的赋值操作之后，多了一条lock指令的操作，这个lock指令的操作相当于一个内存屏障，指的是重排序之后不能把后面的操作重排序到内存屏障之前的位置。

就是说编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序；为此，JMM采取保守策略

在每个volatile写操作的前面插入一个StoreStore屏障。

在每个volatile写操作的后面插入一个StoreLoad屏障。

在每个volatile读操作的后面插入一个LoadLoad屏障。

在每个volatile读操作的后面插入一个LoadStore屏障。

在实际执行时，只要不改变volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障，内存屏障的插入还可以根据具体的处理器内存模型继续优化。以X86处理器为例，因为X86处理器仅会对写-读操作做重排序。X86不会对读-读、读-写和写-写操作做重排序，所以在X86处理器中会省略掉这3种操作类型对应的内存屏障。在X86中，JMM仅需在volatile写后面插入一个StoreLoad屏障即可正确实现volatile写-读的内存语义。

第三点：不能保证原子性

对任意单个volatile变量的读/写具有原子性，但类似于volatile++这种复合操作不具有原子性。

public class volatileTest {
	public static volatile int race = 0;
	public  static void increase(){
		race++;
	}
	public static void main(String[] args) {
		for(int i = 0;i<20;i++){
			new Thread(new Runnable() {
				@Override
				public void run() {
					// TODO Auto-generated method stub
					for(int i = 0;i<10000;i++){
						increase();
					}
				}
			}).start();
		}
		while(Thread.activeCount()>1){
			Thread.yield();
		}
		System.out.println(race);
	}
}

我用javap反编译这条代码的时候，发现只有一行代码的increase方法在class文件中是由4条字节码指令构成的。

getStatic

Iconst_1

Iadd

putStatic

当getStatic指令把race的值取到操作数栈顶的时候，volatile保证了此时是正确的，但是在执行iconst_1（将常量1压入栈）、iadd（将栈顶的两个值出栈、相加，然后把结果放入栈顶）这些指令的时候，其他线程就可能已经把race的值加大了，而在操作数栈顶的值就变成了过期的数据，所以putStatic就可能把较小的race值同步回去了。

解决办法：使用synchronized或者原子包Atomic中的类