4.JMM与volatile

JMM于volatile

JMM

定义

​ JVM规范中试图定义一种Java内存模型(java Memory Model，简称JMM)来屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果。
所以，推导出我们需要知道JMM

定义：

JMM(Java内存模型Java Memory Model，简称JMM)本身是一种抽象的概念并不真实存在它仅仅描述的是一组约定或规范，通过这组规范定义了程序中(尤其是多线程)各个变量的读写访问方式并决定一个线程对共享变量的写入何时以及如何变成对另一个线程可见，关键技术点都是围绕多线程的原子性、可见性和有序性展开的。

原则:
JMM的关键技术点都是围绕多线程的原子性、可见性和有序性展开的
能干嘛?

1. 通过JMM来实现线程和主内存之间的抽象关系。

2. 屏蔽各个硬件平台和操作系统的内存访问差异以实现让Java程序在各种平台下都能达到一致的内存访问效果。

三大特性

可见性

当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道该变更，JMM规定了所有的变量都存储在主内存中。

系统主内存共享变量数据修改被写入的时机是不确定的，多线程并发下很可能出现"脏读""，所以每个线程都有自己的工作内存、线程自己的工作内存中保存了该线程使用到的变量的主内存副本拷贝，线程对变量的所有操作《读取，赋值等）都必需在线程自己的工作内存中进行，而不能够直接读写主内存中的变量。不同线程之间也无法直接访问对方工作内存中的变量，线程间变量值的传递均需要通过主内存来完成

产生问题：线程脏读

原子性

指一个操作是不可打断的，即多线程环境下，操作不能被其他线程干扰

有序性

是什么
对于一个线程的执行代码而言，我们总是习惯性认为代码的执行总是从上到下，有序执行。但为了提升性能，编译器和处理器通常会对指令序列进行重新排序。Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。
优缺点
JVM能根据处理器特性(CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。但是，指令重排可以保证串行语义一致，但没有义务保证多线程间的语义也一致(即可能产生"脏读")，简单说，两行以上不相干的代码在执行的时候有可能先执行的不是第一条，不见得是从上到下顺序执行，执行顺序会被优化。
从源码到最终执行示例图:

单线程环境里面确保程序最终执行结果和代码顺序执行的结果一致。

处理器在进行重排序时必须要考虑指令之间的数据依赖性
多线程环境中线程交替执行,由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的,结果无法预测。===>有时候要禁止指令重排

多线程的读写过程

1. 由于JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间)，工作内存是每个线程的私有数据区域，而Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到的线程自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，各个线程中的工作内存中存储着主内存中的变量副本拷贝，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成，其简要访问过程如下图:

2. JMM定义了线程和主内存之间的抽象关系
   1线程之间的共享变量存储在主内存中(从硬件角度来说就是内存条)
   2每个线程都有一个私有的本地工作内存，本地工作内存中存储了该线程用来读/写共享变量的副本(从硬件角度来说就是CPU的缓存.比如寄存器、L1、L2、L3缓存等)

多线程的先行发生机制happens-before

​ 在JMM中，如果一个操作执行的结果需要对另一个操作可见性或者代码重排序，那么这两个操作之间必须存在happens-before(先行发生)原则。逻辑上的先后关系

案例说明

先行发生原则说明：

​ 如果Java内存模型中所有的有序性都仅靠volatile和synchronized来完成，那么有很多操作都将会变得非常啰嗦，但是我们在编写Java并发代码的时候并没有察觉到这一点。

​ 我们没有时时、处处、次次，添加volatile和synchronized来完成程序，这是因为Java语言中JMM原则下有一个“先行发生”(Happens-Before)的原则限制和规矩，给你立好了规矩!

这个原则非常重要:
它是判断数据是否存在竞争，线程是否安全的非常有用的手段。依赖这个原则，我们可以通过几条简单规则一揽子解决并发环境下两个操作之间是否可能存在冲突的所有问题，而不需要陷入Java内存模型苦涩难懂的底层编译原理之中。

总原则

​ 如果一个操作happens-before另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行顺序排在第二个操作之前。
​ 两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种重排序并不非法。

8条具体规则

1. 次序规则:

   一个线程内 ，按照代码顺序，写在前面的操作先行发生于后面的操作；

   前一个操作的执行结果可以被后面的操作获取

2. 锁定规则:

   一个unlock操作先行发生于后面（时间上的先后）对同一个锁的lock操作

   （一个线程进入加锁的代码块后，只有先释放锁其他线程才能获得锁）

3. volatile变量规则:

   对一个volatile变量的写操作先行发生于后面（时间上的先后）对这个变量的读操作 - 前面的写对后面的读是可见的

4. 传递规则:

   如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C;

5. 线程启动规则(Thread Start Rule):

   Thread对象的start()方法先行发生于此线程的每一个动作（要执行一个线程，首先线程的状态要先发生改变-从新建到-》就绪）

6. 线程中断规则(Thread lnterruption Rule):

   对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生;（要先设置线程中断标志位才能进行检测）----》也就是说你要先调用interrupt()方法设置过中断标志位，我才能检测到中断发送

