并发编程-volatile以及JMM

volatile的做用

volatile可使得在多处理器环境下保证了共享变量的可见性，那么到底什么是可见性呢？不知道你们有没有思考过这个问题

在单线程的环境下，若是向一个变量先写入一个值，而后在没有写干涉的状况下读取这个变量的值，那这个时候读取到的这个变量的值应该是以前写入的那个值。这原本是一个很正常的事情。可是在多线程环境下，读和写发生在不一样的线程中的时候，可能会出现：读线程不能及时的读取到其余线程写入的最新的值。这就是所谓的可见性

为了实现跨线程写入的内存可见性，必须使用到一些机制来实现。而volatile就是这样一种机制

volatile关键字是如何保证可见性的？

查看代码的汇编指令，

会发现，在修改带有volatile修饰的成员变量时，会多一个lock指令。lock是一种控制指令，在多处理器环境下，lock汇编指令能够基于总线锁或者缓存锁的机制来达到可见性的一个效果。

从硬件层面了解可见性的本质

一台计算机中最核心的组件是CPU、内存、以及I/O设备。在整个计算机的发展历程中，除了CPU、内存以及I/O设备不断迭代升级来提高计算机处理性能以外，还有一个很是核心的矛盾点，就是这三者在处理速度的差别。CPU的计算速度是很是快的，内存次之、最后是IO设备好比磁盘。而在绝大部分的程序中，必定会存在内存访问，有些可能还会存在I/O设备的访问

为了提高计算性能，CPU从单核升级到了多核甚至用到了超线程技术最大化提升CPU的处理性能，可是仅仅提高CPU性能还不够，若是后面二者的处理性能没有跟上，意味着总体的计算效率取决于最慢的设备。为了平衡三者的

速度差别，最大化的利用CPU提高性能，从硬件、操做系统、编译器等方面都作出了不少的优化

1. CPU增长了高速缓存

2. 操做系统增长了进程、线程。经过CPU的时间片切换最大化的提高CPU的使用率

3. 编译器的指令优化，更合理的去利用好CPU的高速缓存

 

而后每一种优化，都会带来相应的问题，而这些问题也是致使线程安全性问题的根源。为了了解前面提到的可见性问题的本质，咱们有必要去了解这些优化的过程

CPU高速缓存

线程是CPU调度的最小单元，线程设计的目的最终仍然是更充分的利用计算机处理的效能，可是绝大部分的运算任务不能只依靠处理器“计算”就能完成，处理器还须要与内存交互，好比读取运算数据、存储运算结果，这个I/O操做是很难消除的。而因为计算机的存储设备与处理器的运算速度差距很是大，因此现代计算机系统都会增长一层读写速度尽量接近处理器运算速度的高速缓存来做为内存和处理器之间的缓冲：将运算须要使用的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步到内存之中。

经过高速缓存的存储交互很好的解决了处理器与内存的速度矛盾，可是也为计算机系统带来了更高的复杂度，由于它引入了一个新的问题，缓存一致性。

什么叫缓存一致性呢？

首先，有了高速缓存的存在之后，每一个CPU的处理过程是，先将计算须要用到的数据缓存在CPU高速缓存中，在CPU进行计算时，直接从高速缓存中读取数据而且在计算完成以后写入到缓存中。在整个运算过程完成后，再把缓存中的数据同步到主内存。

因为在多CPU种，每一个线程可能会运行在不一样的CPU内，而且每一个线程拥有本身的高速缓存。同一份数据可能会被缓存到多个CPU中，若是在不一样CPU中运行的不一样线程

看到同一分内存的缓存值不同就会存在缓存不一致的问题

为了解决缓存不一致的问题，在CPU层面作了不少事情，主要提供了两种解决办法

1. 总线锁

2. 缓存锁

 

总线锁和缓存锁

总线锁，简单来讲就是，在多cpu下，当其中一个处理器要对共享内存进行操做的时候，在总线上发出一个LOCK#信号，这个信号使得其余处理器没法经过总线来访问到共享内存中的数据，总线锁定把CPU和内存之间的通讯锁住了，这使得锁按期间，其余处理器不能操做其余内存地址的数据，因此总线锁定的开销比较大，这种机制显然是不合适的

