并发编程之volatile详解

并发编程的可见性，原子性与有序性问题

原子性

​ 原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不
会被其他线程影响。

​ 在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是,对于32位系统来说，对于基本数据类型都是读写操作，long类型和double类型数据的读写并非是原子性，也就是说，如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，商用虚拟机基本是64位。

可见性

​ 理解了指令重排现象，可见性就容易了，可见性指的是一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。对于单线程来说，只能看到修改变量后的值，是不存在可见性的。

​ 但在多线程环境就不一定，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行才做才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中共享变量x对于线程B来说并不可见，这种工作内存与主内存同步延迟现象造就了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过前面的分析，我们知道无论是编译器优化，还是处理器优化的重拍现象，在多线程环境下，确实会导致程序轮序执行的问题，从而也就导致可见性问题。

有序性

​ 有序性是指对于单线程执行代码，我们重视认为代码的执行顺序依次执行，这样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟

JMM如何解决原子性&可见性&有序性问题

原子性问题

​ 除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过synchronized和Lock实现原子性。因为sycchronized和Lock能够保证任意时刻只有一个线程访问代码。

可见性问题

​ volatile关键字保证可见性。当一个共享变量被volatile修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值。synchronized和Lock也可以保证可见性，因为它们可以保证任一时刻只有一个线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。

有序性问题

​ 在Java里面，可以通过volatile关键字来保证一定的“有序性”,另外可以通过synchronized和Lock来保证有序性，很显然，synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

​ **Java内存模型：**每个线程都有自己的工作内存。线程对变量的操作都必须在工作内存中进行，而不能直接对主内存进行操作。并且每个线程不能访问其他线程的工作内存。。Java内存模型具备一些先天的“有序性”，即不需要通过任何手段就能够得到保证的有序性，这个通常也称为happens-before 原则。如果两个操作的执行次序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以随意地对它们进行重排序。

​ **指令重排：**Java语言规范规定JVM线程内部维持顺序华语义。即只要程序的最终结果与顺序化情况结果相同，那么指令的执行顺序可以与代码顺序不一致，这个过程交指令重排。指令重排的意义是什么？JVM能根据处理器特性适当的对机器指令进行重排序，使机器指令更符合CPU的执行特性，最大限度的发挥机器性能。

​ 下图为从源码到最终执行的指令序列示意图：

as-if-serial语义

​ as-if-serial语义的意识是，不管怎么重排序，程序的执行结果不能改变。编译器，rentime和处理器都必须准售as-if-serial语义。

​ 为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为重排序会干煸执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

happens-before原则

​ 只靠sychronized和volatile关键字来保证原子性、可见性以及有序性，那么编写并发程序可能会显得十分麻烦，幸运的是，从JDK 5开始，Java使用新的JSR-133内存模型，提供了happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是判断数据是否存在竞争、线程是否安全的依据，happens-before 原则内容如下

1. 程序顺序规则，即在一个线程内必须保证语义串行性，也就是说按照代码顺序执
   行。
2. 锁规则 解锁(unlock)操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说，如果对于一个锁解锁后，再加锁，那么加锁的动作必须在解锁动作之后(同一个锁)。
3. volatile规则 volatile变量的写，先发生于读，这保证了volatile变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的线程总是能够看到该变量的最新值。
4. 线程启动规则 线程的start()方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start方法时，线程A对共享变量的修改对线程B可见
5. A先于B ，B先于C 那么A必然先于C
6. 线程终止规则线程的所有操作先于线程的终结，Thread.join()方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的join方法成功返回后，线程B对共享变量的修改将对线程A可见。
7. 线程中断规则对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断
8. 对象终结规则对象的构造函数执行，结束先于finalize()方法

volatile无法保证原子性

​

public class VolatileVisibility {
    public static volatile int i = 0;
    public static void increase(){
        i++;
    }
}

​ 在并发场景下，i变量的任何改变都会立马反应到其他线程中，但是如此多条线程同事调用increase（）方法，就会出现线程安全问题，毕竟i++操作并不具备原子性，该操作是先读取值，然后写回一个新值，相当于原来的值加1，分两部完成，如果第二个线程在第一个线程读取到旧值和写回新值期间读取i的预值，那么第二个线程会与第一个线程一起看到同一个值，并执行相同的加1操作，这也就造成了线程安全失败,因此对于increase()方法，必须使用synchronzied修饰，以便包装线程安全，需要注意一旦使用synchronized修饰后，由于synchronized本身具备与volatile相同的特性，即可见性，因此在这样情况下就完全省去volatile修饰变量。

volatile禁止指令重排

​ volatile关键字另一个作用就是禁止指令重排，从而避免多线程环境出现乱序执行的现象，关于指令重排优化前面已经详细分析过，这里主要描述一下volatile是如何禁止指令重排的，先了解一个概念，交内存屏障（Memory Barrier）。

硬件层的内存屏障

​ Intel硬件提供了一系列的内存屏障，主要有：

