volatile被视作是轻量级的sychronized。与sychronied关键字比较，volatile只能保证共享变量数据的可见性，即，当一个变量被多个线程共享，可修改时，一个线程的修改结果会立刻对其他线程可见。
volatile是如何做到可见性的？
首先，要明白为什么会有可见性问题。
CPU负责数据处理，实际的运行时数据存储在内存中，CPU和内存之间通过总线传递数据。由于CPU和内存对数据处理的速度有很大差异，所以通常CPU存取的数据都不会直接与内存交互，转而经过处理器缓存读写。这样的直接后果是，处理器缓存内的数据和内存中的数据未必一致，无法保证最新被处理过的结果立刻刷新到内存中去，同样也无法保证读取到的就是最新被刷新到内存的结果，可见性问题由此产生。类似于这种描述，Java在线程通信方面，采用的是共享内存模型，线程通过共享状态，隐式通信。从下图看，线程A、B之间的通信，需要先把本线程内的共享变量副本刷新到主存，然后经由另一个线程再去将主内存中的变量值同步到该线程本地内存中。
此外，处理器的执行顺序和内存中的顺序不会一致，虽然从性能优化的角度考量，这是很合理的，但是会对程序员编程造成一定的影响。如何保证内存编程的结果和想要的一致，需要介于程序员和处理器之间建立约定。
上图引用自《Java并发编程艺术》一书，很好的阐释了程序员与处理器之间的矛盾，程序员希望很好的控制程序运行，程序按定义语义执行，处理器则希望尽可能的提高效率，尽量不受执行顺序约束。为了应对二者之间的矛盾，需要给上层的程序编写者提供一个很强的保证，即按照该保证编程，就能得到想要的执行结果（在此并不能完全承诺执行顺序和保证的顺序一致）。这个“保证”就是“happens-before”规则。
它承诺：
（1）程序顺序：单线程内的每个操作，happens before该线程内的后续操作；
（2）锁：解锁操作，happens before随后对这个锁的加锁；
（3）volatile：volatile域的写，happens before后续对这个域的读；
（4）传递性：a happens before b，b happens before c，则有a happens before c。
程序员只要按照这个原则编程，就可以保证处理器执行结果。
那么volatile是如何实现happens before的效果？也就是有效阻止某些处理器的重排序，答案是内存屏障（P26）。一旦域被volatile修饰，编译后的字节码内会被添加上各种内存屏障。同样加上其他，如synchronized和final原语也会添加这种屏障。JMM把内存屏障分为四类，即LoadLoad、StoreStore、LoadStore和StoreLoad屏障，其中StoreLoad具有其他三种的所有效果，被现代处理器广泛支持。
StoreLoad Barriers指令示例为Store1；StoreLoad；Load2，确保Store1数据对其他处理器变得可见（即刷新到内存）先于Load2及所有后续装载指令的装载。StoreLoad Barriers会使该屏障前的所有内存访问指令（存储和装载指令）完成之后，才执行该屏障之后的内存访问指令。
关于volatile实现原理，可以参考《Java并发编程艺术》P39-47。文章主要阐述的就是，写-读的内存语义，以及volatile是如何针对这种场景添加内存屏障，保证程序员看到的“happens before”原则视图有效的。复习时可以看看，找找感觉。