如何优化呢？最好的方法就是控制锁的保护粒度，咱们只须要保证对于被多个CPU缓存的同一份数据是一致的就行。因此引入了缓存锁，它核心机制是基于缓存一致性协议来实现的。

缓存一致性协议

为了达到数据访问的一致，须要各个处理器在访问缓存时

遵循一些协议，在读写时根据协议来操做，常见的协议有MSI，MESI，MOSI等。最多见的就是MESI协议。接下来给你们简单讲解一下MESI

MESI表示缓存行的四种状态，分别是

1. M(Modify) 表示共享数据只缓存在当前CPU缓存中，而且是被修改状态，也就是缓存的数据和主内存中的数据不一致

2. E(Exclusive) 表示缓存的独占状态，数据只缓存在当前CPU缓存中，而且没有被修改

3. S(Shared) 表示数据可能被多个CPU缓存，而且各个缓存中的数据和主内存数据一致

4. I(Invalid) 表示缓存已经失效

 

在MESI协议中，每一个缓存的缓存控制器不只知道本身的读写操做，并且也监听(snoop)其它Cache的读写操做

对于MESI协议，从CPU读写角度来讲会遵循如下原则：

CPU读请求：缓存处于M、E、S状态均可以被读取，I状态CPU只能从主存中读取数据

CPU写请求：缓存处于M、E状态才能够被写。对于S状态的写，须要将其余CPU中缓存行置为无效才可写

总结可见性的本质

因为CPU高速缓存的出现使得若是多个cpu同时缓存了相同的共享数据时，可能存在可见性问题。也就是CPU0修改了本身本地缓存的值对于CPU1不可见。不可见致使的后果是CPU1后续在对该数据进行写入操做时，是使用的脏数据。使得数据最终的结果不可预测。

你可能但愿在代码里面去模拟一下可见性的问题，实际上，这种状况很难模拟。由于咱们没法让某个线程指定某个特定CPU，这是系统底层的算法，JVM应该也是无法控制的。还有最重要的一点，就是你没法预测CPU缓存何时会把值传给主存，可能这个时间间隔很是短，短到你没法观察到。最后就是线程的执行的顺序问题，由于多线程你没法控制哪一个线程的某句代码会在另外一个线程的某句代码后面立刻执行。

因此咱们只能基于它的原理去了解这样一个存在的客观事

了解到这里，你们应该会有一个疑问，刚刚不是说基于缓存一致性协议或者总线锁可以达到缓存一致性的要求吗？为何还须要加volatile关键字？或者说为何还会存在可见性问题呢？

MESI优化带来的可见性问题

MESI协议虽然能够实现缓存的一致性，可是也会存在一些问题。

就是各个CPU缓存行的状态是经过消息传递来进行的。若是CPU0要对一个在缓存中共享的变量进行写入，首先须要发送一个失效的消息给到其余缓存了该数据的CPU。而且要等到他们的确认回执。CPU0在这段时间内都会处于阻塞状态。为了不阻塞带来的资源浪费。在cpu中引入了StoreBufferes。

CPU0只须要在写入共享数据时，直接把数据写入到storebufferes中，同时发送invalidate消息，而后继续去处理其余指令。

当收到其余全部CPU发送了invalidate acknowledge消息时，再将storebufferes中的数据数据存储至cache line中。最后再从缓存行同步到主内存。

可是这种优化存在两个问题

1. 数据何时提交是不肯定的，由于须要等待其余cpu给回复才会进行数据同步。这里实际上是一个异步操做

2. 引入了storebufferes后，处理器会先尝试从storebuffer中读取值，若是storebuffer中有数据，则直接从storebuffer中读取，不然就再从缓存行中读取

咱们来看一个例子

 

exeToCPU0和exeToCPU1分别在两个独立的CPU上执行。假如CPU0的缓存行中缓存了isFinish这个共享变量，而且状态为（E）、而Value多是（S）状态。

