volatile的应用
在多线程并发编程中synchronized和volatile都扮演者重要的角色，volatile是轻量级的synchronized，它在多处理器开发中保证了共享变量的“可见性”。
可见性的意思是当一个线程修改一个共享变量时，另外的线程能读到这个修改的值。
如果volatile变量修饰符使用恰当的话，它比synchronized的使用和执行成本更低，因为它不会引起线程上下文的切换和调度。
1. volatile的定义与实现原理
Java语言规范第3版对volatile的定义如下：
Java编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致地更新，线程应该确保通过排它锁单独获得这个变量。
Java语言提供了volatile，在某些情况下比锁更加方便。如果一个字段被声明成volatile，Java线程内存模型确保所有线程看到这个变量的值是一致的。
在了解volatile实现原理之前，先看下与实现原理相关的CPU术语与说明
| 术语 | 英文单词 | 术语描述 |
|---|---|---|
| 内存屏障 | memory barriers | 是一组处理器指令，用户实现对内存操作的顺序限制 |
| 缓存行 | cache line | CPU高速缓存中可以分配的最小存储单位。处理器填写缓存行时会加载整个缓存行，现代CPU需要执行几百次CPU指令 |
| 原子操作 | atomic operations | 不可终端的一个或一系列操作 |
| 缓存行填充 | cache line fill | 当处理器识别到从内存中读取操作数是可缓存的，处理器读取整个高速缓存行到适当的缓存(L1，L2，L3的或所有) |
| 写命中 | write hit | 当处理器将操作数写回到一个内存缓存的区域时，它首先会检查这个缓存的内存地址是否在缓存行中，如果存在一个有效的缓存行，则处理器将这个操作数写回到缓存，而不是写回到内存，这个操作被称为写命中 |
| 写缺失 | write misses the cache | 一个有效的缓存行被写入到不存在的内存区域 |
为了提高处理速度，处理器不直接和内存进行通信，而是先将系统内存的数据读到内部缓存(L1, L2或其他)后再进行操作，但操作完不知道何时会写到内存。如果对声明了volatile的变量进行写操作，JVM就会向处理器发送一条Lock前缀的指令。 这是volatile实现“可见性”的最重要的一部分
Lock前缀的指令在多核处理器下会引发两件事情
- 将当前处理器缓存行的数据写回到系统内存
在多处理器环境中，LOCK#信号确保在声言该信号期间，处理器可以独占任何共享内存[1] 。但是，在最近的处理器里，LOCK#信号一般不锁总线，而是锁缓存，毕竟锁总线的开销比较大。
在锁操作时，会锁定这块内存区域的缓存并回写到内存，并使用缓存一致性机制来确保修改的原子性，此操作被称为“缓存锁定”，缓存一致性机制会阻止同时修改由两个以上处理器缓存的内存区域数据
- 一个处理器的缓存回写到内存会导致其他处理器的缓存无效
2. volatile的使用优化
著名的Java并发编程大师Doug lea在JDK7的并发包里新增一个队列集合类LinkedTransferQueue，它在使用volatile变量时，用一种追加字节的方式来优化队列出队和入队的性能。
LinkedTransferQueue的代码如下
/** 队列中的头部节点 **/
private transient final PaddedAtomicReference<QNode> head;
/** 队列中的尾部节点 **/
private transient final PaddedAtomicReference<QNode> tail;
static final class PaddedAtomicReference <T> extends AtomicReference <T> {
// 使用很多4个字节的引用追加到64字节
Object p0, p1, p2, p3, p4, p5, p6, p7, p8, p9, pa, pb, pc, pd, pe;
PaddedAtomicReference(T r) {
super(r);
}
}
public class AtomicReference <V> implements java.io.Serializable {
private volatile V value;
// 省略其他代码
}
追加字节能优化性能？ 这种方式看起来很神奇，但如果深入理解处理器架构就能理解其中的奥秘。对于LinkedTransferQueue这个类，它使用一个内部类类型来定义队列的头节点(head)和尾节点(tail)，而这个内部类PaddedAtomicReference相对于父类AtomicReference只做了一件事，就是将共享变量追加到64字节。一个对象的引用占4个字节，它追加了15个变量(共占60个字节)，再加上父类的value变量，一共64个字节。
为什么追加64字节能够提高并发编程的效率呢？ 因为对于英特尔酷睿i7、酷睿、Atom和NetBurst，以及Core Solo和Pentium M处理器的L1、L2或L3缓存的高速缓存行是64个字节宽，不支持部分填充缓存行，这意味着，如果队列的头节点和尾节点都不足64字节的话，处理器会将它们都读到同一个高速缓存中，在多处理器下每个处理器都会缓存同样的头、尾节点，当一个处理器试图修改头节点时，会将整个缓存行锁定，那么在缓存一致性机制的作用下，会导致其他处理器不能访问自己高速缓存中的尾节点，而队列的入队和出队操作则需要不停修改头节点和尾节点，所以在多处理器的情况下将会严重影响到队列的入队和出队效率。Doug lea使用追加到64字节的方式来填满高速缓存区的缓存行，避免头节点和尾节点加载到同一个缓存行，使头、尾节点在修改时不会互相锁定。
是不是在使用volatile变量时都应该追加到64字节呢？ 不是的。在下面两种场景下不应该使用这种方式
-
缓存行非64字节宽的处理器。 如P6系列和奔腾处理器，它们的L1和L2高速缓存行是32个字节宽
-
共享变量不会被频繁地写。 因为使用追加字节的方式需要处理器读取更多的字节到高速缓存区，这本身就会带来一定的性能消耗，如果共享变量不被频繁写的话，锁的几率也非常小，就没必要通过追加字节的方式来避免相互锁定。
因为它会锁住总线，导致其他CPU不能访问总线，不能访问总线就意味着不能访问系统内存 ↩︎