一、JMM简介

Java虚拟机支持多线程执行。在Java中Thread类代表线程，创建一个线程的唯一方法就是创建一个Thread类的实例对象。当调用了对象的start方法后，相应的线程将会执行。
线程的行为有时会令人困惑而且和我们的直觉相左，特别是在线程没有正确同步的情况下。本规范描述了JVM平台上多线程程序的语义（含义），具体包括一个线程对共享变量的写入何时能被其他线程“看到”。由于本规范和不同硬件平台上的内存模型相似，所以将本规范命名为Java内存模型。

JMM是一个和多线程相关的规范；
JMM描述了JVM平台上多线程程序的语义（含义），具体包括一个线程对共享变量的写入何时能被其他线程“看到”。

二、内存模型

有点计算机基础的同学都应该知道，程序执行的时候其实就是一条条指令在CPU上执行的过程，而指令的执行又势必会涉及到数据的读取和写入。说到数据，就又不得不提到一个重要的硬件:内存。在计算机中，内存是数据的“收集站”，数据从键盘、网络、文件也有可能是一些传感器设备进入到内存，然后CPU从内存中读取这些数据并对这些数据进行“加工”后再写回到内存。
上面整个过程看起来很完美，但是就像人与人之间是有差别的一样，硬件和硬件之间也存在差别。CPU的运行速度就和尤塞恩·博尔特的速度一样（飞一样的速度），而内存的运行速度和CPU相比就像我的跑步速度和博尔特比一样，根本不是一个数量级的。CPU和内存运行速度的差距会导致整个系统性能的下降，因为CPU每次读写数据都要等待内存。（木桶理论在计算机中的体现）
但是这个问题根本就难不倒我们伟大的硬件工程师们。“聪明”的工程师们在CPU中加入了一层CPU高速缓存层。这个缓存的运算速度和CPU相当，当指令在CPU上运行的时候，会先将运算需要的数据从内存中复制一份到CPU的高速缓存当中，那么CPU进行计算时就可以直接从它的高速缓存读取数据和向其中写入数据，当运算结束之后，再将高速缓存中的数据刷新到主存当中。（现代CPU其实是有多级缓存的，但是为了简单起见就没介绍了，因为我觉得这里不介绍CPU多级缓存不会影响对JMM的理解）

2.1、原子性问题

上面提到CPU进行运算时需要将共享变量先加载到CPU缓存中，运算结束后再将最新数据写回共享内存。这种看起来完美的工作方式其实存在一个问题，下面我们就以上面的图片为列子，说下这个问题。
假如现在系统环境是单核CPU+多线程工作模式，共享变量初始值是1，线程1和线程2分别对这个共享变量进行加一操作，理论上这个共享变量最后的值是3。我们看看程序的执行行为是否会和我们预期的一致。
线程对一个共享变量加一的过程需要分三步进行：

step1: read共享变量到工作内存
step2：对共享变量+1
step3：将共享变量写回主内存

但是上面的三个步骤并不是原子操作，也就是说可能会被打断。现在假如线程1已经执行完了step1，但是这时CPU时间片用完了，线程2获得执行机会也从内存中加载共享变量的值（此时共享变量的值还是1），最后两个线程执行完step2和step3之后共享变量的值是2，并不是3。
出现上面问题的原因就是对共享变量的加一操作并不是原子性操作，所谓原子性操作是指一个或多个操作，要么全部执行且在执行过程中不被任何因素打断，要么全部不执行。在多线程环境下原子性问题可能会造成错误的执行结果。
原子性问题是内存模型存在的第一个问题，但是内存模型存在的问题不止这一个。

2.2、缓存一致性问题

随着科技的进步，对CPU的需求越来越高。但是摩尔定律的失效注定单个CPU的性能已经很难再大幅度提升。此时“聪明”的硬件工程师又出场了，他们创造性地将多个CPU集成到一个上，这样CPU的性能不就能成倍地增长了么。多核CPU的确带来了CPU性能的提升，但是这却“害苦”了软件工程师，因为多核CPU大大提升了多线程编程的难度。
多核CPU进行多线程编程时存在的一个显著问题就是缓存一致性问题。

2.3、指令重排序问题

所谓的指令重拍是指CPU为了是内部的处理器单元得到充分的应用，可能会对代码进行乱序执行的行为。这个指令重拍的行为在单线程环境下不会有任何问题，但是在多线程环境下程序就可能出现错误的执行结果。
这边不准备对指令重排进行深入的讨论，大家只要知道指令重排序是一种CPU性能优化的行为，而这个行为在多线程环境下可能会导致程序错误的执行结果。下边举一个简单的列子说明这个问题：

class Singleton{
    private static Singleton instance = null;
    private Singleton() {
    }
    public static Singleton getInstance() {
        if(instance==null) { // 1
            synchronized (Singleton.class) {
                if(instance==null)
                    instance = new Singleton();  //2
            }
        }
        return instance;
    }
}