那么这个时候，CPU0在执行的时候，会先把value=10的指令写入到storebuffer中。而且通知给其余缓存了该value变量的CPU。在等待其余CPU通知结果的时候，CPU0会继续执行isFinish=true这个指令。

而由于当前CPU0缓存了isFinish而且是Exclusive状态,所

以能够直接修改isFinish=true。这个时候CPU1发起read操做去读取isFinish的值可能为true，可是value的值不等于10。

这种状况咱们能够认为是CPU的乱序执行，也能够认为是一种重排序，而这种重排序会带来可见性的问题

这下硬件工程师也抓狂了，咱们也能理解，从硬件层面很难去知道软件层面上的这种先后依赖关系，因此没有办法经过某种手段自动去解决。

因此硬件工程师就说：既然怎么优化都不符合你的要求，要不你来写吧。

因此在CPU层面提供了memory barrier(内存屏障)的指令，从硬件层面来看这个memroy barrier就是CPU flush store bufferes中的指令。软件层面能够决定在适当的地方来插入内存屏障。

CPU层面的内存屏障

什么是内存屏障?从前面的内容基本能有一个初步的猜测，内存屏障就是将store bufferes中的指令写入到内存，从而使得其余访问同一共享内存的线程的可见性。

X86的memory barrier指令包括lfence(读屏障) sfence(写屏障) mfence(全屏障)

Store Memory Barrier(写屏障) 告诉处理器在写屏障以前的全部已经存储在存储缓存(store bufferes)中的数据同步到主内存，简单来讲就是使得写屏障以前的指令的结果对屏障以后的读或者写是可见的

Load Memory Barrier(读屏障) 处理器在读屏障以后的读操做,都在读屏障以后执行。配合写屏障，使得写屏障以前的内存更新对于读屏障以后的读操做是可见的

Full Memory Barrier(全屏障) 确保屏障前的内存读写操做的结果提交到内存以后，再执行屏障后的读写操做

有了内存屏障之后，对于上面这个例子，咱们能够这么来改，从而避免出现可见性问题

总的来讲，内存屏障的做用能够经过防止CPU对内存的乱序访问来保证共享数据在多线程并行执行下的可见性

可是这个屏障怎么来加呢？回到最开始咱们讲volatile关键字的代码，这个关键字会生成一个Lock的汇编指令，这个指令其实就至关于实现了一种内存屏障

这个时候问题又来了，内存屏障、重排序这些东西好像是和平台以及硬件架构有关系的。做为Java语言的特性，一次编写多处运行。咱们不该该考虑平台相关的问题，而且这些所谓的内存屏障也不该该让程序员来关心。

什么是JMM

JMM全称是JavaMemory Model.什么是JMM呢？

经过前面的分析发现，致使可见性问题的根本缘由是缓存以及重排序。而JMM实际上就是提供了合理的禁用缓存以及禁止重排序的方法。因此它最核心的价值在于解决可见性和有序性。

JMM属于语言级别的抽象内存模型，能够简单理解为对硬件模型的抽象，它定义了共享内存中多线程程序读写操做的行为规范：在虚拟机中把共享变量存储到内存以及从内存中取出共享变量的底层实现细节

经过这些规则来规范对内存的读写操做从而保证指令的正确性，它解决了CPU多级缓存、处理器优化、指令重排序致使的内存访问问题，保证了并发场景下的可见性。

须要注意的是，JMM并无限制执行引擎使用处理器的寄存器或者高速缓存来提高指令执行速度，也没有限制编译器对指令进行重排序，也就是说在JMM中，也会存在缓存一致性问题和指令重排序问题。只是JMM把底层的问题抽象到JVM层面，再基于CPU层面提供的内存屏障指令，以及限制编译器的重排序来解决并发问题

JMM抽象模型分为主内存、工做内存；主内存是全部线程共享的，通常是实例对象、静态字段、数组对象等存储在堆内存中的变量。工做内存是每一个线程独占的，线程对变量的全部操做都必须在工做内存中进行，不能直接读写主内存中的变量，线程之间的共享变量值的传递都是基于主内存来完成

