什么是JMM模型

• 什么是JMM模型？
• • JMM不同于JVM内存区域模型
  • • 主内存
    • 工作内存
    • Java内存模型与硬件内存架构的关系
  • JMM存在的必要性
  • 数据同步八大原子操作
  • • 同步规则分析
  • 并发编程的可见性，原子性与有序性问题
  • • 原子性
    • 可见性
    • 有序性
  • JMM如何解决原子性&可见性&有序性问题
  • • 原子性问题
    • 可见性问题
    • 有序性问题
    • as-if-serial语义
    • happens-before 原则
• volatile内存含义
• • volatile的可见性
  • volatile无法保证原子性
  • volatile禁止指令重排优化
  • 硬件层的内存屏障
  • volatile内存语义的实现

上一篇：操作系统底层工作原理

什么是JMM模型？

java内存模型（Java Memory Model）简称JMM，是一种抽象的概念，并不是真实存在，它描述的是一组规则或规范，通过这组规范定义了程序中各个变量的访问方式。JVM运行程序的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存，用于存储线程的私有数据，而java内存模型中规定所有变量都存储在主内存中，主内存是共享内存区域，所有线程都可以访问，但线程对变量的操作必须在工作内存中进行，首先要将变量从主内存中拷贝到自己的工作内存中，然后对变量进行操作，操作完后再将变量写回到主内存中，不能直接操作主内存的变量，工作内存中存储着主内存中变量的副本，工作内存是每个线程的私有数据区域，因此不同的线程无法访问彼此的内存，线程的传值必须通过主内存来完成。

JMM不同于JVM内存区域模型

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

主内存，工作内存交互图

主内存

主要存储的是java实例对象，所有线程创建的实例对象都存放在主内存中，不管改实例对象是成员变量还是局部变量，也包括共享的类信息，常量，静态变量，由于那时共享数据区域，多条线程对同一个变量进行访问可能会发生线程安全问题

工作内存

主要存储当前方法的所有本地变量信息(工作内存中存储着主内存中的变量副本拷贝)， 每个线程只能访问自己的工作内存，即线程中的本地变量对其它线程是不可见的，就算是两 个线程执行的是同一段代码，它们也会各自在自己的工作内存中创建属于当前线程的本地变 量，当然也包括了字节码行号指示器、相关Native方法的信息。注意由于工作内存是每个 线程的私有数据，线程间无法相互访问工作内存，因此存储在工作内存的数据不存在线程安 全问题。
根据JVM虚拟机规范主内存与工作内存的数据存储类型以及操作方式，对于一个实例对 象中的成员方法而言，如果方法中包含本地变量是基本数据类型，将直接存储在工作内存的帧栈结构 中，但倘若本地变量是引用类型，那么该变量的引用会存储在功能内存的帧栈中，而对象实 例将存储在主内存(共享数据区域，堆)中。但对于实例对象的成员变量，不管它是基本数据 类型或者包装类型(Integer、Double等)还是引用类型，都会被存储到堆区。至于static变 量以及类本身相关信息将会存储在主内存中。需要注意的是，在主内存中的实例对象可以被多线程共享，倘若两个线程同时调用了同一个对象的同一个方法，那么两条线程会将要操作 的数据拷贝一份到自己的工作内存中，执行完成操作后才刷新到主内存.
模型图

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

多线程的执行最终都会映射到硬件处理器上进行执行，但Java内存模型和硬 件内存架构并不完全一致。对于硬件内存来说只有寄存器、缓存内存、主内存的概念，并没 有工作内存(线程私有数据区域)和主内存(堆内存)之分，也就是说Java内存模型对内存的划 分对硬件内存并没有任何影响，因为JMM只是一种抽象的概念，是一组规则，并不实际存 在，不管是工作内存的数据还是主内存的数据，对于计算机硬件来说都会存储在计算机主内 存中，当然也有可能存储到CPU缓存或者寄存器中，因此总体上来说，Java内存模型和计算 机硬件内存架构是一个相互交叉的关系，是一种抽象概念划分与真实物理硬件的交叉。

JMM存在的必要性

