JUC并发编程 04——Java内存模型之JMM

双非鼠不想输

已于 2024-04-20 18:16:14 修改

阅读量1k

点赞数 19

分类专栏： JUC并发编程文章标签： juc

于 2023-12-13 15:09:02 首次发布

本文链接：https://blog.csdn.net/qq_62767608/article/details/134951225

版权

JUC并发编程专栏收录该内容

11 篇文章 0 订阅

订阅专栏

一.CPU 缓存模型

为什么要弄一个 CPU 高速缓存呢？ 类比我们开发网站后台系统使用的缓存（比如 Redis）是为了解决程序处理速度和访问常规关系型数据库速度不对等的问题。 CPU 缓存则是为了解决 CPU 处理速度和内存处理速度不对等的问题。

我们甚至可以把 内存看作外存的高速缓存，程序运行的时候我们把外存的数据复制到内存，由于内存的处理速度远远高于外存，这样提高了处理速度。

总结：CPU Cache 缓存的是内存数据用于解决 CPU 处理速度和内存不匹配的问题，内存缓存的是硬盘数据用于解决硬盘访问速度过慢的问题。

CPU寄存器：每个CPU都包含一系列的寄存器，CPU访问寄存器的速度远大于主存。
高速缓存cache：为了弥补内存与处理器之间速度差距的问题，计算机系统引入了高速缓存（Cache）作为内存和处理器之间的缓冲。现代计算机通常采用多层次的缓存结构，包括L1缓存、L2缓存、L3缓存等。这些缓存层次结构的设计是为了在不同级别提供不同大小和速度的缓存。
- 高速缓存cache的作用：缓存的主要目的是存储运算需要使用的数据，以便在处理器需要时能够快速访问。当处理器执行指令时，它首先查看缓存中是否存在需要的数据。如果数据在缓存中，就可以直接访问，避免了等待主存读取的时间。如果数据不在缓存中，就需要从主存中加载到缓存，这个过程称为缓存缺失（Cache Miss）。
- 缓存行： 高速缓存将数据以缓存行为单位存储，而不是逐个字节。当处理器请求某个地址的数据时，缓存通常会将整个缓存行加载到缓存中。这是因为在程序执行中，很可能会连续访问相邻的内存位置，因此预取整个缓存行可以提高后续访问的效率。
- 速度层次： 高速缓存的速度介于内部寄存器和主存之间。虽然缓存的访问速度快于主存，但通常比内部寄存器的访问速度慢一些。不同级别的缓存速度也有所差异，L1缓存通常比L2和L3缓存更快。
内存：一个计算机还包含一个主存。所有的CPU都可以访问主存。主存通常比CPU中的缓存（Cache）大得多。
运作原理：通常情况下，当一个CPU需要读取主存时，它会将主存的部分读到CPU缓存（Cache）中。它甚至可能将缓存（Cache）中的部分内容读到它的内部寄存器中，然后在寄存器中执行操作。当CPU需要将结果写回到主存中去时，它会将内部寄存器的值刷新到缓存（Cache）中，然后在某个时间点将值刷新回主存。

缓存一致性问题：在多处理器系统中，每个处理器都有自己的高速缓存（Cache），而它们又共享同一主内存（MainMemory）。基于高速缓存（Cache）的存储交互很好地解决了处理器与内存的速度矛盾，但是也引入了新的问题：缓存一致性（CacheCoherence）。当多个处理器的运算任务都涉及同一块主内存区域时，将可能导致各自的缓存数据不一致的情况，如果真的发生这种情况，那同步回到主内存时以谁的缓存数据为准呢？

CPU 为了解决内存缓存不一致性问题可以通过制定缓存一致协议（比如MESI协议）或者其他手段来解决。 这个缓存一致性协议指的是在 CPU 高速缓存与主内存交互的时候需要遵守的原则和规范。不同的 CPU 中，使用的缓存一致性协议通常也会有所不同。

每个处理器通过嗅探在总线上传播的数据来检查自己的缓存的值是不是过期了，当处理器发现自己缓存行对应的内存地址被修改时，就会将当前处理器的缓存的缓存行设置为无效。

