Java内存模型(Java Memory Molde，JMM)

文章目录

1、Java内存模型(Java Memory Molde，JMM)
2、多线程先行发生原则之happens-before

1、Java内存模型(Java Memory Molde，JMM)

在讲解Java内存模型之前，先看一下物理机的模型：

主内存和工作内存

Java内存模型的主要目的是定义程序中各种变量的访问规则，即关注在虚拟机中把变量值存储到内存和从内存中取出变量值这样的底层细节。此处的变量（Variables）与Java编程中所说的变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素。但是不包括局部变量与方法参数（因为是线程私有的，不会被共享）。

Java内存模型规定了所有的变量都存储在主内存（Main Memory）。
每条线程都有自己的==工作内存（Working Memory），线程的工作内存中保存了被该线程使用的变量的主内存副本==，线程对变量的所有操作（读取、赋值等）都必须在工作内存中进行，而不能直接读写主内存中的数据。不同的线程中间也无法直接访问对方工作内存中的变量。线程间变量值的传递均需要通过主内存来完成。

内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存这一类的实现细节。Java虚拟机实现时必须保证下面提及的每一种操作都是原子的、不可再分的：

Lock（锁定）：作用于主内存的变量，它把一个变量标识为一条线程独占的状态。
unLock（解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程所定。
Read（读取）：作用于主内存的变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的 load动作使用。
Load（载入）：作用于工作内存的变量，它把 read操作从主内存中得到的变量值放入工作内存的变量副本中。
Use（使用）：作用于工作内存的变量，它把工作内存中一个变量的值传递给执行引擎，每当虚拟机遇到一个需要使用变量的值的字节码指令时将会执行这个操作。
Assign（赋值）：作用于工作内存的变量，它把一个从执行引擎接收的值符给工作内存的变量，每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作。
Store（存储）：作用于工作内存的变量，它把工作内存中一个变量的值传送到主内存中，以便随后的write操作使用。
Write（写入）：作用于主内存的变量，它把 store 操作从工作内存中得到的变量的值放入主内存的变量中。

注意：

如果对一个变量执行lock操作，将会清空工作内存中此变量的值；
对一个变量执行 unlock 操作之前，必须先把此变量同步到主内存中。

小总结

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

原子性：每一种操作都是原子的、不可再分的
可见性：是指当一个线程修改了某一个共享变量的值，其他线程是否能够立即知道该变更，JMM规定了所有的变量都存储在主内存中。
有序性：支持指令重排。

这里对有序性进行详细讲解～

是什么？

对于一个线程的执行代码而言，我们总是习惯认为代码的执行总是从上到下，有序执行。但为了提升性能，编译器和处理器通常会对指令序列进行重新排序。Java规范规定JVM线程内部维持顺序化语义，即只要程序的最终结果与它顺序化执行的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。
优缺点

JVM能根据处理器特性（CPU多级缓存系统、多核处理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的发挥机器性能。但是，

指令重排可以保证串行语义一致，但没有义务保证多线程间的语义也一致（即可能产生"脏读"），简单说，两行以上不相干的代码在执行的时候有可能先执行的不是第一条，不见得是从上到下顺序执行，执行顺序会被优化。

从源码到最终执行示例图：

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

处理器在进行重排序时必须要考虑指令之间的数据依赖性。

多线程环境中线程交替执行，由于编译器优化重排的存在，两个线程中使用的变量能否保证一致性是无法确定的，结果无法预测。

2、多线程先行发生原则之happens-before

多线程先行发生原则之happens-before

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

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

这个原则非常重要：

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

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

接下来来个 x、y案例说明一下吧～

x=5;    // 线程A执行
y=x;   // 线程B执行

问题：y是否等于5呢？

如果线程A得操作（x=5）happens-before(先行发生)线程B的操作(y=x)，那么可以确定线程B执行后y=5一定成立；

如果他们不存在 happens-before原则，那么y=5不一定成立。

这就是happens-before原则的威力——>包含可见性和有序性的约束

说了那么多，happens-before原则简而言之就是：

如果一个操作先行发生于另一个操作，那么第一个操作的执行结果将对第二个操作可见，而且第一个操作的执行结果顺序排在第二个操作之前。

两个操作之间存在happens-before关系，并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致，那么这种排序并不非法。好比：1+2+3=3+2+1。

happens-before细说有以下八条原则：

次序规则：一个线程内，按照代码的顺序，写在前面的操作先行发生于写在后面的操作
锁定规则：一个unLock操作先行发生于后面（“后面”是指时间上的先后）对同一个锁的lock操作
volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，前面的写对后面的读是可见的（“后面”是指时间上的先后）
传递规则：如果操作A先行发生于操作B，而操作B又先行发生于操作C，则可以得出操作A先行发生于操作C
线程启动规则（Thread Start Rule)：Thread对象的start()方法先行发生于此线程的每一个动作
线程中断规则（Thread Interruption Rule）：对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断时间的发生，即先调用interrupt()方法设置过中断标志位，才能通过Thread.interrupted()检测到是否发生中断。
线程终止规则（Thread Termination Rule）：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过isAlive()等手段检测线程是否已经终止执行。
对象终结规则（Finalizer Rule）：一个对象的初始化完成（构造函数执行结束）先行发生于它的finalize()方法的开始。