由于JVM 运行的实体是线程，而每个线程创建时JVM都会为其创建一个工作内存，用于存储线程的私有数据，线程与主内存的变量操作必须通过主内存间接完成，主要过程是将变量从主内存中拷贝到工作内存中，然后对变量进行操作，操作完以后再把变量写回主内存中，如果两个线程同时对一个主内存中的实例对象的变量进行操作可能会发生线程安全问题。
假设主内存中存在一个共享变量x，现在有A和B两条线程分别对该变量x=1进行操作， A/B线程各自的工作内存中存在共享变量副本x。假设现在A线程想要修改x的值为2，而B线 程却想要读取x的值，那么B线程读取到的值是A线程更新后的值2还是更新前的值1呢？答案 是，不确定，即B线程有可能读取到A线程更新前的值1，也有可能读取到A线程更新后的值 2，这是因为工作内存是每个线程私有的数据区域，而线程A变量x时，首先是将变量从主内 存拷贝到A线程的工作内存中，然后对变量进行操作，操作完成后再将变量x写回主内，而 对于B线程的也是类似的，这样就有可能造成主内存与工作内存间数据存在一致性问题，假 如A线程修改完后正在将数据写回主内存，而B线程此时正在读取主内存，即将x=1拷贝到 自己的工作内存中，这样B线程读取到的值就是x=1，但如果A线程已将x=2写回主内存后， B线程才开始读取的话，那么此时B线程读取到的就是x=2，但到底是哪种情况先发生呢？

以上关于主内存与工作内存之间的具体交互协议，即一个变量如何从主内存拷贝到工作 内存、如何从工作内存同步到主内存之间的实现细节。

数据同步八大原子操作

1. lock（锁定）：作用于主内存的变量，把一个变量标记为一个线程独占状态
2. unlock（解锁）：作用于主内存的变量，把一个处于锁定状态的变量释放出来，释放后的变量才能被其他线程锁定
3. read（读取）：作用于主内存的变量把一个变量值从主内存传输到线程的工作内存中，以便以后的load操作
4. load（载入）：作用于工作内存的变量，把read操作从主内存中得到的变量值放入工作内存的变量副本中
5. use（使用）：作用于工作内存的变量，把工作内存的变量值传输给执行引擎
6. assign（赋值）：作用于工作内存的变量，把一个从执行引擎接收到的值赋给工作内存的变量
7. store（存储）：作用于工作内存的变量，把工作内存中的一个变量值传送到主内存中，以便以后的write操作
8. write（写入）：作用于工作内存的变量，把store操作从工作内存中的一个变量值传送到主内存中

如果要把一个变量从主内存中复制到工作内存中，就需要按顺序地执行read和load操 作，如果把变量从工作内存中同步到主内存中，就需要按顺序地执行store和write操作。但Java内存模型只要求上述操作必须按顺序执行，而没有保证必须是连续执行。

同步规则分析

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

并发编程的可见性，原子性与有序性问题

原子性

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

可见性

可见性指的是当一个线程修改了某个共享变量 的值，其他线程是否能够马上得知这个修改的值。对于串行程序来说，可见性是不存在的， 因为我们在任何一个操作中修改了某个变量的值，后续的操作中都能读取这个变量值，并且 是修改过的新值。
但在多线程环境中可就不一定了，前面我们分析过，由于线程对共享变量的操作都是线 程拷贝到各自的工作内存进行操作后才写回到主内存中的，这就可能存在一个线程A修改了 共享变量x的值，还未写回主内存时，另外一个线程B又对主内存中同一个共享变量x进行操 作，但此时A线程工作内存中共享变量x对线程B来说并不可见，这种工作内存与主内存同步 延迟现象就造成了可见性问题，另外指令重排以及编译器优化也可能导致可见性问题，通过 前面的分析，我们知道无论是编译器优化还是处理器优化的重排现象，在多线程环境下，确 实会导致程序轮序执行的问题，从而也就导致可见性问题。

有序性

有序性是指对于单线程的执行代码，我们总是认为代码的执行是按顺序依次执行的，这 样的理解并没有毛病，毕竟对于单线程而言确实如此，但对于多线程环境，则可能出现乱序 现象，因为程序编译成机器码指令后可能会出现指令重排现象，重排后的指令与原指令的顺 序未必一致，要明白的是，在Java程序中，倘若在本线程内，所有操作都视为有序行为，如 果是多线程环境下，一个线程中观察另外一个线程，所有操作都是无序的，前半句指的是单 线程内保证串行语义执行的一致性，后半句则指指令重排现象和工作内存与主内存同步延迟 现象。

JMM如何解决原子性&可见性&有序性问题

原子性问题

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

可见性问题

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

有序性问题

