volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”。可见性是指当一个线程修改一个共享变量时，另外一个线程能读到这个修改的值，从而避免出现数据脏读的问题。
volatile变量修饰符如果使用恰当的话，它比synchronized的使用和执行成本会更低，因为它不会引起线程上下文的切换和调度。
实现原理
编译器对volatile写操作多加一行lock前缀的指令
lock前缀的指令在多核处理器下会引发了两件事情：
- 将当前处理器缓存行的数据会写回到系统内存
- 这个写回内存的操作会引起在其他CPU里缓存了该内存地址的数据无效
当处理器发现本地缓存失效后，就会从内存中重读该变量数据，即可以获取当前最新值。
为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存（L1，L2或其他）后再进行操作，但操作完不知道何时会写到内存。
如果对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令，将这个变量所在缓存行的数据写回到系统内存。
但是，就算写回到内存，如果其他处理器缓存的值还是旧的，再执行计算操作就会有问题。所以，在多处理器下，为了保证各个处理器的缓存是一致的，就会实现缓存一致性协议：每个处理器通过嗅探在总线上传播的数据来检查自己缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改，就会将当前处理器的缓存行设置成无效状态，当处理器对这个数据进行修改操作的时候，会重新从系统内存中把数据读到处理器缓存里。
通过添加内存屏障阻止指令重排列
- 在每个volatile写操作的前面插入一个StoreStore屏障
- 在每个volatile写操作的后面插入一个StoreLoad屏障
- 在每个volatile读操作的后面插入一个LoadLoad屏障
- 在每个volatile读操作的后面插入一个LoadStore屏障
需要注意的是：volatile写是在前面和后面分别插入内存屏障，而volatile读操作是在后面插入两个内存屏障
- StoreStore屏障：禁止上面的普通写和下面的volatile写重排序
- StoreLoad屏障：禁止上面的volatile写与下面可能有的volatile读/写重排序
- LoadLoad屏障：禁止下面所有的普通读操作和上面的volatile读重排序
- LoadStore屏障：禁止下面所有的普通写操作和上面的volatile读重排序
使用实例
著名的Java并发编程大师Doug lea在JDK7的并发包里新增一个队列集合类LinkedTransferQueue，他在使用Volatile变量时，将共享变量：队列的头结点和尾节点各自追加到64个字节，以此优化队列出队和入队的性能。
原因：处理器的L1，L2或L3缓存的高速缓存行是64个字节宽，不支持部分填充缓存行，这意味着如果队列的头节点和尾节点都不足64字节的话，处理器会将它们都读到同一个高速缓存行中，在多处理器下每个处理器都会缓存同样的头尾节点，当一个处理器试图修改头节点时会将整个缓存行锁定，那么在缓存一致性机制的作用下，会导致其他处理器不能访问自己高速缓存中的尾节点，而队列的入队和出队操作是需要不停修改头节点和尾节点，所以在多处理器的情况下将会严重影响到队列的入队和出队效率。Doug lea使用追加到64字节的方式来填满高速缓冲区的缓存行，避免头节点和尾节点加载到同一个缓存行，使得头尾节点在修改时不会互相锁定。
在以下两种场景下不应该使用追加字节方式：
- 缓存行非64字节宽的处理器，如P6系列和奔腾处理器，它们的L1和L2高速缓存行是32个字节宽
- 共享变量不会被频繁的写。因为使用追加字节的方式需要处理器读取更多的字节到高速缓冲区，这本身就会带来一定的性能消耗，共享变量如果不被频繁写的话，锁的几率也非常小，就没必要通过追加字节的方式来避免相互锁定。
参考：