7. 线程终止规则(Thread Termination Rule):

   线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过isAlve()等手段检测线程是否已经终止执行。

8. 对象终结规则(Finalizer Rule):

   一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始

总结

​ 在Java 语言里面，Happens-Before的语义本质上是一种可见性
​ A Happens-Before B 意味着A发生过的事情对B来说是可见的，无论A事件和B事件是否发生在同一个线程里
​ JMM的设计分为两部分:
​ 一部分是面向我们程序员提供的，也就是happens-before规则，它通俗易懂的向我们程序员阐述了一个强内存模型，我们只要理解happens-before规则，就可以编写并发安全的程序了。
​ 另一部分是针对JVM实现的，为了尽可能少的对编译器和处理器做约束从而提高性能，JMM在不影响程序执行结果的前提下对其不做要求，即**允许优化重排序 **。我们只需要关注前者就好了，也就是理解happens-before规则即可，其它繁杂的内容有JMM规范结合操作系统给我们搞定，我们只写好代码即可。

volatile

被volatile修饰的变量特点

可见性

​ 当写一个volatile变量时，JMM会把该线程对应的本地内存中的共享变量值立即刷新回主内存中。

​ 当读一个volatile变量时，JMM会把该线程对应的本地内存设置为无效，重新回到主内存中读取最新共享变量

​ 所以volatile的写内存语义是直接刷新到主内存中，读的内存语义是直接从主内存中读取。

有序性

​ 禁止指令重排

为什么volatile可以保证可见性和有序性--------------》内存屏障（）memory barrier

内存屏障

定义

​ 内存屏障（也称内存栅栏，屏障指令等，是一类同步屏障指令，是CPU或编译器在对内存随机访问的操作中的一个同步点，使得此点之前的所有读写操作都执行后才可以开始执行此点之后的操作)，避免代码重排序。内存屏障其实就是一种JVM指令，Java内存模型的重排规则会要求Java编译器在生成JVM指令时插入特定的内存屏障指令，通过这些内存屏障指令，volatle实现了Java内存模型中的可见性和有序性(禁重排)，但volatile无法保证原子性。
​ 内存屏障之前的所有写操作都要回写到主内存，
​ 内存屏障之后的所有读操作都能获得内存屏障之前的所有写操作的最新结果(实现了可见性)。
​ 写屏障〈Store Memory Barrier):告诉处理器在写屏障之前将所有存储在缓存(store bufferes)中的数据同步到主内存。也就是说当看到Store屏障指令，就必须把该指令之前所有写入指令执行完毕才能继续往下执行。
​ 读屏障(Load Memory Barrier):处理器在读屏障之后的读操作，都在读屏障之后执行。也就是说在Load屏障指令之后就能够保证后面的读取数据指令一定能够读取到最新的数据。

​ 因此重排序时，不允许把内存屏障之后的指令重排序到内存屏障之前。

​ 一句话:对一个volatle变量的写,先行发生于任意后续对这个volatile变量的读，也叫写后读。

#### 分类

​ happens-before 先行发生原则的落地实现

​ 粗分：

1. 读屏障。在读指令之前插入读屏障，让工作内存或CPU高速缓存当中的缓存数据失效，重新回到主内存中获取最新数据
2. 写屏障。在写指令之后插入写屏障，强制把写缓冲区的数据刷回到主内存中

​ 细分：

loadload	load1 ；loadload； load2	保证load1 的读取操作在load2及后续操作之前执行
storestore	store1；storestore；store2	在store2及其后的写操作执行前，保证store1的写操作已刷新到主内存
loadstore	Load1; LoadStore; Store2	在stroe2及其后的写操作执行前，保证load1的读操作已读取结束
storeload	Store1; StoreLoad; Load2	保证store1的写操作已刷新到主内存之后，load2及其后的读操作才能执行

volatile特性

有序性

重排序

​ 重排序是指编译器和处理器为了优化程序性能而对指令序列进行重新排序的一种手段，有时候会改变程序语句的先后顺序

​ 不存在数据依赖关系，可以重排序;

​ 存在数据依赖关系，禁止重排序

但重排后的指令绝对不能改变原有的串行语义!这点在并发设计中必须要重点考虑!
重排序的分类和执行流程
1:编译器 优化重排序-》 2:指令级 并行重排序 -》3:内存系统重排序 -》最终执行的指令序列

编译器优化的重排序:编译器在不改变单线程串行语义的前提下，可以重新调整指令的执行顺序
指令级并行的重排序:处理器使用指令级并行技术来讲多条指令重叠执行，若不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序

内存系统的重排序:由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是乱序执行
数据依赖性:若两个操作访问同一变量，且这两个操作中有一个为写操作，此时两操作间就存在数据依赖性。

有序性

1. 重排序有可能影响程序的执行和实现，因此我们有时候希望告诉JVM你别重排序，我这里不需要排序。

2. 对于编译器的重排序，JMM会根据重排序的规则，禁止特定类型的编译器重排序。