我们的程序运行在操作系统之上，操作系统屏蔽了底层硬件的操作细节，将各种硬件资源虚拟化。于是，操作系统也就同样需要解决内存缓存不一致性问题。

操作系统通过 内存模型（Memory Model） 定义一系列规范来解决这个问题。无论是 Windows 系统，还是 Linux 系统，它们都有特定的内存模型。

二.指令重排序

为了提升执行速度/性能，计算机在执行程序代码的时候，会对指令进行重排序。简单来说就是系统在执行代码的时候并不一定是按照你写的代码的顺序依次执行。

实际上为了提高性能，编译器和处理器在运行时都会对指令做重排序。可以分为以下三类：

编译器优化的重排序。编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
指令级并行的重排序。现代处理器采用了指令级并行技术（Instruction-Level Parallelism，ILP）来将多条指令重叠执行。如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序。由于处理器使用缓存和读/写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

指令重排序可以保证串行（单线程）语义一致，但是没有义务保证多线程间的语义也一致，所以在多线程下，指令重排序可能会导致一些问题。

上述的1属于编译器重排序，2和3属于处理器重排序。这些重排序可能会导致多线程程序出现内存可见性问题。

对于编译器，JMM的编译器重排序规则会禁止特定类型的编译器重排序（不是所有的编译器重排序都要禁止）。
对于处理器重排序，JMM的处理器重排序规则会要求Java编译器在生成指令序列时，插入特定类型的内存屏障（Memory Barriers，Intel称之为Memory Fence）指令，通过内存屏障指令来禁止特定类型的处理器重排序。

三.JMM（Java内存模型）

一般来说，编程语言也可以直接复用操作系统层面的内存模型。不过，不同的操作系统内存模型不同。如果直接复用操作系统层面的内存模型，就可能会导致同样一套代码换了一个操作系统就无法执行了。Java 语言是跨平台的，它需要自己提供一套内存模型以屏蔽系统差异。

这只是 JMM 存在的其中一个原因。实际上，对于 Java 来说，你可以把 JMM 看作是 Java 定义的并发编程相关的一组规范，除了抽象了线程和主内存之间的关系之外，其还规定了从 Java 源代码到 CPU 可执行指令的这个转化过程要遵守哪些和并发相关的原则和规范，其主要目的是为了简化多线程编程，增强程序可移植性的。

JMM提供了一种强大的抽象，使得程序员可以更方便地编写多线程程序而不用过于担心底层的硬件和操作系统的细节。通过使用合适的同步机制，如synchronized关键字、volatile关键字、Locks等，程序员可以确保在多线程环境下的线程安全性和正确的数据共享。

JMM 是如何抽象线程和主内存之间的关系

线程之间的共享变量存储在主内存（Main Memory）中。
每个线程都有一个私有的本地内存（Local Memory），本地内存是JMM的一个抽象概念，并不真实存在，它涵盖了缓存、写缓冲区、寄存器以及其他的硬件和编译器优化。本地内存中存储了该线程以读/写共享变量的拷贝副本。每个线程只能操作自己本地内存中的变量，无法直接访问其他线程的本地内存。如果线程间需要通信，必须通过主内存来进行。
从更低的层次来说，主内存就是硬件的内存，而为了获取更好的运行速度，虚拟机及硬件系统可能会让工作内存优先存储于寄存器和高速缓存中。
Java内存模型中的线程的工作内存（working memory）是cpu的寄存器和高速缓存的抽象描述。而JVM的静态内存储模型（JVM内存模型）只是一种对内存的物理划分而已，它只局限在内存，而且只局限在JVM的内存。

JMM模型下的线程间通信

线程间通信必须要经过主内存。

如下，如果线程A与线程B之间要通信的话，必须要经历下面2个步骤：

线程A把本地内存A中更新过的共享变量刷新到主内存中去。
线程B到主内存中去读取线程A之前已更新过的共享变量。

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

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

除了这 8 种同步操作之外，还规定了下面这些同步规则来保证这些同步操作的正确执行（了解即可）：

