序言
在并发编程中，当好几个进程与此同时浏览同一个共享资源的可变性自变量时，会造成不确定性的結果，因此 要撰写线程安全的编码，其实质上是对这种可变性的共享资源自变量的浏览实际操作开展管理方法。造成这类不确定性結果的缘故便是由此可见性、有序化和原子性难题，Java 为处理由此可见性和有序化难题引进了 Java 运行内存实体模型，应用相互独立计划方案（其关键完成技术性是锁）来处理原子性难题。这篇先一起来看看处理由此可见性、有序化难题的 Java 运行内存实体模型（JMM）。
什么叫 Java 运行内存实体模型
Java 运行内存实体模型在wiki百科上的界定以下：
The Java memory model describes how threads in the Java programming language interact through memory. Together with the description of single-threaded execution of code, the memory model provides the semantics of the Java programming language.
运行内存实体模型限定的是共享资源自变量，也就是储存在堆内存中的自变量，在 Java 语言表达中，全部的实例变量、静态变量和二维数组原素都储存在堆内存当中。而方式主要参数、错误处理主要参数这种静态变量储存在方式栈帧当中，因而不容易在进程中间共享资源，不容易遭受运行内存实体模型危害，也不会有运行内存由此可见性的问题。
一般，在进程中间的通讯方式有共享内存和消息传递二种，很显著，Java 选用的是第一种即共享资源的运行内存实体模型，在共享资源的运行内存实体模型里，线程同步中间共享资源程序流程的公共性情况，根据读-写运行内存的方法来开展隐式通信。
从抽象性的视角看来，JMM 实际上是界定了进程和主运行内存中间的关联，最先，好几个进程中间的共享资源自变量储存在主运行内存当中，与此同时每一个进程都是有一个自身独享的当地运行内存，当地运行内存中储存着该进程读或写共享资源自变量的团本（留意：当地运行内存是 JMM 界定的抽象化，事实上并不会有）。抽象性实体模型如下图所显示：
在这个抽象性的运行内存实体模型中，在2个进程中间的通讯（共享资源自变量情况变动）时，会开展以下2个流程：
- 进程 A 把在当地运行内存升级后的共享资源自变量团本的值，更新到主运行内存中。
- 进程 B 在应用到该共享资源自变量时，到主运行内存中去载入进程 A 升级后的共享资源自变量的值，并升级进程 B 当地运行内存的值。
JMM 实质上是在硬件配置（CPU）运行内存实体模型以上又干了一层抽象性，促使运用开发者只必须掌握 JMM 就可以编写出恰当的高并发编码，而不用太多掌握硬件配置方面的运行内存实体模型。
为何必须 Java 运行内存实体模型
在日常的软件开发中，为一些共享资源自变量取值的情景会常常遇到，假定一个进程为整形共享资源自变量 count 做取值实际操作（count = 9527;），这时便会有一个难题，其他载入该共享资源自变量的进程在什么情况获得到的变量类型为 9527 呢？假如缺乏同歩得话，会出现许多 要素造成其他载入该自变量的进程没法马上乃至是始终都没法见到该自变量的全新值。
例如缓存文件就很有可能会更改载入共享资源自变量团本递交到主运行内存的顺序，储存在当地缓存文件的值，针对其他进程不是由此可见的；c语言编译器为了更好地提升特性，有时会获取窗口句柄中句子实行的顺序，这种要素都是有很有可能会造成其他进程没法见到共享资源自变量的全新值。
在文章开头，提及了 JMM 主要是为了更好地处理由此可见性和有序化难题，那麼最先就需要先弄清楚，造成由此可见性和有序化难题产生的实质原因是什么？如今的服务项目绝大多数全是运作在多核 CPU 的网络服务器上，每粒 CPU 都是有自身的缓存文件，这时候 CPU 缓存文件与运行内存的数据信息便会有一致性难题了，当一个进程对共享资源自变量的改动，此外一个进程没法马上见到。造成由此可见性的问题的实质缘故是缓存文件。
有序化就是指编码具体的实行次序和编码界定的次序一致，c语言编译器为了更好地提升特性，尽管会遵循 as-if-serial 词义（无论怎样重排列，在单核下的实行結果不可以更改），但是有时c语言编译器及编译器的提升也很有可能引起一些难题。例如：双向查验来建立单案例目标。下边是应用双向查验来完成延迟时间建立单例模式目标的编码：
/**
* @author mghio
* @since 2021-08-22
*/
public class DoubleCheckedInstance {
private static DoubleCheckedInstance instance;
public static DoubleCheckedInstance getInstance() {
if (instance == null) {
synchronized (DoubleCheckedInstance.class) {
if (instance == null) {
instance = new DoubleCheckedInstance();
}
}
}
return instance;
}
}
这儿的 instance = new DoubleCheckedInstance();，看上去 Java 编码仅有一行，应该是没法就可以了重排列的，事实上其编译程序后的具体命令是以下三步：
- 分配对象的存储空间
- 复位目标
- 设定 instance 偏向刚早已分派的基址
上边的第 2 步和第 3 步假如更改实行次序也始终不变单核的实行結果，换句话说很有可能会产生重排列，下面的图是一种线程同步高并发实行的情景：
这时进程 B 获得到的 instance 是沒有复位过的，假如此来浏览 instance 的成员函数就很有可能开启空指针异常。造成有序化难题的实质缘故是c语言编译器提升。那么你很有可能会想即然缓存文件和c语言编译器提升是造成由此可见性的问题和有序化难题的缘故，那立即禁止使用掉不就能够 彻底消除这种难题了没有，可是假如那么干了得话，程序流程的特性很有可能便会遭受较为大的危害了。
实际上能够 换一种构思，能否把这种禁止使用缓存文件和c语言编译器提升的支配权交到编号的技术工程师来解决，她们毫无疑问最清晰何时必须禁止使用，那样就只必须给予按需禁止使用缓存文件和编译程序提升的方式就可以，应用较为灵便。因而Java 运行内存实体模型就问世了，它标准了 JVM 怎样给予按需禁止使用缓存文件和编译程序提升的方式，要求了 JVM 务必遵循一组最少的确保，这一最少确保要求了进程对共享资源自变量的载入实际操作什么时候对其他进程由此可见。
次序一致性运行内存实体模型
次序一致性实体模型是一个理想后的基础理论参考模型，CPU和计算机语言的运行内存实体模型的设计方案全是参照的次序一致性实体模型基础理论。其有以下两大特点：
- 一个进程中的全部实际操作务必依照程序流程的次序来实行
- 全部的进程都只有见到一个单一的实行实际操作次序，无论程序流程是不是同歩
在技术工程师角度下的次序一致性实体模型以下：
次序一致性实体模型有一个单一的全局性运行内存，这一全局性运行内存能够 根据摇摆不定的电源开关能够 联接到随意一个进程，每一个进程都务必依照程序流程的次序来实行运行内存的读和写实际操作。该理想化实体模型下，每日任务時刻都只有有一个进程能够 联接到运行内存，当好几个进程高并发实行时，就可以根据电源开关就可以把好几个进程的读和写实际操作串行化。
次序一致性实体模型中，全部操实际操作彻底依照次序串行通信实行，可是在 JMM 中就沒有这一确保了，未同歩的程序流程在 JMM 中不但程序流程的实行次序是混乱的，并且因为当地运行内存的存有，全部进程见到的实际操作次序也很有可能会不一致，例如一个进程把写共享资源自变量储存在当地运行内存中，在都还没更新到主运行内存前，其他进程不是由此可见的，仅有升级到主运行内存后，其他进程才有可能见到。
JMM 对在恰当同歩的程序流程干了次序一致性的确保，也就是程序流程的实行結果和该程序流程在次序一致性运行内存实体模型中的实行結果同样。
Happens-Before 标准
Happens-Before 标准是 JMM 中的关键定义，Happens-Before 定义最初在 这篇毕业论文 明确提出，其在毕业论文中应用 Happens-Before 来界定分布式架构中间的偏序关系。在 JSR-133 中应用 Happens-Before 来特定2个实际操作中间的实行次序。
JMM 恰好是根据这一标准来确保跨进程的运行内存由此可见性，Happens-Before 的含意是前边一个对共享资源自变量的实际操作結果对该自变量的事后实际操作是由此可见的，管束了c语言编译器的提升个人行为，尽管容许c语言编译器提升，可是提升后的编码务必要达到 Happens-Before 标准，这一标准给技术工程师干了这一确保：同歩的线程同步程序流程是依照 Happens-Before 特定的次序来实行的。目地便是为了更好地在没有获取窗口句柄（单核或是恰当同歩的线程同步程序流程）实行結果的前提条件下，尽较大很有可能的提升 程序运行的高效率。
JSR-133 标准中定了以下 6 项 Happens-Before 标准：
- 程序流程次序标准：一个进程中的每一个实际操作，Happens-Before 该进程中的随意事后实际操作
- 监控器锁标准：对一个锁的开启实际操作，Happens-Before 于后边对这一锁的上锁实际操作
- volatile 标准对一个 volatile 种类的自变量的写实际操作，Happens-Before 与随意后边对这一 volatile 自变量的读实际操作
- 传递性标准：假如实际操作 A Happens-Before 于实际操作 B，而且实际操作 B Happens-Before 于实际操作 C，则实际操作 A Happens-Before 于实际操作 C
- start() 标准：假如一个进程 A 实行实际操作 threadB.start() 运行进程 B，那麼进程 A 的 start() 实际操作 Happens-Before 于进程 B 的随意实际操作
- join() 标准：假如进程 A 实行实际操作 threadB.join() 并取得成功回到，那麼进程 B 中的随意实际操作 Happens-Before 于进程 A 从 threadB.join() 提交成功回到
JMM 的一个基本准则是：只需不更改单核和恰当同歩的线程同步的实行結果，c语言编译器和CPU随意怎么优化都能够，事实上针对运用开发者针对2个实际操作是不是确实被重排列并不关注，真真正正关注的是实行結果不可以被改动。因而 Happens-Before 实质上和 sa-if-serial 的词义是一致的，仅仅 sa-if-serial 仅仅确保在单核下的实行結果不被更改。
汇总
文中关键详细介绍了运行内存实体模型的有关基本知识和有关定义，JMM 屏蔽掉不一样CPU运行内存实体模型中间的差别，在不一样的CPU服务平台上给运用开发者抽象性出了统一的 Java 运行内存实体模型（JMM）。普遍的CPU运行内存实体模型比 JMM 的要弱，因而 JVM 会在转化成字节码命令时在适度的部位插进内存屏障（内存屏障的种类会因为CPU服务平台而各有不同）来限定一部分重排列。
