Java内存模型与JVM内存区域是不同的概念层次，JMM描述的是一组规则，通过这组规则控制程序中各个变量在共享数据区域和私有数据区域的访问方式，JMM是围绕原子性，有序性、可见性展开。JMM与JVM内存区域唯一相似点，都存在共享数据区域和私有数据区域，在JMM中主内存属于共享数据区域，从某种程度上讲应该包括但不限于堆和方法区，而工作内存属于线程私有数据区域，从某个程度上讲则应该包括但不限于程序计数器、虚拟机栈以及本地方法栈。

什么是java内存模型？

Java内存模型(Java Memory Model简称JMM)是一种抽象的概念，并不真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量（包括对象实例，静态字段 和构成数组对象的元素）的访问方式。JSR文档解释如下：

给定一个程序和该程序的一串执行轨迹，内存模型描述了该执行轨迹是否是该程序的一次合法执行。对于Java，内存模型检查执行轨迹中的每次读操作，然后根据特定规则，检验该读操作观察到的写是否合法。内存模型描述了某个程序的可能行为。JVM 实现可以自由地生成想要的代码，只要该程序所有最终执行产生的结果能通过内存模型进行预测。这为大量的代码转换提供了充分的自由，包括动作（action）的重排序以及非必要的同步移除。内存模型的一个高级、非正式的概述显示其是一组规则，规定了一个线程的写操作何时会对另一个线程可见。通俗地说，读操作 r通常能看到任何写操作 w写入的值，意味着 w 不是在 r 之后发生，且w看起来没有被另一个写操作 w’覆盖掉（从 r的角度看）。

Java内存模型中规定所有变量都存储在主内存，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作(读取赋值等)必须在工作内存中进行，首先要将变量从主内存拷贝到自己的工作内存空间，然后对变量进行操作，操作完成后再将变量写回主内存，不能直接操作主内存中的变量，工作内存中存储着主内存中的变量副本拷贝。工作内存是每个线程的私有数据区域，因此不同的线程间无法访问对方的工作内存，线程间的通信(传值)必须通过主内存来完成。
微信截图_20210627224239.png

Java内存模型与硬件内存架构的关系

通过对Java内存模型以及Java多线程的实现原理的了解，我们应该已经意识到，多线程的执行最终都会映射到硬件处理器上进行执行，但Java内存模型和硬件内存架构并不完全一致。对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没有工作内存(线程私有数据区域)和主内存(共享内存)之分，也就是说Java内存模型内存的划分对硬件内存并没有任何影响，因为JMM只是一种抽象的概念，是一组规则，并不实际存在，不管是工作内存的数据还是主内存的数据，对于计算机硬件来说都会存储在计算机主内存中，当然也有可能存储到CPU缓存或者寄存器中，因此总体上来说，Java内存模型和计算机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉。(注意对于JVM内存区域划分也是同样的道理)
微信截图_20210627232706.png

数据八大原子操作

关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存中拷贝到工作内存、如何从工作内存同步到主内存之间的实现细节，Java内存模型定义了一下八种原子操作来完成：

lock(锁定)：作用于主内存的变量，把一个变量标记为一条线程独占状态
unlock(解锁)：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
read(读取)：作用于主内存的变量，把一个变量值从主内存传输到线程的工作内存中，以便随后的load动作使用
load(载入)：作用于工作内存的变量，它把read操作从主内存中得到的变量值放入工作内存的变量副本中
use(使用)：作用于工作内存的变量，把工作内存中的一个变量值传递给执行引擎
assign(赋值)：作用于工作内存的变量，它把一个从执行引擎接收到的值赋给工作内存的变量
store(存储)：作用于工作内存的变量，把工作内存中的一个变量的值传送到主内存中，以便随后的write的操作
write(写入)：作用于工作内存的变量，它把store操作从工作内存中的一个变量的值传送到主内存的变量中

原子操作规则

不允许一个线程无原因地（没有发生过任何assign操作）把数据从工作内存同步回主内存中。
一个新的变量只能在主内存中诞生，对一个变量实施use和store操作之前，必须先自行 load和assign操作。
一个变量在同一时刻只允许一条线程对其进行lock操作，但lock操作可以被同一线程重复执行多次，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁。lock 和unlock必须成对出现。
如果对一个变量执行lock操作，将会清空工作内存中此变量的值，在执行引擎使用这个变量之前需要重新执行load或assign操作初始化变量的值。
如果一个变量事先没有被lock操作锁定，则不允许对它执行unlock操作，也不允许去 unlock一个被其他线程锁定的变量。
对一个变量执行unlock操作之前，必须先把变量同步到主内存中（执行store和write 操作）