3. 对于处理器的重排序，Java编译器在生成指令序列的适当位置，插入内存屏障指令，来禁止特定类型的处理器排序。

happens-before之volatile变量原则

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

当第一个操作为volatle读时，不论第二个操作是什么，都不能重排序。这个操作保证了volatile读之后的操作不会被重排到volatile读之前。

当第二个操作为volatile写时，不论第一个操作是什么，都不能重排序。这个操作保证了volatile写之前的操作不会被重排到volatile写之后。

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

volatile读插入内存屏障后生成的指令序列示意图：

在每个volatile读操作的后面插入一个LoadLoad屏障禁止处理器把上面的volatile读与下面的普通读重排序
在每个volatile 读操作的后面插入一个LoadStore屏障禁止处理器把上面的volatile读与下面的普通写重排序

volatile读插入内存屏障后生成的指令序列示意图：

在每个volatile 写操作的前面插入一个 StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作都已经刷新到主内存中。
在每个volatile 写操作的后面插入一个 StoreLoad屏障作用是避免volatile写与后面可能有的volatile读/写操作重排序

可见性

​ 保证不同线程对某个变量完成操作后结果及时可见，即该共享变量一旦改变所有线程立即可见

结果：当main 线程将flag修改为false后 t1线程并没有停止运行

说明：flag 变量存储在主内存中，每个线程都有该变量的副本，没有volatile修饰

1. main修改flag后，还没将本地存储刷新到主内存中
2. main修改flag后，已经将本地存储刷新到主内存中，但是t1线程并没有从主内存中读取最新的数据

解决：使用volatile修饰

volatile变量读写过程

read:作用于主内存，将变量的值从主内存传输到工作内存，主内存到工作内存
load:作用于工作内存，将read从主内存传输的变量值放入工作内存变量副本中，即数据加载
use:作用于工作内存，将工作内存变量副本的值传递给执行引擎，每当JVM遇到需要该变量的字节码指令时会执行该操作
assign:作用于工作内存，将从执行引擎接收到的值赋值给工作内存变量，每当JVM遇到一个给变量赋值字节码指令时会执行该操作store:作用于工作内存，将赋值完毕的工作变量的值写回给主内存
write:作用于主内存，将store传输过来的变量值赋值给主内存中的变量
由于上述6条只能保证单条指令的原子性，针对多条指令的组合性原子保证，没有大面积加锁，所以，JVM提供了另外两个原子指令​

lock:作用于主内存，将一个变量标记为一个线程独占的状态，只是写时候加锁，就只是锁了写变量的过程。
unlock:作用于主内存，把一个处于锁定状态的变量释放，然后才能被其他线程占用

没有原子性

​ volatile变量的复合操作不具有原子性，比如number++

​ 读取赋值一个普通变量情况：

​ 当线程1对主内存对象发起read操作到write操作第一套流程的时间里，线程2随时都有可能对这个主内存对象发起第二套操作

volatile变量读写情况：

对于volatle变量具备可见性，JVM只是保证从主内存加载到线程工作内存的值是最新的，也仅是数据加载时是最新的。但是多线程环境下，"数据计算"和"数据赋值"操作可能多次出现，若数据在加载之后，若主内存volatle修饰变量发生修改之后，线程工作内存中的操作将会作废去读主内存最新值，操作出现写丢失问题。即各线程私有内存和主内存公共内存中变量不同步，进而导致数据不一致。由此可见volatle解决的是变量读时的可见性问题，但无法保证原子性，对于多线程修改主内存共享变量的场景必须使用加锁同步。

​

普通变量加锁后，从线程读取到写入的整个流程都是一个线程在操作，所以保证了原子性

volatile修饰的变量，同时进行读写操作，但是数据加载，数据计算，数据赋值是非原子性操作，当有一个线程先完成操作后，将新值写到主内存中。另一个线程会重新去读取新值，但是本次操作已经在进行中了，由于值的更新，会导致本次操作是无效的，这就相当于少了一次操作。所以volatile变量不能保证原子性

volatile变量不适合参与到依赖当前值的运算

1. volatile变量不适合参与到依赖当前值的运算，如i=i+ 1; i+t;之类的
   那么依靠可见性的特点volatie可以用在哪些地方呢﹖通常volatile用做保存某个状态的boolean值or int值。

2. 《深入理解Java虚拟机》提到:由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁(使用synchronized、java.util.concurrent中的锁或原子类）来保证原子性:

   • 运算结果并不依赖变量的当前值，或者能够确保只有单一的线程修改变量的值.

   • 变量不需要与其他的状态变量共同参与不变约束。

正确使用volatile

1. 单一赋值可以，but含复合运算赋值不可以(i++之类)

volatile int a = 10
volatile boolean flag = false

2. 状态标志，判断业务是否结束

3. 开销较低的读，写锁策略

4. DCL双端锁的发布(单例模式double check)

   

隐患:多线程环境下，在""问题代码处"，会执行如下操作，由于重排序导致2,3乱序，后果就是其他线程得到的是null而i不是完成初始化的对象

解决