不允许线程无原因的将变量从工作内存写回主内存（没有经过任何的assign）。
一个新的变量只能在主内存中诞生，不允许在工作内存中直接使用一个未被初始化的变量（load或者assign）的变量，就是对一个变量进行use和store操作之前，必须先自行load与assign操作。
一个变量在同一时刻只能被一个线程lock，同一个线程能多次lock，必须对应的多次unlock，lock与unlock必须成对的出现。
如果对一个变量执行lock操作，将会清除工作内存中此变量的值，在执行引擎使用这个变量时，必须重新load、assign操作。
如果一个线程对一个变量没有进行lock操作，则不允许unlock，也不允许对其他线程进行unlock。
对一个变量进行unlock时，必须先将变量刷新到主内存。

Java 内存区域和 JMM 有何区别

Java 内存区域和内存模型是完全不一样的两个东西：

JVM 内存结构和 Java 虚拟机的运行时区域相关，是一种对内存的物理划分，它只局限在内存，而且只局限在JVM的内存。定义了 JVM 在运行时如何分区存储程序数据，就比如说堆主要用于存放对象实例。
Java 内存模型和 Java 的并发编程相关，抽象了线程和主内存之间的关系就比如说线程之间的共享变量必须存储在主内存中，规定了从 Java 源代码到 CPU 可执行指令的这个转化过程要遵守哪些和并发相关的原则和规范，其主要目的是为了简化多线程编程，增强程序可移植性的。

Java内存模型解决的问题

1.线程缓存导致的可见性问题

可见性（共享对象可见性）：线程对共享变量修改的可见性。当一个线程修改了共享变量的值，其他线程能够立刻得知这个修改。

如果两个或者更多的线程在没有正确的使用volatile声明或者同步的情况下共享一个对象，一个线程更新这个共享对象可能对其它线程来说是不可见的：共享对象被初始化在主存中。跑在CPU上的一个线程将这个共享对象读到CPU缓存中，然后修改了这个对象。只要CPU缓存没有被刷新回主存，对象修改后的版本对跑在其它CPU上的线程都是不可见的。这种方式可能导致每个线程拥有这个共享对象的私有拷贝，每个拷贝停留在不同的CPU缓存中。

下图示意了这种情形。跑在左边CPU的线程拷贝这个共享对象到它的CPU缓存中，然后将count变量的值修改为2。这个修改对跑在右边CPU上的其它线程是不可见的，因为修改后的count的值还没有被刷新回主存中去。

解决这个内存可见性问题你可以使用：

Java中的volatile关键字：volatile的特殊规则保证了新值能立即同步到主内存，以及每个线程在每次使用volatile变量前都立即从主内存刷新。因此我们可以说volatile保证了多线程操作时变量的可见性。相比之下，普通变量不能保证可见性，因为普通变量被修改后，新值不一定马上同步到主内存，当其他线程需要读取该变量时，可能还是从工作内存中加载旧的值。
Java中的synchronized关键字：
- lock操作：当线程进入synchronized块时，会执行lock操作，该操作会清空工作内存中的共享变量的值，并重新从主内存中加载变量的值。这确保了线程获取锁后，能够看到其他线程在释放锁之前对共享变量所做的修改。
- unlock操作： 当线程退出synchronized块时，会执行unlock操作，该操作会把对共享变量的修改同步回主内存，确保其他线程能够看到释放锁线程对共享变量的修改。

2.多线程写同步与原子性

多线程竞争（Race Conditions）问题：当读，写和检查共享变量时出现race conditions。

如果两个或者更多的线程共享一个对象，多个线程在这个共享对象上更新变量，就有可能发生race conditions。

想象一下，如果线程A读一个共享对象的变量count到它的CPU缓存中。再想象一下，线程B也做了同样的事情，但是往一个不同的CPU缓存中。现在线程A将count加1，线程B也做了同样的事情。现在count已经被增加了两次，每个CPU缓存中一次。如果这些增加操作被顺序的执行，变量count应该被增加两次，然后原值+2被写回到主存中去。然而，两次增加都是在没有适当的同步下并发执行的。无论是线程A还是线程B将count修改后的版本写回到主存中去，修改后的值仅会被原值大1，尽管增加了两次：