当执行如下代码：

public class test {
    private static boolean initFlag = false;
    private static int counter = 0;
    public static void refresh(){
        initFlag = true;
    }
    public static void main(String[] args){
        Thread threadA = new Thread(()->{
            while (!initFlag){
                //System.out.println("runing");
                counter++;
            }
            log.info("线程：" + Thread.currentThread().getName()
                    + "探测到initFlag状态改变");
        },"threadA");
        threadA.start();
        try {
            Thread.sleep(500);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        Thread threadB = new Thread(()->{
            refresh();
        },"threadB");
        threadB.start();
    }
}

Java内存模型工作流程如图：
微信截图_20210628103133.png
上面代码在ThreadB修改了initFlag的值后，ThreadA还是一直在死循环，这与并发编程的三大特性中的可见性有关。

并发编程三大特性

原子性

原子性指的是一个操作是不可中断的，即使是在多线程环境下，一个操作一旦开始就不会被其他线程影响。

在java中，对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是，对于32位系统的来说，long类型数据和double类型数据(对于基本数据类型，byte,short,int,float,boolean,char读写是原子操作)，它们的读写并非原子性的，也就是说如果存在两条线程同时对long类型或者double类型的数据进行读写是存在相互干扰的，因为对于32位虚拟机来说，每次原子读写是32位的，而long和double则是64位的存储单元，这样会导致一个线程在写时，操作完前32位的原子操作后，轮到B线程读取时，恰好只读取到了后32位的数据，这样可能会读取到一个既非原值又不是线程修改值的变量，它可能是“半个变量”的数值，即64位数据被两个线程分成了两次读取。但也不必太担心，因为读取到“半个变量”的情况比较少见，至少在目前的商用的虚拟机中，几乎都把64位的数据的读写操作作为原子操作来执行。

解决方法：
除了JVM自身提供的对基本数据类型读写操作的原子性外，可以通过synchronized 和 Lock实现原子性。因为synchronized和Lock能够保证任一时刻只有一个线程访问该代码块。

可见性

可见性指的是当一个线程修改了某个共享变量的值，其他线程是否能够马上得知这个修改的值。

对于串行程序来说，可见性是不存在的，因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且是修改过的新值。但在并发多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操作，但此时A线程工作内存中的变量x对线程B来说并不可见，这种工作内存与主内存同步延迟现象就造成了可见性问题。

解决方法：
volatile关键字保证可见性，当一个共享变量被volatile修饰时，它会保证修改的值立即被其他的线程看到，即修改的值立即更新到主存中，当其他线程需要读取时，它会去内存中读取新值。synchronized和Lock也可以保证可见性，因为它们可以保证任一时刻只有一个线程能访问共享资源，并在其释放锁之前将修改的变量刷新到内存中。

有序性

编码人员所编写程序运行的结果与编码人员对推测出的结果要一致，即不能出现有违直觉的结果，满足这一条件则程序满足有序性。

程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单线程内保证串行语义执行的一致性，后半句则指的是指令重排现象和工作内存与主内存同步延迟现象。

解决方法：
在Java里面，可以通过volatile关键字来保证一定的“有序性”（具体原理在下一节讲述volatile关键字）。另外可以通过synchronized和Lock来保证有序性，很显然， synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行同步代码，自然就保证了有序性。

指令重排

java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的重排序。

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

public static void main(String[] args) throws InterruptedException {
    int i = 0;
    for (;;){
        i++;
        x = 0; y = 0;
        a = 0; b = 0;
        Thread t1 = new Thread(new Runnable() {
            public void run() {
                shortWait(10000);
                a = 1;
                x = b;
            }
        });
        Thread t2 = new Thread(new Runnable() {
            public void run() {
                b = 1;
                y = a;
            }
        });
        t1.start();
        t2.start();
        t1.join();
        t2.join();
        String result = "第" + i + "次 (" + x + "," + y + ")" + "出现指令重排";
        if(x == 0 && y == 0) {
            System.out.println(result);
            break;
        } else {
            log.info(result);
        }
    }
}

执行上述代码，若程序出现x = 0，y = 0 的结果，则说明发生了指令重排
微信截图_20210628151746.png

as-if-serial语义

as-if-serial语义的意思是：不管怎么重排序（编译器和处理器为了提高并行度），单线程程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。为了遵守as-if-serial语义，编译器和处理器不会对存在数据依赖关系的操作做重排序，因为这种重排序会改变执行结果。但是，如果操作之间不存在数据依赖关系，这些操作就可能被编译器和处理器重排序。

public static void main(String[] args) {
    /**
     * 以下例子当中1、2步存在指令重排行为，但是1、2不能与第三步指令重排
     * 也就是第3步不可能先于1、2步执行，否则将改变程序的执行结果
     */
    double p = 3.14; //1
    double r = 1.0; //2
    double area = p * r * r; //3计算面积
}

happen-before语义

只靠sychronized和volatile关键字来保证原子性、可见性以及有序性，那么编写并发程序可能会显得十分麻烦，幸运的是，从JDK 5开始，Java使用新的JSR-133内存模型，提供了happens-before 原则来辅助保证程序执行的原子性、可见性以及有序性的问题，它是判断数据是否存在竞争、线程是否安全的依据，我们来看一下JSR文档中对happen-before的描述：

Happens-Before 关系两个动作（action）可以被 happens-before 关系排序。如果一个动作 happens-before 另一个动作，则第一个对第二个可见，且第一个排在第二个之前。必须强调的是，两个动作之间存在 happens-before 关系并不意味着这些动作在 Java 中必须以这种顺序发生。happens-before 关系主要用于强调两个有冲突的动作之间的顺序，以及定义数据争用的发生时机。可以通过多种方式包含一个happens-before 顺序：

某个线程中的每个动作都 happens-before 该线程中该动作后面的动作。
某个管程上的 unlock 动作 happens-before 同一个管程上后续的 lock 动作。
对某个 volatile 字段的写操作 happens-before 每个后续对该 volatile 字段的读操作。
在某个线程对象上调用 start()方法 happens-before 该启动了的线程中的任意动作。
某个线程中的所有动作 happens-before 任意其它线程成功从该线程对象上的join()中返回。
如果某个动作 a happens-before 动作 b，且 b happens-before 动作 c，则有 a happens-before c.

程序顺序原则：即在单线程内必须保证语义串行性，也就是说按照代码顺序执行。（时间上）先执行的操作 happen-before 后执行的操作
锁规则：解锁操作必然发生在后续的同一个锁的加锁(lock)之前，也就是说，一个unlock 操作 happen-before 后面对同一个锁的 lock 操作
volatile规则：volatile变量的写操作 happen-before 后面对该变量的读操作，这保证了volatile变量的可见性，简单的理解就是，volatile变量在每次被线程访问时，都强迫从主内存中读该变量的值，而当该变量发生变化时，又会强迫将最新的值刷新到主内存，任何时刻，不同的线程总是能够看到该变量的最新值。
线程启动规则：线程的 start() 方法先于它的每一个动作，即如果线程A在执行线程B的start方法之前修改了共享变量的值，那么当线程B执行start() 方法时，线程A对共享变量的修改对线程B可见
线程终止规则：线程的所有操作先于线程的终结，Thread.join() 方法的作用是等待当前执行的线程终止。假设在线程B终止之前，修改了共享变量，线程A从线程B的 join方法成功返回后，线程B对共享变量的修改将对线程A可见。
线程中断规则：对线程 interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过Thread.interrupted()方法检测线程是否中断。
对象终结规则：对象的构造函数执行，结束先于finalize()方法
传递性：A happen-before B ，B happen-before C ，那么A必然 happen-before C

DCL为什么要禁止指令重排？

以下是一个经典的懒汉式创建单例

public class DoubleCheckLock{
    private static DoubleCheckLock instance;
    private DoubleCheckLock(){} 
    public static DoubleCheckLock getInstance(){
        if(instance == null){
            synchronize(DoubleCheckLock.class){
                if(instance == null){
                    instance = new DoubleCheckLock();
                }
            }
        }
        return instance;
    }
}

一个对象的创建可以简单，可以分为以下三个部分

为对象分配一块空的内存空间
对象初始化，将对象的信息填充到该内存空间中
将该内存地址赋值给引用变量

如果上述步骤2、3发生指令重排，当一条线（T1）程执行完步骤3，此时切换到另外一条线程（T2），当T2进行第一次判断，由于引用变量已经指向了一个地址（对象还没初始化，该地址空间里面还没有内容），所以判断该引用不为null，这就出现很致命的bug。