本文摘自 敖丙大神的文章
你会发现，永远都不会输出有点东西这一段代码，按道理线程改了flag变量，主线程也能访问到的呀？
为会出现这个情况呢？那我们就需要聊一下另外一个东西了。
JMM（JavaMemoryModel）
JMM：Java内存模型，是java虚拟机规范中所定义的一种内存模型，Java内存模型是标准化的，屏蔽掉了底层不同计算机的区别（注意这个跟JVM完全不是一个东西，只有还有小伙伴搞错的）。
那正式聊之前，先大概科普一下现代计算机的内存模型吧。
现代计算机的内存模型
其实早期计算机中cpu和内存的速度是差不多的，但在现代计算机中，cpu的指令速度远超内存的存取速度，由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统都不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存（Cache）来作为内存与处理器之间的缓冲。
将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。
基于高速缓存的存储交互很好地解决了处理器与内存的速度矛盾，但是也为计算机系统带来更高的复杂度，因为它引入了一个新的问题：缓存一致性（CacheCoherence）。
在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一主内存（MainMemory）。
然后我们可以聊一下JMM了。
JMM
Java内存模型(JavaMemoryModel)描述了Java程序中各种变量(线程共享变量)的访问规则，以及在JVM中将变量，存储到内存和从内存中读取变量这样的底层细节。
JMM有以下规定：
所有的共享变量都存储于主内存，这里所说的变量指的是实例变量和类变量，不包含局部变量，因为局部变量是线程私有的，因此不存在竞争问题。
每一个线程还存在自己的工作内存，线程的工作内存，保留了被线程使用的变量的工作副本。
线程对变量的所有的操作(读，取)都必须在工作内存中完成，而不能直接读写主内存中的变量。
不同线程之间也不能直接访问对方工作内存中的变量，线程间变量的值的传递需要通过主内存中转来完成。
本地内存和主内存的关系：
正是因为这样的机制，才导致了可见性问题的存在，那我们就讨论下可见性的解决方案。
可见性的解决方案
加锁
为啥加锁可以解决可见性问题呢？
因为某一个线程进入synchronized代码块前后，线程会获得锁，清空工作内存，从主内存拷贝共享变量最新的值到工作内存成为副本，执行代码，将修改后的副本的值刷新回主内存中，线程释放锁。
而获取不到锁的线程会阻塞等待，所以变量的值肯定一直都是最新的。
Volatile修饰共享变量
开头的代码优化完之后应该是这样的：
Volatile做了啥？
每个线程操作数据的时候会把数据从主内存读取到自己的工作内存，如果他操作了数据并且写会了，他其他已经读取的线程的变量副本就会失效了，需要都数据进行操作又要再次去主内存中读取了。
volatile保证不同线程对共享变量操作的可见性，也就是说一个线程修改了volatile修饰的变量，当修改写回主内存时，另外一个线程立即看到最新的值。
是不是看着加一个关键字很简单，但实际上他在背后含辛茹苦默默付出了不少，我从计算机层面的缓存一致性协议解释一下这些名词的意义。
之前我们说过当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致，举例说明变量在多个CPU之间的共享。
略……
禁止指令重排序
什么是重排序?
为了提高性能，编译器和处理器常常会对既定的代码执行顺序进行指令重排序。
重排序的类型有哪些呢？源码到最终执行会经过哪些重排序呢？
一个好的内存模型实际上会放松对处理器和编译器规则的束缚，也就是说软件技术和硬件技术都为同一个目标，而进行奋斗：在不改变程序执行结果的前提下，尽可能提高执行效率。
JMM对底层尽量减少约束，使其能够发挥自身优势。
因此，在执行程序时，为了提高性能，编译器和处理器常常会对指令进行重排序。
一般重排序可以分为如下三种：
编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序;
指令级并行的重排序。现代处理器采用了指令级并行技术来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序;
内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行的。
这里还得提一个概念，as-if-serial。
as-if-serial
不管怎么重排序，单线程下的执行结果不能被改变。
编译器、runtime和处理器都必须遵守as-if-serial语义。
那Volatile是怎么保证不会被执行重排序的呢？
内存屏障
java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。
为了实现volatile的内存语义，JMM会限制特定类型的编译器和处理器重排序，JMM会针对编译器制定volatile重排序规则表：
需要注意的是：volatile写是在前面和后面分别插入内存屏障，而volatile读操作是在后面插入两个内存屏障。
写
读
上面的我提过重排序原则，为了提高处理速度，JVM会对代码进行编译优化，也就是指令重排序优化，并发编程下指令重排序会带来一些安全隐患：如指令重排序导致的多个线程操作之间的不可见性。
如果让程序员再去了解这些底层的实现以及具体规则，那么程序员的负担就太重了，严重影响了并发编程的效率。
从JDK5开始，提出了happens-before的概念，通过这个概念来阐述操作之间的内存可见性。
happens-before
如果一个操作执行的结果需要对另一个操作可见，那么这两个操作之间必须存在happens-before关系。
volatile域规则：对一个volatile域的写操作，happens-before于任意线程后续对这个volatile域的读。
如果现在我的变了falg变成了false，那么后面的那个操作，一定要知道我变了。
聊了这么多，我们要知道Volatile是没办法保证原子性的，一定要保证原子性，可以使用其他方法。
无法保证原子性
就是一次操作，要么完全成功，要么完全失败。
假设现在有N个线程对同一个变量进行累加也是没办法保证结果是对的，因为读写这个过程并不是原子性的。
要解决也简单，要么用原子类，比如AtomicInteger，要么加锁(记得关注Atomic的底层)。
应用
大家可能好奇为啥要双重检查？如果不用Volatile会怎么样？
我先讲一下禁止指令重排序的好处。
对象实际上创建对象要进过如下几个步骤：
分配内存空间
调用构造器，初始化实例
返回地址给引用
上面我不是说了嘛，是可能发生指令重排序的，那有可能构造函数在对象初始化完成前就赋值完成了，在内存里面开辟了一片存储区域后直接返回内存的引用，这个时候还没真正的初始化完对象。
但是别的线程去判断instance！=null，直接拿去用了，其实这个对象是个半成品，那就有空指针异常了。