上面的代码是一段实现单列模式的代码。代码中的Instance变量没有用volatile关键字修饰的，会导致这样一个问题：在线程执行到第1行的时候，代码读取到instance不为null时，但是instance引用的对象有可能还没有完成初始化。
造成这种现象主要的原因是重排序。
2处的代码可以分解成以下几步

emory = allocate();　　    // 1：分配对象的内存空间
ctorInstance(memory);　 // 2：初始化对象
instance = memory;　　  // 3：设置instance指向刚分配的内存地址

上面的第2和第3步之间，可能会被重排序。例如：

memory = allocate();　　// 1：分配对象的内存空间
instance = memory;　　// 3：设置instance指向刚分配的内存地址
                                          // 注意，此时对象还没有被初始化！
ctorInstance(memory);　// 2：初始化对象

此时程序判断到instance变量是非空的，但是还没初始化完成。如果立即使用的话会出现“致命”的问题。
通过上面分析我们看到：随着CPU性能的不断提升，随之出现了原子性问题、缓存一致性问题和指令重排序问题。细心的我们会发现这些问题其实是和多线程环境下共享变量访问的原子性、可见性和有序性问题一一对应的。

2.4、内存模型的作用

为了既保证CPU的高效执行，又保证共享内存读写的正确性（原子性、可见性和有序性），人们定义了内存模型。内存模型是一个规范，这个规范能保证共享内存读写的正确性。

三、Java内存模型

上面提到内存模型的出现是为了解决共享变量读写的原子性、可见性和有序性问题，但是没有具体讲怎么解决的。下面就来看看在Java中的内存模型JMM。
Java内存模型是内存模型在JVM中的体现。这个模型的主要目标是定义程序中各个共享变量的访问规则，也就是在虚拟机中将变量存储到内存以及从内存中取出变量这类的底层细节。通过这些规则来规范对内存的读写操作，保证了并发场景下的可见性、原子性和有序性。
Java内存模型规定了所有的变量（此处的变量（Variables）与Java编程中所说的变量有所区别，它包括了实例字段、静态字段和构成数组对象的元素，但是不包括局部变量与方法参数）都存储在主内存中（此处的主内存与介绍物理硬件时提到的主内存名字一样，两者也可以类比，但物理上它仅是虚拟机内存的一部分），每条线程还有自己的工作内存（可与前面讲的处理器高速缓存类比），线程的工作内存中保存了该线程中是用到的变量的主内存副本拷贝，线程对变量的所有操作都必须在工作内存中进行，而不能直接读写主内存。不同的线程之间也无法直接访问对方工作内存中的变量，线程间变量的传递均需要自己的工作内存和主存之间进行数据同步进行。
而JMM就作用于工作内存和主存之间数据同步过程。他规定了如何做数据同步以及什么时候做数据同步。也就是说Java线程之间的通信由Java内存模型控制， JMM决定一个线程对共享变量的写入何时对另一个线程可见。

四、内存间交互操作

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

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

如果要把一个变量从主内存拷贝到工作内存，那就要按顺序执行read和load操作，如果要把变量从工作内存同步回主内存，就要按顺序执行store和write操作。注意，Java内存模型只要求上述两个操作必须按顺序执行，但不要求是连续执行。也就是说read与load之间、store与write之间是可插入其他指令的，如对主内存中的变量a、b进行访问时，一种可能出现的顺序是read a、read b、load b、load a。除此之外，Java内存模型还规定了在执行上述8种基本操作时必须满足如下规则：

不允许read和load、store和write操作之一单独出现，即不允许一个变量从主内存读取了但工作内存不接受，或者工作内存发起回写了但主内存不接受的情况出现。
不允许一个线程丢弃它最近的assign操作，即变量在工作内存中改变了之后必须把该变化同步回主内存。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存同步回主内存中。
一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或assign）的变量，换句话说就是对一个变量实施use、store操作之前，必须先执行assign和load操作。
一个变量在同一个时刻只允许一条线程对其进行lock操作，但lock操作可以被同一条线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。
如果对一个变量执行lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assign操作以初始化变量的值。
如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把此变量同步回主内存中（执行store、write操作）。

大家发现，上面的定义相当繁琐，实践起来也很复杂。后来Java设计团队大概也意识到了这个问题，将Java内存模型的操作简化为read、write、lock和unlock四种，但这只是语言描述上的等价化简，Java内存模型的基础设计并未改变。

五、总结

Java的多线程之间是通过共享内存进行通信的，而由于采用共享内存进行通信，在通信过程中会存在一系列如原子性、可见性和有序性的问题。JMM就是为了解决这些问题而出现的，这个模型建立了一些规范，来屏蔽各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能达到一致的内存访问效果,以保证在多核CPU多线程编程环境下，对共享变量读写的原子性、可见性和有序性。

编程相关

01、JMM模型