1. volatile简介
synchronized是阻塞式同步，在线程竞争激烈的情况下会升级为重量级锁。而volatile就可以说是java虚拟机提供的最轻量级的同步机制。但它同时不容易被正确理解，以至于在并发编程中很多程序员遇到线程安全的问题就会使用synchronized。Java内存模型告诉我们，各个线程会将共享变量从主内存中拷贝到工作内存，然后执行引擎会基于工作内存中的数据进行操作处理。线程在工作内存进行操作后何时会写到主内存中？这个时机对普通变量是没有规定的，而针对volatile修饰的变量给java虚拟机特殊的约定，线程对volatile变量的修改会立刻被其他线程所感知，即不会出现数据脏读的现象，从而保证数据的“可见性”。
现在我们有了一个大概的印象就是：被volatile修饰的变量能够保证每个线程能够获取该变量的最新值，从而避免出现数据脏读的现象。
2. volatile实现原理
volatile是怎样实现了？比如一个很简单的Java代码：
class Main {
public volatile static int i=0;
public int sum() {
Main.i++;
return i;
}
}
汇编代码如下：
[Constants]
# {method} {0x00000000571e0390} 'sum' '()I' in 'Main'
# [sp+0x40] (sp of caller)
0x0000000002b62220: mov 0x8(%rdx),%r10d
0x0000000002b62224: cmp %rax,%r10
0x0000000002b62227: jne 0x0000000002aa5f60 ; {runtime_call}
0x0000000002b6222d: data16 data16 nopw 0x0(%rax,%rax,1)
0x0000000002b62238: data16 data16 xchg %ax,%ax
0x0000000002b6223c: nopl 0x0(%rax)
[Verified Entry Point]
0x0000000002b62240: mov %eax,-0x6000(%rsp)
0x0000000002b62247: push %rbp
0x0000000002b62248: sub $0x30,%rsp
0x0000000002b6224c: movabs $0x571e05c0,%rax ; {metadata(method data for {method} {0x00000000571e0390} 'sum' '()I' in 'Main')}
0x0000000002b62256: mov 0xdc(%rax),%esi
0x0000000002b6225c: add $0x8,%esi
0x0000000002b6225f: mov %esi,0xdc(%rax)
0x0000000002b62265: movabs $0x571e0388,%rax ; {metadata({method} {0x00000000571e0390} 'sum' '()I' in 'Main')}
0x0000000002b6226f: and $0x0,%esi
0x0000000002b62272: cmp $0x0,%esi
0x0000000002b62275: je 0x0000000002b622a1
0x0000000002b6227b: movabs $0xd5e5a0c0,%rax ; {oop(a 'java/lang/Class' = 'Main')}
0x0000000002b62285: mov 0x68(%rax),%esi ;*getstatic i
; - Main::sum@0 (line 11)
0x0000000002b62288: inc %esi
0x0000000002b6228a: mov %esi,0x68(%rax)
0x0000000002b6228d: lock addl $0x0,(%rsp) ;*putstatic i
; - Main::sum@5 (line 11)
0x0000000002b62292: mov 0x68(%rax),%eax ;*getstatic i
; - Main::sum@8 (line 12)
0x0000000002b62295: add $0x30,%rsp
0x0000000002b62299: pop %rbp
0x0000000002b6229a: test %eax,-0x27021a0(%rip) # 0x0000000000460100
; {poll_return}
0x0000000002b622a0: retq
0x0000000002b622a1: mov %rax,0x8(%rsp)
0x0000000002b622a6: movq $0xffffffffffffffff,(%rsp)
0x0000000002b622ae: callq 0x0000000002b5f1a0 ; OopMap{rdx=Oop off=147}
;*synchronization entry
; - Main::sum@-1 (line 11)
; {runtime_call}
0x0000000002b622b3: jmp 0x0000000002b6227b
0x0000000002b622b5: nop
0x0000000002b622b6: nop
0x0000000002b622b7: mov 0x2a8(%r15),%rax
0x0000000002b622be: movabs $0x0,%r10
0x0000000002b622c8: mov %r10,0x2a8(%r15)
0x0000000002b622cf: movabs $0x0,%r10
0x0000000002b622d9: mov %r10,0x2b0(%r15)
0x0000000002b622e0: add $0x30,%rsp
0x0000000002b622e4: pop %rbp
0x0000000002b622e5: jmpq 0x0000000002b5a160 ; {runtime_call}
在生成汇编代码时会在volatile修饰的共享变量进行写操作的时候会多出Lock前缀的指令。我们想这个Lock指令肯定有神奇的地方，那么Lock前缀的指令在多核处理器下会发现什么事情了？主要有这两个方面的影响：
- 将当前处理器缓存行的数据写回系统内存；
- 这个写回内存的操作会使得其他CPU里缓存了该内存地址的数据无效
为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2或其他）后再进行操作，但操作完不知道何时会写到内存。如果对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议，每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。因此，经过分析我们可以得出如下结论：
- Lock前缀的指令会引起处理器缓存写回内存；
- 一个处理器的缓存回写到内存会导致其他处理器的缓存失效；
- 当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。
这样针对volatile变量通过这样的机制就使得每个线程都能获得该变量的最新值。
3. volatile的happens-before关系
经过上面的分析，我们已经知道了volatile变量可以通过缓存一致性协议保证每个线程都能获得最新值，即满足数据的“可见性”。
在六条happens-before规则中有一条是：volatile变量规则：对一个volatile域的写，happens-before于任意后续对这个volatile域的读。下面我们结合具体的代码，我们利用这条规则推导下：
public class VolatileExample {
private int a = 0;
private volatile boolean flag = false;
public void writer(){
a = 1; //1
flag = true; //2
}
public void reader(){
if(flag){ //3
int i = a; //4
}
}
}
上面的实例代码对应的happens-before关系如下图所示：
加锁线程A先执行writer方法，然后线程B执行reader方法图中每一个箭头两个节点就代码一个happens-before关系，黑色的代表根据程序顺序规则推导出来，红色的是根据volatile变量的写happens-before 于任意后续对volatile变量的读，而蓝色的就是根据传递性规则推导出来的。这里的2 happen-before 3，同样根据happens-before规则定义：如果A happens-before B,则A的执行结果对B可见，并且A的执行顺序先于B的执行顺序，我们可以知道操作2执行结果对操作3来说是可见的，也就是说当线程A将volatile变量 flag更改为true后线程B就能够迅速感知。
4. volatile的内存语义
还是以上面的代码为例，假设线程A先执行writer方法，线程B随后执行reader方法，初始时线程的本地内存中flag和a都是初始状态，下图是线程A执行volatile写后的状态图。
当volatile变量写后，线程中本地内存中共享变量就会置为失效的状态，因此线程B再需要读取从主内存中去读取该变量的最新值。下图就展示了线程B读取同一个volatile变量的内存变化示意图。
从横向来看，线程A和线程B之间进行了一次通信，线程A在写volatile变量时，实际上就像是给B发送了一个消息告诉线程B你现在的值都是旧的了，然后线程B读这个volatile变量时就像是接收了线程A刚刚发送的消息。既然是旧的了，那线程B该怎么办了？自然而然就只能去主内存去取啦。
4.1 volatile的内存语义实现
我们都知道，为了性能优化，JMM在不改变正确语义的前提下，会允许编译器和处理器对指令序列进行重排序，那如果想阻止重排序要怎么办了？答案是可以添加内存屏障。
内存屏障
JMM内存屏障分为四类见下图，
java编译器会在生成指令系列时在适当的位置会插入内存屏障指令来禁止特定类型的处理器重排序。为了实现volatile的内存语义，JMM会限制特定类型的编译器和处理器重排序，JMM会针对编译器制定volatile重排序规则表：
"NO"表示禁止重排序。为了实现volatile内存语义时，编译器在生成字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎是不可能的，为此，JMM采取了保守策略：
对于每个volatile写操作：
（1）前面插入一个StoreStore屏障；
（2）后面插入一个StoreLoad屏障；
对于每个volatile读操作
（1）后面插入一个LoadLoad屏障；
（2）后面插入一个LoadStore屏障。
需要注意的是：volatile写是在前面和后面分别插入内存屏障，而volatile读操作是在后面插入两个内存屏障
StoreStore屏障：禁止上面的普通写和下面的volatile写重排序；
StoreLoad屏障：防止上面的volatile写与下面可能有的volatile读/写重排序
LoadLoad屏障：禁止下面所有的普通读操作和上面的volatile读重排序
LoadStore屏障：禁止下面所有的普通写操作和上面的volatile读重排序
下面以两个示意图进行理解，图片摘自相当好的一本书《java并发编程的艺术》。