在Java里面，可以通过volatile关键字来保证一定的“有序性”（具体原理在下一节讲 述volatile关键字）。另外可以通过synchronized和Lock来保证有序性，很显然， synchronized和Lock保证每个时刻是有一个线程执行同步代码，相当于是让线程顺序执行 同步代码，自然就保证了有序性。
Java内存模型：每个线程都有自己的工作内存（类似于前面的高速缓存）。线程对变 量的所有操作都必须在工作内存中进行，而不能直接对主存进行操作。并且每个线程不能访 问其他线程的工作内存。Java内存模型具备一些先天的“有序性”，即不需要通过任何手段 就能够得到保证的有序性，这个通常也称为happens-before 原则。如果两个操作的执行次 序无法从happens-before原则推导出来，那么它们就不能保证它们的有序性，虚拟机可以 随意地对它们进行重排序。
指令重排序：java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果 与它顺序化情况的结果相等，那么指令的执行顺序可以与代码顺序不一致，此过程叫指令的 重排序。指令重排序的意义是什么？JVM能根据处理器特性（CPU多级缓存系统、多核处 理器等）适当的对机器指令进行重排序，使机器指令能更符合CPU的执行特性，最大限度的 发挥机器性能。

最终执行的指令序列示意图

as-if-serial语义

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

happens-before 原则

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

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

volatile内存含义

volatile是Java虚拟机提供的轻量级的同步机制。volatile关键字有如下两个作用

• 保证被volatile修饰的共享变量对所有线程总数可见的，也就是当一个线程修改 了一个被volatile修饰共享变量的值，新值总是可以被其他线程立即得知。
• 禁止指令重排序优化。

volatile的可见性

关于volatile的可见性作用，我们必须意识到被volatile修饰的变量对所有线程总数立即 可见的，对volatile变量的所有写操作总是能立刻反应到其他线程中

public class VolatileDemo {
    volatile boolean initFlag = false;

    public void save() {
        this.initFlag = true;
        String threadname = Thread.currentThread().getName();
        System.out.println("线程：" + threadname + ":修改共享变量initFlag");
    }

    public void load() {
        String threadname = Thread.currentThread().getName();
        while (!initFlag) {
            //线程在此处空跑，等待initFlag状态改变
        }
        System.out.println("线程：" + threadname + "当前线程嗅探到initFlag的状态的改变");
    }