解决这个问题可以使用Java同步块。

一个同步块可以保证在同一时刻仅有一个线程可以进入代码的临界区。同步块还可以保证代码块中所有被访问的变量将会从主存中读入，当线程退出同步代码块时，所有被更新的变量都会被刷新回主存中去，不管这个变量是否被声明为volatile。

使用原子性保证多线程写同步问题

原子性：指一个操作是按原子的方式执行的。要么该操作不被执行；要么以原子方式执行，即执行过程中不会被其它线程中断。

实现原子性：

由Java内存模型来直接保证的原子性变量操作包括read、load、assign、use、store、write，我们大致可以认为基本数据类型变量、引用类型变量、声明为volatile的任何类型变量的访问读写是具备原子性的。这些类型变量的读、写天然具有原子性，但类似于 “基本变量++” / “volatile++” 这种复合操作并没有原子性。
如果应用场景需要一个更大范围的原子性保证，需要使用同步块技术。Java内存模型提供了lock和unlock操作来满足这种需求。虚拟机提供了字节码指令monitorenter和monitorexist来隐式地使用这两个操作，这两个字节码指令反映到Java代码中就是同步块——synchronized关键字。

补充：long和double的非原子性协定

Java内存模型要求lock、unlock、read、load、assign、use、store、write这8个操作都具有原子性，但是对于64位的数据类型（double、long）定义了相对宽松的规定：允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次的32位操作来进行，即允许虚拟机可以不保证64位数据类型的load、store、read和write操作的原子性。

非原子性协定可能导致的问题

如果有多个线程共享一个未申明为volatile的long或double类型的变量，并且同时对其进行读取和修改操作，就有可能会有线程读取到"半个变量"的数值或者是一半正确一半错误的失效数据。

在实际应用中的解决

因为上述可能造成的问题，势必在对long和double类型变量操作时要加上volatile关键字。volatile只能保证可见性不能保证原子性，但用volatile修饰long和double可以保证其操作原子性。

实际上如下：

64位的java虚拟机不存在这个问题，可以操作64位的数据
目前商用JVM基本上都会将64位数据的操作作为原子操作实现

所以我们编写代码时一般不需要将long和double变量专门申明为volatile

3.指令重排序带来的问题

编译器为了优化性能，有时候会改变程序中语句的先后顺序，例如程序中：“a=6；b=7；”编译器优化后可能变成“b=7；a=6；”，在这个例子中，编译器调整了语句的顺序，但是不影响程序的最终结果。不过有时候编译器及解释器的优化可能导致意想不到的 Bug。

一个经典的案例就是利用双重检查创建单例对象，例如下面的代码：在获取实例 getInstance() 的方法中，我们首先判断 instance 是否为空，如果为空，则锁定 Singleton.class 并再次检查 instance 是否为空，如果还为空则创建 Singleton 的一个实例。

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

假设有两个线程 A、B 同时调用 getInstance() 方法，他们会同时发现 instance == null ，于是同时对 Singleton.class 加锁，此时 JVM 保证只有一个线程能够加锁成功（假设是线程 A），另外一个线程则会处于等待状态（假设是线程 B）；线程 A 会创建一个 Singleton 实例，之后释放锁，锁释放后，线程 B 被唤醒，线程 B 再次尝试加锁，此时是可以加锁成功的，加锁成功后，线程 B 检查 instance == null 时会发现，已经创建过 Singleton 实例了，所以线程 B 不会再创建一个 Singleton 实例。这看上去一切都很完美，无懈可击，但实际上这个 getInstance() 方法并不完美。问题出在哪里呢？出在 new 操作上，我们以为的 new 操作应该是：

分配一块内存 M；
在内存 M 上用构造器初始化 Singleton 对象；
然后 M 的地址赋值给 instance 变量。

是实际上优化后的执行路径却是这样的：

分配一块内存 M；
将 M 的地址赋值给 instance 变量；
最后在内存 M 上用构造器初始化 Singleton 对象。