Java内存模型底层实现能够简单的认为：经过内存屏障(memory barrier)禁止重排序，即时编译器根据具体的底层体系架构，将这些内存屏障替换成具体的CPU 指令。对于编译器而言，内存屏障将限制它所能作的重排序优化。而对于处理器而言，内存屏障将会致使缓存的刷新操做。好比，对于volatile，编译器将在volatile字段的读写操做先后各插入一些内存屏障。

JMM是如何解决可见性有序性问题的

简单来讲，JMM提供了一些禁用缓存以及进制重排序的方法，来解决可见性和有序性问题。这些方法你们都很熟悉：volatile、synchronized、final；

JMM如何解决顺序一致性问题

重排序问题

为了提升程序的执行性能，编译器和处理器都会对指令作重排序，其中处理器的重排序在前面已经分析过了。所谓的重排序其实就是指执行的指令顺序。

编译器的重排序指的是程序编写的指令在编译以后，指令可能会产生重排序来优化程序的执行性能。

编译器的重排序，JMM提供了禁止特定类型的编译器重排序。

处理器重排序，JMM会要求编译器生成指令时，会插入内

存屏障来禁止处理器重排序

固然并非全部的程序都会出现重排序问题

编译器的重排序和CPU的重排序的原则同样，会遵照数据依赖性原则，编译器和处理器不会改变存在数据依赖关系的两个操做的执行顺序,好比下面的代码，

a=1; b=a; 

a=1;a=2;

a=b;b=1;

这三种状况在单线程里面若是改变代码的执行顺序，都会致使结果不一致，因此重排序不会对这类的指令作优化。这种规则也成为as-if-serial。无论怎么重排序，对于单个线程来讲执行结果不能改变。好比

int a=2;//1

int b=3;//2

int rs=a*b; //3

1和三、2和3存在数据依赖，因此在最终执行的指令中，3不能重排序到1和2以前，不然程序会报错。因为1和2不存在数据依赖，因此能够从新排列1和2的顺序

JMM层面的内存屏障

为了保证内存可见性，Java编译器在生成指令序列的适当

位置会插入内存屏障来禁止特定类型的处理器的重排序，在JMM中把内存屏障分为四类

HappenBefore

它的意思表示的是前一个操做的结果对于后续操做是可见的，因此它是一种表达多个线程之间对于内存的可见性。因此咱们能够认为在JMM中，若是一个操做执行的结果须要对另外一个操做课件，那么这两个操做必需要存在happens-before关系。这两个操做能够是同一个线程，也能够是不一样的线程

JMM中有哪些方法创建happen-before规则

程序顺序规则

1. 一个线程中的每一个操做，happens-before于该线程中的任意后续操做;能够简单认为是as-if-serial。单个线程

中的代码顺序无论怎么变，对于结果来讲是不变的

 

2. volatile变量规则，对于volatile修饰的变量的写的操做，必定happen-before后续对于volatile变量的读操做；

根据volatile规则，2happens before 3

 

3. 传递性规则，若是1 happens-before 2; 3happens-before 4; 那么传递性规则表示:1 happens-before 4;

4. start规则，若是线程A执行操做ThreadB.start(),那么线程A的ThreadB.start()操做happens-before线程B中

的任意操做

 

 

 

5. join规则，若是线程A执行操做ThreadB.join()并成功返回，那么线程B中的任意操做happens-before于线程A从ThreadB.join()操做成功返回。

 

Thread
t 1 = new
// 此处对共享变量 x 修改
x = 100
});
//
例如此处对共享变量修改，
//
则这个修改结果对线程 t1 可见
//
主线程启动子线程
t1.start();
t1.join();
//
子线程全部对共享变量的修改
//
在主线程调用 t1 .join() 以后皆可见
//
此例中， x = 100

 

6. 监视器锁的规则，对一个锁的解锁，happens-before于随后对这个锁的加锁

 

synchronized (this) { //
此处自动加锁
// x 是共享变量 , 初始值 =10
if (this.x < 12) {
this.x = 12;
}
} //
此处自动解锁

假设x 的初始值是10，线程A 执行完代码块后x 的值会变成12（执行完自动释放锁），线程B 进入代码块时，可以看到线程A 对x 的写操做，也就是线程B 可以看到x==12。