    public static void main(String[] args) {
        VolatileDemo sample = new VolatileDemo();
        Thread threadA = new Thread(() -> {
            sample.save();
        }, "threadA");
        Thread threadB = new Thread(() -> {
            sample.load();
        }, "threadB");
        threadB.start();
        try {
            Thread.sleep(1000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        threadA.start();
    }
}

线程A改变initFlag属性之后，线程B马上感知到

volatile无法保证原子性

	public static volatile int i = 0;
    public static void increase() {
        i++;
    }

在并发场景下，i变量的任何改变都会立马反应到其他线程中，但是如此存在多条线程 同时调用increase()方法的话，就会出现线程安全问题，毕竟i++;操作并不具备原子性，该 操作是先读取值，然后写回一个新值，相当于原来的值加上1，分两步完成，如果第二个线 程在第一个线程读取旧值和写回新值期间读取i的域值，那么第二个线程就会与第一个线程 一起看到同一个值，并执行相同值的加1操作，这也就造成了线程安全失败，因此对于 increase方法必须使用synchronized修饰，以便保证线程安全，需要注意的是一旦使用 synchronized修饰方法后，由于synchronized本身也具备与volatile相同的特性，即可见 性，因此在这样种情况下就完全可以省去volatile修饰变量。

volatile禁止指令重排优化

volatile关键字另一个作用就是禁止指令重排优化，从而避免多线程环境下程序出现乱 序执行的现象，关于指令重排优化前面已详细分析过，这里主要简单说明一下volatile是如 何实现禁止指令重排优化的。先了解一个概念，内存屏障(Memory Barrier）。

硬件层的内存屏障

Intel硬件提供了一系列的内存屏障，主要有：

1. lfence，是一种Load Barrier 读屏障
2. sfence, 是一种Store Barrier 写屏障
3. mfence, 是一种全能型的屏障，具备ifence和sfence的能力
4. Lock前缀，Lock不是一种内存屏障，但是它能完成类似内存屏障的功能。Lock会对 CPU总线和高速缓存加锁。

不同硬件实现内存屏障的方式不同，Java内存模型屏蔽了这种底层硬件平台的差异，由 JVM来为不同的平台生成相应的机器码。 JVM中提供了四类内存屏障指令：

屏障类型	指令示例	说明
LoadLoad	Load1; LoadLoad; Load2	保证load1的读取操作在load2及后续读取操作之前执行
StoreStore	Store1; StoreStore; Store2	在store2及其后的写操作执行前，保证store1的写操作已刷新到主内存
LoadStore	Load1; LoadStore; Store2	在stroe2及其后的写操作执行前，保证load1的读操作已读取结束
StoreLoad	Store1; StoreLoad; Load2	保证store1的写操作已刷新到主内存之后，load2及其后的读操作才能执行

内存屏障，又称内存栅栏，是一个CPU指令，它的作用有两个，一是保证特定操作的执 行顺序，二是保证某些变量的内存可见性（利用该特性实现volatile的内存可见性）。由于 编译器和处理器都能执行指令重排优化。如果在指令间插入一条Memory Barrier则会告诉 编译器和CPU，不管什么指令都不能和这条Memory Barrier指令重排序，也就是说通过插 入内存屏障禁止在内存屏障前后的指令执行重排序优化。Memory Barrier的另外一个作用 是强制刷出各种CPU的缓存数据，因此任何CPU上的线程都能读取到这些数据的最新版本。 总之，volatile变量正是通过内存屏障实现其在内存中的语义，即可见性和禁止重排优化。

volatile内存语义的实现

前面提到过重排序分为编译器重排序和处理器重排序。为了实现volatile内存语义， JMM会分别限制这两种类型的重排序类型。

是JMM针对编译器制定的volatile重排序规则表

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

• 当第二个操作是volatile写时，不管第一个操作是什么，都不 能重排序。这个规则确保volatile写之前的操作不会被编译器重排序 到volatile写之后。
• 当第一个操作是volatile读时，不管第二个操作是什么，都不 能重排序。这个规则确保volatile读之后的操作不会被编译器重排序到volatile读之前。
• 当第一个操作是volatile写，第二个操作是volatile读时，不能 重排序。

为了实现volatile的内存语义，编译器在生成字节码时，会在指令序列中插入内存屏障 来禁止特定类型的处理器重排序。对于编译器来说，发现一个最优布置来最小化插入屏障的 总数几乎不可能。为此，JMM采取保守策略。

• ∙在每个volatile写操作的前面插入一个StoreStore屏障。
• 在每个volatile写操作的后面插入一个StoreLoad屏障。
• 在每个volatile读操作的后面插入一个LoadLoad屏障。
• 在每个volatile读操作的后面插入一个LoadStore屏障。

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

上图中StoreStore屏障可以保证在volatile写之前，其前面的所有普通写操作已经对任 意处理器可见了。这是因为StoreStore屏障将保障上面所有的普通写在volatile写之前刷新 到主内存。
volatile写后面的StoreLoad屏障。此屏障的作用是避免volatile 写与 后面可能有的volatile读/写操作重排序。因为编译器常常无法准确判断在一个volatile 写的后面 是否需要插入一个StoreLoad屏障（比如，一个volatile写之后方法立即 return）。为了保证能正确 实现volatile的内存语义，JMM在采取了保守策略：在每个volatile写的后面，或者在每个volatile 读的前面插入一个StoreLoad屏障。从整体执行效 率的角度考虑，JMM最终选择了在每个 volatile写的后面插入一个StoreLoad屏障。因为 volatile写-读内存语义的常见使用模式是：一个 写线程写volatile变量，多个读线程读同一 个volatile变量。当读线程的数量大大超过写线程时，选择在volatile写之后插入StoreLoad 屏障将带来可观的执行效率的提升。从这里可以看到JMM 在实现上的一个特点：首先确保 正确性，然后再去追求执行效率。

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

上图中LoadLoad屏障用来禁止处理器把上面的volatile读与下面的普通读重排序。 LoadStore屏障用来禁止处理器把上面的volatile读与下面的普通写重排序。
上述volatile写和volatile读的内存屏障插入策略非常保守。在实际执行时，只要不改变 volatile写-读的内存语义，编译器可以根据具体情况省略不必要的屏障。

 	int a;
    volatile int v1 = 1;
    volatile int v2 = 2;
    void readAndWrite() {
        int i = v1;    // 第一个volatile读
        int j = v2;    // 第二个volatile读
        a = i + j;         // 普通写
        v1 = i + 1;     // 第一个volatile写
        v2 = j * 2;     // 第二个 volatile写
    }

针对readAndWrite()方法，编译器在生成字节码时可以做如下的优化。

最后的StoreLoad屏障不能省略。因为第二个volatile写之后，方法立即 return。此时编 译器可能无法准确断定后面是否会有volatile读或写，为了安全起见，编译 器通常会在这里插 入一个StoreLoad屏障。

标签：变量,屏障,线程,内存,JMM,volatile,多线程,操作
来源： https://blog.csdn.net/qq_45217077/article/details/121875953