并发专题（三）Volatile

Java语言规范第三版中对volatile的定义如下： java编程语言允许线程访问共享变量，为了确保共享变量能被准确和一致的更新，线程应该确保通过排他锁单独获得这个变量。

Volatile的定义和原理

Volatile是轻量级的Synchronized，比之执行成本更低，因为它不会引起线程的上下文切换，它在多处理器开发中保证了共享变量的“可见性”，“可见性”的意思是当一个线程修改一个变量时，另外一个线程能读到这个修改的值。Java语言提供了volatile，在某些情况下比锁更加方便。如果一个字段被声明成volatile，java线程内存模型确保所有线程看到这个变量的值是一致的。

package com.own.learn.concurrent.Volatile;

public class VolatileBarrierExample {

    volatile Long v1 = null;

    public static void main(String[] args) {

        VolatileBarrierExample ex = new VolatileBarrierExample();
        ex.readAndWrite();
    }

    void readAndWrite() {
        v1 = 1L;
    }
}

JIT转化汇编代码：（v1变量）

  0x00007f55cd100684: mov    0x20(%rsp),%rsi
  0x00007f55cd100689: mov    %rax,%r10
  0x00007f55cd10068c: shr    $0x3,%r10
  0x00007f55cd100690: mov    %r10d,0xc(%rsi)
  0x00007f55cd100694: shr    $0x9,%rsi
  0x00007f55cd100698: movabs $0x7f55dd1cb000,%rdi
  0x00007f55cd1006a2: movb   $0x0,(%rsi,%rdi,1)
  0x00007f55cd1006a6: lock addl $0x0,(%rsp)  

通过查IA-32架构软件开发者手册可知，lock前缀的指令在多核处理器下会引发了两件事情。

将当前处理器缓存行的数据会写回到系统内存。
Lock前缀指令导致在执行指令期间，声言处理器的 LOCK# 信号。在多处理器环境中，LOCK# 信号确保在声言该信号期间，处理器可以独占使用任何共享内存。（因为它会锁住总线，导致其他CPU不能访问总线，不能访问总线就意味着不能访问系统内存），但是在最近的处理器里，LOCK＃信号一般不锁总线，而是锁缓存，毕竟锁总线开销比较大。在8.1.4章节有详细说明锁定操作对处理器缓存的影响，对于Intel486和Pentium处理器，在锁操作时，总是在总线上声言LOCK#信号。但在P6和最近的处理器中，如果访问的内存区域已经缓存在处理器内部，则不会声言LOCK#信号。相反地，它会锁定这块内存区域的缓存并回写到内存，并使用缓存一致性机制来确保修改的原子性，此操作被称为“缓存锁定”，缓存一致性机制会阻止同时修改被两个以上处理器缓存的内存区域数据。
ps： CPU的位数指的是数据总线位数，而决定最大支持内存的则是地址总线位数。

写回内存的操作会引起在其他CPU里缓存了该内存地址的数据无效。 
IA-32处理器和Intel 64处理器使用MESI（修改，独占，共享，无效）控制协议去维护内部缓存和其他处理器缓存的一致性。在多核处理器系统中进行操作的时候，IA-32 和Intel 64处理器能嗅探其他处理器访问系统内存和它们的内部缓存。它们使用嗅探技术保证它的内部缓存，系统内存和其他处理器的缓存的数据在总线上保持一致。例如在Pentium和P6 family处理器中，如果通过嗅探一个处理器来检测其他处理器打算写内存地址，而这个地址当前处理共享状态，那么正在嗅探的处理器将无效它的缓存行，在下次访问相同内存地址时，强制执行缓存行填充。volatile的可见性分析

package com.own.learn.concurrent.Volatile;

public class VolatileVisibilityTest2 {

    public volatile boolean flag = false;

    public static void main(String[] args) {

        final VolatileVisibilityTest2 volatileVisibilityTest2 = new VolatileVisibilityTest2();

        new Thread(() -> {
            try {
                Thread.sleep(10);
            } catch (Exception e) {
                e.printStackTrace();
            }
            volatileVisibilityTest2.flag = true;
        }).start();

        new Thread(() -> {
            while (!volatileVisibilityTest2.flag) {
            }

            System.out.println("  2 " + true);
        }).start();

    }
}

主线程定义了一个flag变量，两个子线程相互修改是可见的。 
线程本身并不直接与主内存进行数据的交互，而是通过线程的工作内存来完成相应的操作。这也是导致线程间数据不可见的本质原因。因此要实现volatile变量的可见性，直接从这方面入手即可。对volatile变量的写操作与普通变量的主要区别有两点： 
　　（1）修改volatile变量时会强制将修改后的值刷新的主内存中。 
　　（2）修改volatile变量后会导致其他线程工作内存中对应的变量值失效。因此，再读取该变量值的时候就需要重新从读取主内存中的值。 
　　通过这两个操作，就可以解决volatile变量的可见性问题。

原子性

volatile只能保证对单次读/写的原子性。因为long和double两种数据类型的操作可分为高32位和低32位两部分，因此普通的long或double类型读/写可能不是原子的。因此，鼓励大家将共享的long和double变量设置为volatile类型，这样能保证任何情况下对long和double的单次读/写操作都具有原子性。

package com.own.learn.concurrent.Volatile;

public class VolatileActorTest {
    volatile int i;

    public void addI() {
        i++;
    }
    public static void main(String[] args) throws Exception {
        VolatileActorTest volatileActorTest = new VolatileActorTest();
        for (int i=0; i< 100; i++) {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    volatileActorTest.addI();
                }
            }).start();
        }
        Thread.sleep(1000);//等待10秒，保证上面程序执行完成

        System.out.println(volatileActorTest.i);

    }
}

多执行几次发现，结果不一定是100.

防重排序

public class VolatileSingleTest {

    volatile static B b = null;

    public synchronized void getB() {
        if (b == null) {

            synchronized (VolatileSingleTest.class) {
                if (null == b) {
                    b = new B();
                }
            }

        }
    }

    class B {

    }

}

b = new B();其实发生了三件事： 
memory = allocate(); //1：为对象分配内存空间 
ctorInstance(memory) /:2 ：初始化对象 
instance = memory;//3 ： 设置instance指向刚分配的内存地址 
其中，volatile担心2和3重排了

Volatile的使用优化

队列集合类LinkedTransferQueue，在使用volatile变量时，追加64字节的方式来优化队列出队和入队的性能

/** 队列中的头部节点 */
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字节的方式来填满高速缓冲区的缓存行，避免头节点和尾节点加载到同一个缓存行，使头、尾节点在修改时不会互相锁定。