优化后会导致什么问题呢？我们假设线程 A 先执行 getInstance() 方法，当执行完指令 2 时恰好发生了线程切换，切换到了线程 B 上；如果此时线程 B 也执行 getInstance() 方法，那么线程 B 在执行第一个判断时会发现 instance != null ，所以直接返回 instance，而此时的 instance 是没有初始化过的，如果我们这个时候访问 instance 的成员变量就可能触发空指针异常，并且线程B无需获取锁。

happens-before原则

happens-before 原则的诞生是为了程序员和编译器、处理器之间的平衡。

程序员追求的是易于理解和编程的强内存模型，遵守既定规则编码即可，但是JMM对编译器和处理器限制的越死，程序执行的效率就越低。
编译器和处理器追求的是较少约束的弱内存模型，让它们尽己所能地去优化性能，让性能最大化。

对于这两个矛盾的需求，JMM就需要找到两者之间的平衡。所以happens-before 原则的设计思想其实非常简单：

为了对编译器和处理器的约束尽可能少，只要不改变程序的执行结果（这个重排序在没有改变单线程程序的执行结果的前提下），编译器和处理器怎么进行重排序优化都行。
对于会改变程序执行结果的重排序，JMM 要求编译器和处理器必须禁止这种重排序。

JMM禁止了会影响程序执行的重排序，同时放开了对不影响程序执行结果的重排序的限制。也就是说，只要不影响程序运行的结果，编译器和处理器想怎么优化都可以。例如：

如果编译器经过细致的分析后，认定一个锁只会被单个线程访问，那么这个锁可以被消除。
如果编译器经过细致的分析后，认定一个volatile变量只会被单个线程访问，那么编译器可以把这个volatile变量当作一个普通变量来对待。

这些优化既不会改变程序的执行结果，又能提高程序的执行效率。

happens-before的常见规则

happens-before 的规则有 8 条，下面给出常见的5条：

程序顺序规则：一个线程内，按照代码顺序，书写在前面的操作 happens-before 于书写在后面的操作；
解锁规则：解锁 happens-before 于加锁；
volatile 变量规则：对一个 volatile 变量的写操作 happens-before 于后面对这个 volatile 变量的读操作。说白了就是对 volatile 变量的写操作的结果对于发生于其后的任何操作都是可见的。
传递规则：如果 A happens-before B，且 B happens-before C，那么 A happens-before C；
线程启动规则：Thread 对象的start()方法 happens-before 于此线程的每一个动作。

JMM 抽象了 happens-before 原则来解决指令重排序问题。

我们看下面这段代码：

int userNum = getUserNum(); 	// 1
int teacherNum = getTeacherNum();	 // 2
int totalNum = userNum + teacherNum;	// 3

1 happens-before 2
2 happens-before 3
1 happens-before 3

虽然 1 happens-before 2，但对 1 和 2 进行重排序不会影响代码的执行结果，所以 JMM 是允许编译器和处理器执行这种重排序的。但 1 和 2 必须是在 3 执行之前，也就是说 1，2 happens-before 3 。

happens-before 原则表达的意义其实并不是一个操作发生在另外一个操作的前面，更准确地来说，它更想表达的意义是前一个操作的结果对于后一个操作是可见的，无论这两个操作是否在同一个线程里。注意，这是 JMM向程序员做出的保证。

举个例子：操作 1 happens-before 操作 2，即使操作 1 和操作 2 不在同一个线程内，JMM 也会保证操作 1 的结果对操作 2 是可见的。

了解了 happens-before 原则的设计思想，我们再来看看 JSR-133 对 happens-before 原则的定义：

如果一个操作 happens-before 另一个操作，那么第一个操作的执行结果将对第二个操作可见。
两个操作之间存在 happens-before 关系，并不意味着 Java 平台的具体实现必须要按照 happens-before 关系指定的顺序来执行。如果重排序之后的执行结果，与按 happens-before 关系来执行的结果一致，那么 JMM 也允许这样的重排序。happens-before这么做的目的，都是为了在不改变程序执行结果的前提下，尽可能地提高程序执行的并行度。

一个happens-before规则对应于一个或多个编译器和处理器重排序规则。对于Java程序员来说，happens-before规则简单易懂，它避免Java程序员为了理解JMM提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现方法。关系如下图所示：