1. lfence，是一种LoadBarrier读屏障

2. sfence，是一种StoreBarrier写屏障

3. mfence，是一种全能型的屏障，具备ifence和sfence的能力4.Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对CPU总线和高速缓存加锁，可以理解为CPU指令级的一种锁。它后面可以跟ADD,ADC,AND,BTC,BTR,BTS,CMPXCHG,CMPXCH8B,DEC,INC,NEG,NOT,OR,SBB,SUB,XOR,XADD,andXCHG等指令

   ​ 不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由JVM来为不同的平台生成相应的机器码。JVM提供了四种内存屏障指令：

   屏障类型	指令示例	说明
   LoadLoad	Load1; LoadLoad; Load2	保证load1的读取操作在load2及后续读取操作之前执行
   StoreStore	Store1; StoreStore; Store2	在store2及其后的写操作执行前，保证store1的写操作已刷新到主内存
   LoadStore	Load1; LoadStore; Store2	在stroe2及其后的写操作执行前，保证load1的读操作已读取结束
   StoreLoad	Store1; StoreLoad; Load2	保证store1的写操作已刷新到主内存之后，load2及其后的读操作才能执行

   ​ 内存屏障，是一个CPU指令，它有两个作用，一是保证特定操作的执行顺序，二是保证某些变量的内存可见性（利用该特效实现volatile的内存可见性）。**由于编译器和处理器都能执行指令重排优化。**如果在指令间插入一条Memory Barrier则会告诉编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插入内存屏障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另一个作用是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。总之，volatile变量正式通过内存屏障实现其在内存中的语义，即可见性和禁止重排优化。

   

   ​ 上述代码一个经典的单例的双重检测代码，这段代码在单线程环境下并没有什么问题，但如果在多线程环境下就可以出现线程安全问题。原因在于某一个线程执行到第一次检测，读取到的instance不为null时，instance的引用对象可能没有完成初始化。

   

   ​

   ​ 由于步骤2和步骤3不存在数据依赖关系，而且无论重排前还是重排后程序的执行结果在单线程中并没有改变，因此这种重排优化是允许的，但是指令重排只会保证串行语义的执行一致性（单线程），但并不会关心多线程间的语义一致性。所以当一条线程访问instance不为null时，由于instace实例化未必已经初始化完成，也就造成了线程安全问题。那么该如何解决呢，很简单，我们使用volatile禁止instace变量被执行指令重排优化即可。

volatile内存语义的实现

​ 前面提到重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义，JMM会分别限制这两种类型的重排序类型。

第一个操作	第二个操作：普通读写	第二个操作：volatile读	第二个操作：volatile写
普通读写	可以重排	可以重排	不可以重排
volatile读	不可以重排	不可以重排	不可以重排
volatile写	可以重排	不可以重排	不可以重排

从上图可以看出：

当第二个操作是volatile写时，不管第一个操作是什么，都不能重排序。这个规则确保volatile写之前不会被编译器重排序到volatile写之后。

当一个操作是volatile读时，不管第二个操作是什么，都不能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。

当第一个操作是volatile写，第二个操作是volatile读或写时，不能重排序。

​ 为了实现volatile’的内存语义，编译器生产字节码时，会在指令序列中插入内存屏障来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的总数几乎不可能。为此，JMM才去保守策略。下面是基于保守策略的JMM内存屏障插入策略。

• • 在每个volatile写操作的前面插入一个StoreStore屏障。
  • ·在每个volatile写操作的后面插入一个StoreLoad屏障。
  • ·在每个volatile读操作的后面插入一个LoadLoad屏障。
  • ·在每个volatile读操作的后面插入一个LoadStore屏障。

上述内存屏障插入策略非常保守，但它可以保证在任意处理器平台，任意的程序中都能得到正确的volatile内存语义。下面是保守策略下，volatile写插入内存屏障后生成的指令序列示意图。

​ 上图中StoreStore屏障可以保证在volatile写之前,其前面的所有普通写操作已经对任意处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新到主内存。

​ 这里比较有意思的是，volatile写后面的StoreLoad屏障。此屏障的作用是避免volatile写与 后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在一个volatile写的后面 是否需要插入一个StoreLoad屏障（比如，一个volatile写之后方法立即return）。为了保证能正确 实现volatile的内存语义，JMM在才去保守策略：在每个volatile写的后面，或者在每个volatile 读的前面插入一个StoreLoad屏障。从整体执行效率的角度考虑，JMM最终选择了在每个 volatile写的后面插入一个StoreLoad屏障。因为volatile写-读内存语义的常见使用模式是：一个 写线程写volatile变量，多个读线程读同一个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写之后插入StoreLoad屏障将带来可观的执行效率的提升。从这里可以看到JMM 在实现上的一个特点：首先确保正确性，然后再去追求执行效率。

上图中LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。

上诉讲的东西知道理解就好，面试的时候将出个大概就很ok了。
（仅供自己学习记录）