简单说说volatile关键字实现的机制吧？

    volatile变量用来实现并发过程当中遇到的读写原子性的实现，不一样线程对申明volatile变量的写后，其余线程对该变量的读为最新的值，便可见性。可是volatile不保证复合操做（如i++相似的依赖原值得操做）的线程安全。在JSR133中定义了happends-before原则，对volatile变量的写happends-before于对该变量的读。volatile相对于synchronized实现锁的同步是属于轻量级的同步。

 

参考资料：

同步与Java内存模型(一)序言

Java内存模型没有具体讲述前面讨论的执行策略是由编译器，CPU，缓存控制器仍是其它机制促成的。甚至没有用开发人员所熟悉的类，对象及方法来讨论。取而代之，Java内存模型中仅仅定义了线程和内存之间那种抽象的关系。众所周知，每一个线程都拥有本身的工做存储单元（缓存和寄存器的抽象）来存储线程当前使用的变量的值。Java内存模型仅仅保证了代码指令与变量操做的有序性，大多数规则都只是指出何时变量值应该在内存和线程工做内存之间传输。这些规则主要是为了解决以下三个相互牵连的问题：

1. 原子性：哪些指令必须是不可分割的。在Java内存模型中，这些规则需声明仅适用于-—实例变量和静态变量，也包括数组元素，但不包括方法中的局部变量-—的内存单元的简单读写操做。
2. 可见性：在哪些状况下，一个线程执行的结果对另外一个线程是可见的。这里须要关心的结果有，写入的字段以及读取这个字段所看到的值。
3. 有序性：在什么状况下，某个线程的操做结果对其它线程来看是无序的。最主要的乱序执行问题主要表如今读写操做和赋值语句的相互执行顺序上。

聊聊并发（一）深刻分析Volatile的实现原理

为何要使用Volatile

Volatile变量修饰符若是使用恰当的话，它比synchronized的使用和执行成本会更低，由于它不会引发线程上下文的切换和调度。

Volatile的使用优化

著名的Java并发编程大师Doug lea在JDK7的并发包里新增一个队列集合类LinkedTransferQueue，他在使用Volatile变量时，用一种追加字节的方式来优化队列出队和入队的性能。

追加字节能优化性能？这种方式看起来很神奇，但若是深刻理解处理器架构就能理解其中的奥秘。让咱们先来看看LinkedTransferQueue这个类，它使用一个内部类类型来定义队列的头队列（Head）和尾节点（tail），而这个内部类PaddedAtomicReference相对于父类AtomicReference只作了一件事情，就将共享变量追加到64字节。咱们能够来计算下，一个对象的引用占4个字节，它追加了15个变量共占60个字节，再加上父类的Value变量，一共64个字节。

/** head of the queue */
private transient final PaddedAtomicReference<QNode> head;

/** tail of the queue */
private transient final PaddedAtomicReference<QNode> tail;

static final class PaddedAtomicReference <T> extends AtomicReference <T> {

  // enough padding for 64bytes with 4byte refs
  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;

  //省略其余代码

｝

为何追加64字节可以提升并发编程的效率呢？ 由于对于英特尔酷睿i7，酷睿， Atom和NetBurst， Core Solo和Pentium M处理器的L1，L2或L3缓存的高速缓存行是64个字节宽，不支持部分填充缓存行，这意味着若是队列的头节点和尾节点都不足64字节的话，处理器会将它们都读到同一个高速缓存行中，在多处理器下每一个处理器都会缓存一样的头尾节点，当一个处理器试图修改头接点时会将整个缓存行锁定，那么在缓存一致性机制的做用下，会致使其余处理器不能访问本身高速缓存中的尾节点，而队列的入队和出队操做是须要不停修改头接点和尾节点，因此在多处理器的状况下将会严重影响到队列的入队和出队效率。Doug lea使用追加到64字节的方式来填满高速缓冲区的缓存行，避免头接点和尾节点加载到同一个缓存行，使得头尾节点在修改时不会互相锁定。

那么是否是在使用Volatile变量时都应该追加到64字节呢？不是的。在两种场景下不该该使用这种方式。第一：缓存行非64字节宽的处理器，如P6系列和奔腾处理器，它们的L1和L2高速缓存行是32个字节宽。第二：共享变量不会被频繁的写。由于使用追加字节的方式须要处理器读取更多的字节到高速缓冲区，这自己就会带来必定的性能消耗，共享变量若是不被频繁写的话，锁的概率也很是小，就不必经过追加字节的方式来避免相互锁定。

JSR133中文版.pdf 

它们的定义以下：

 某个管程 m 上的解锁动做 synchronizes-with 全部后续在 m 上的锁定动做 （这里的后续是根据同步顺序定义的）。

 对 volatile 变量 v 的写操做 synchronizes-with 全部后续任意线程对 v 的读操 做（这里的后续是根据同步顺序定义的）。

 用于启动一个线程的动做 synchronizes-with 该新启动线程中的第一个动做。

 线程 T1 的最后一个动做 synchronizes-with 线程 T2 中任一用于探测 T1 是否 终止的动做。T2 可能经过调用 T1.isAlive()或者在 T1 上执行一个 join 动做 来达到这个目的。

 若是线程 T1 中断了线程 T2，T1 的中断操做 synchronizes-with 任意时刻任 何其它线程（包括 T2）用于肯定 T2 是否被中断的操做。这能够经过抛出 一个 InterruptedException 或调用 Thread.interrupted 与 Thread.isInterrupted 来实现。

 为每一个变量写默认值（0，false 或 null）的动做 synchronizes-with 每一个线程 中的第一个动做。 虽然在对象分配以前就为该对象中的变量写入默认值看起来有些奇怪，从 概念上看，程序启动建立对象时都带有默认的初始值。所以，任何对象的 默认初始化操做 happens-before 程序中的任意其它动做（除了写默认值的 操做）。

 调用对象的终结方法时，会隐式的读取该对象的引用。从一个对象的构造 器末尾到该引用的读取之间存在一个 happens-before 边缘。注意，该对象 的全部冻结操做（见 9.2 节）happen-before 前面那个 happens-before 边缘 的起始点。