有图有真相的Java内存模型基础,你好意思不看嘛!

简介: 有图有真相的Java内存模型基础


一、并发编程模型分类


并发编程要处理的两个问题:(这里的线程是指并发执行活动的实体)


线程之间如何通信:通信是指线程之间以何种机制来交换 信息。

线程之间如何同步:同步是指程序用于控制不同线程之间操作发生相对顺序的机制。

由这两个问题引出并发编程的两个模型


共享内存并发模型

消息传递并发模型


1.1 共享内存

解决通信

在共享内存的并发模型里,线程之间共享程序的公共状态,线程之间通过写-读内存中的公共状态来隐式进行通信。


解决同步

在共享内存并发模型里,同步是显式进行的。程序员必须显式指定某个方法或某段代码需要在线程之间互斥执行。


1.2 消息传递

解决通信

在消息传递的并发模型里,线程之间没有公共状态,线程之间必须通过明确的发送消息来显式进行通信。


解决同步

消息传递的并发模型里,由于消息的发送必须在消息的接收之前, 因此同步是隐式进行的。


1.3 Java的并发采用模型

Java的并发采用的是共享内存模型;


Java 线程之间的通信总是隐式进行,整个通信过程对程序员完全透明。如果编写多线程程序的我们不理解隐式进行的线程之间通信的工作机制,很可能会遇到各种奇怪的内存可见性问题。


二、Java内存模型(JMM)的抽象


在java中,所有实例域、静态域和数组元素存储在堆内存中;


堆内存在线程之间共享(本文使用“共享变量”这个术语代指实例域,静态域和数组元素);


局部变量 (Local variables),方法定义参数(java语言规范称之为formal method parameters)和异常处理器参数(exception handler parameters)不会在线程之间共享,它们不会有内存可见性问题,也不受内存模型的影响;


Java 线程之间的通信由Java内存模型(本文简称为 JMM)控制,JMM 决定一个 线程对共享变量的写入何时对另一个线程可见;


从抽象的角度来看,JMM 定义了 线程和主内存之间的抽象关系:线程之间的共享变量存储在主内存(main memory)中,每个线程都有一个私有的本地内存(local memory),本地内存中存储了该线程以读/写共享变量的副本;


本地内存是 JMM 的一个抽象概念,并不 真实存在。它涵盖了缓存,写缓冲区,寄存器以及其他的硬件和编译器优化;


Java 内存模型的抽象示意图如下:


image.png


从上图来看,线程 A 与线程 B 之间如要通信的话,必须要经历下面 2 个步骤:


  1. 首先,线程 A 把本地内存 A 中更新过的共享变量刷新到主内存中去;
  2. 然后,线程 B 到主内存中去读取线程 A 之前已更新过的共享变量;


下面通过示意图来说明这两个步骤:


image.png


如上图所示,本地内存 A 和 B 有主内存中共享变量 x 的副本。


假设初始时,这三个 内存中的 x 值都为 0。


线程 A 在执行时,把更新后的 x 值(假设值为 1)临时存放 在自己的本地内存 A 中。


当线程 A 和线程 B 需要通信时,线程 A 首先会把自己本 地内存中修改后的 x 值刷新到主内存中,此时主内存中的 x 值变为了 1。


随后,线程 B 到主内存中去读取线程 A 更新后的 x 值,此时线程 B 的本地内存的 x 值也变为了 1。


从整体来看,这两个步骤实质上是线程 A 在向线程 B 发送消息,而且这个通信过程 必须要经过主内存。JMM 通过控制主内存与每个线程的本地内存之间的交互,来为 java 程序员提供内存可见性保证。


image.png


三、 重排序


在执行程序时为了提高性能,编译器和处理器常常会对指令做重排序。


重排序分三 种类型:


编译器优化的重排序。编译器在不改变单线程程序语义的前提下,可以重新安排语句的执行顺序。


指令级并行的重排序。现代处理器采用了指令级并行技术(Instruction-Level Parallelism, ILP)来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。


内存系统的重排序。由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行。


从 java 源代码到最终实际执行的指令序列,会分别经历下面三种重排序:


image.png


上述的 1 属于编译器重排序;2 和 3 属于处理器重排序;


这些重排序都可能会导致多线程程序出现内存可见性问题;


对于编译器,JMM 的编译器重排序规则会禁止特定类型的编译器重排序(不是所有的编译器重排序都要禁止);


对于处理器重排序,JMM 的处理器重排序规则会要求 java 编译器在生成指令序列时,插入特定类 型的内存屏障(memory barriers,intel 称之为 memory fence)指令,通过内存屏障指令来禁止特定类型的处理器重排序(不是所有的处理器重排序都要禁止);


JMM 属于语言级的内存模型,它确保在不同的编译器和不同的处理器平台之上, 通过禁止特定类型的编译器重排序和处理器重排序,为程序员提供一致的内存可见性保证。


四、处理器重排序与内存屏障指令


现代的处理器使用写缓冲区来临时保存向内存写入的数据。


写缓冲区可以保证指令流水线持续运行,它可以避免由于处理器停顿下来等待向内存写入数据而产生的延迟;


同时,通过以批处理的方式刷新写缓冲区,以及合并写缓冲区中对同一内存地址的多次写,可以减少对内存总线的占用;


虽然写缓冲区有这么多好处,但每个处理器上的写缓冲区,仅仅对它所在的处理器可见。这个特性会对内存操作的执行顺序产生重要的影响:处理器对内存的读/写操作的执行顺序,不一定与内存实际发生的读/写操作顺序一致;


为了具体说明,请看下面示例:


处理器A 处理器B
a = 1 // A1 b = 2 // B1
x = b // A2 y = a // B2


初始状态:a = b = 0


处理器允许执行后得到结果:x = y = 0


假设处理器 A 和处理器 B 按程序的顺序并行执行内存访问,最终却可能得到 x = y = 0 的结果。具体的原因如下图所示:


image.png


这里处理器 A 和处理器 B 可以同时把共享变量写入自己的写缓冲区(A1,B1), 然后从内存中读取另一个共享变量(A2,B2),最后才把自己写缓存区中保存的 脏数据刷新到内存中(A3,B3);


当以这种时序执行时,程序就可以得到 x = y = 0 的结果。 从内存操作实际发生的顺序来看,直到处理器 A 执行 A3 来刷新自己的写缓存区, 写操作 A1 才算真正执行了。虽然处理器 A 执行内存操作的顺序为:A1->A2,但内存操作实际发生的顺序却是:A2->A1。此时,处理器 A 的内存操作顺序被重排序了(处理器 B 的情况和处理器 A 一样,这里就不赘述了)。


这里的关键是,由于写缓冲区仅对自己的处理器可见,它会导致处理器执行内存操作的顺序可能会与内存实际的操作执行顺序不一致。


由于现代的处理器都会使用写缓冲区,因此现代的处理器都会允许对写-读操作重排序。


下面是常见处理器允许的重排序类型的列表:


Load(读)


Store(写)



Load-Load
Load-Store Store-Store Store-Load 数据依赖
sparc-TSO N N N Y N
x86 N N N Y N
ia64 Y Y Y Y N
PowerPC Y Y Y Y N


上表单元格中的“N”表示处理器不允许两个操作重排序,“Y”表示允许重排 序;


从上表我们可以看出:常见的处理器都允许 Store-Load 重排序;


常见的处理器都 不允许对存在数据依赖的操作做重排序。sparc-TSO 和 x86 拥有相对较强的处理器内存模型,它们仅允许对写-读操作做重排序(因为它们都使用了写缓冲区)。


※注 1:sparc-TSO 是指以 TSO(Total Store Order)内存模型运行时,sparc 处理 器的特性。


※注 2:上表中的 x86 包括 x64 及 AMD64。


※注 3:由于 ARM 处理器的内存模型与 PowerPC 处理器的内存模型非常类似,本文将忽 略它。


※注 4:数据依赖性后文会专门说明。


image.png


为了保证内存可见性,java 编译器在生成指令序列的适当位置会插入内存屏障指令 来禁止特定类型的处理器重排序。


JMM 把内存屏障指令分为下列四类:


image.png


StoreLoad Barriers 是一个“全能型”的屏障,它同时具有其他三个屏障的效果。


现代的多处理器大都支持该屏障(其他类型的屏障不一定被所有处理器支持)。执行该屏障开销会很昂贵,因为当前处理器通常要把写缓冲区中的数据全部刷新到内存中(buffer fully flush)。


五、happens-before(发生之前)

从 JDK5 开始,java 使用新的 JSR -133 内存模型(本文除非特别说明,针对的都 是 JSR- 133 内存模型);


JSR-133 使用 happens-before 的概念来阐述操作之间的内存可见性;


在 JMM 中,如果一个操作执行的结果需要对另一个操作可见,那么这两个操作之间必须要存在 happens-before 关系。这里提到的两个操作既可以是在一个线程之内,也可以是在不同线程之间;


与程序员密切相关的 happens-before 规则如下:


程序顺序规则:一个线程中的每个操作,happens- before 于该线程中的任意后续操作。


这个还是非常好理解的,比如上面那三行代码,第一行的 "double pi = 3.14; " happens-before 于 “double r = 1.0;”,这就是规则1的内容,比较符合单线程里面的逻辑思维,很好理解。


double pi = 3.14; // A
double r = 1.0; // B
double area = pi * r * r; // C


监视器锁规则:对一个监视器的解锁,happens- before 于随后对这个监视器的加锁。


这个规则中说的锁其实就是Java里的 synchronized。例如下面的代码,在进入同步块之前,会自动加锁,而在代码块执行完会自动释放锁,加锁以及释放锁都是编译器帮我们实现的。


synchronized (this) { //此处自动加锁
  // x是共享变量,初始值=10
  if (this.x < 12) {
    this.x = 12; 
  }  
} //此处自动解锁


所以结合锁规则,可以理解为:假设 x 的初始值是 10,线程 A 执行完代码块后 x 的值会变成 12(执行完自动释放锁),线程 B 进入代码块时,能够看到线程 A 对 x 的写操作,也就是线程 B 能够看到 x==12。这个也是符合我们直觉的,非常好理解。


volatile变量规则:对一个 volatile 域的写,happens- before 于任意后续对 这个 volatile 域的读。


这个就有点费解了,对一个 volatile 变量的写操作相对于后续对这个 volatile 变量的读操作可见,这怎么看都是禁用缓存的意思啊,貌似和 1.5 版本以前的语义没有变化啊(1.5版本前允许volatile变量和普通变量之间重排序)?如果单看这个规则,的确是这样,但是如果我们关联一下规则 4,你就能感受到变化了


传递性:如果 A happens- before B,且 B happens- before C,那么 A happens- before C。


我们将规则 4 的传递性应用到我们下面的例子中,会发生什么呢?


class VolatileExample {
  int x = 0;
  volatile boolean v = false;
  public void writer() {
    x = 42;
    v = true;
  }
  public void reader() {
    if (v == true) {
      // 这里x会是多少呢?
    }
  }
}


可以看下面这幅图:


image.png


从图中,我们可以看到:


“x=42” Happens-Before 写变量 “v=true” ,这是规则 1 的内容;


写变量“v=true” Happens-Before 读变量 “v=true”,这是规则 3 的内容 。


再根据这个传递性规则,我们得到结果:“x=42” Happens-Before 读变量“v=true”。这意味着什么呢?


如果线程 B 读到了“v=true”,那么线程 A 设置的“x=42”对线程 B 是可见的。也就是说,线程 B 能看到 “x == 42” ,有没有一种恍然大悟的感觉?这就是 1.5 版本对 volatile 语义的增强,这个增强意义重大,1.5 版本的并发工具(java.util.concurrent)就是靠 volatile 语义来搞定可见性的。


start()规则:这条是关于线程启动的。它是指主线程 A 启动子线程 B 后,子线程 B 能够看到主线程在启动子线程 B 前的操作。


join()规则:如果线程A执行操作ThreadB.join()并成功返回,那么线程B中的任意操作happens-before于线程A从ThreadB.join()操作成功返回。


通过上面6中 happens-before 规则的组合就能为我们程序员提供一致的内存可见性。 常用的就是规则1和其他规则结合,为我们编写并发程序提供可靠的内存可见性模型。


image.png


注意,两个操作之间具有 happens-before 关系,并不意味着前一个操作必须要在后一个操作之前执行!


happens-before关系的定义如下:


如果一个操作happens-before另一个操作,那么第一个操作的执行结果将对第二个操作可见,而且第一个操作的执行顺序排在第二个操作之前。


两个操作之间存在happens-before关系,并不意味着Java平台的具体实现必须要按照happens-before关系指定的顺序来执行。如果重排序之后的执行结果,与按happens-before关系来执行的结果一致,那么这种重排序并不非法(也就是说,JMM允许这种重排序)。


上面的1)是JMM对程序员的承诺。 从程序员的角度来说,可以这样理解happens-before关系:如果A happens-before B,那么Java内存模型将向程序员保证——A操作的结果将对B可见,且A的执行顺序排在B之前。注意,这只是Java内存模型向程序员做出的保证!


上面的2)是JMM对编译器和处理器重排序的约束原则。 正如前面所言,JMM其实是在遵循一个基本原则:只要不改变程序的执行结果(指的是单线程程序和正确同步的多线程程序)编译器和处理器怎么优化都行。JMM这么做的原因是:程序员对于这两个操作是否真的被重排序并不关心,程序员关心的是程序执行时的语义不能被改变(即执行结果不能被改变)。因此,happens-before关系本质上和as-if-serial语义是一回事。


happens- before 的定义很微妙,后面会具体说说 happens-before 为什么要这么定义。


happens-before 与 JMM 的关系如下图所示:


image.png


如上图所示,一个 happens-before 规则对应于一个或多个编译器和处理器重排序 规则;


JMM的设计分为两部分:


一部分是面向我们程序员提供的,也就是happens-before规则,它通俗易懂的向我们程序员阐述了一个强内存模型,我们只要理解 happens-before规则,就可以编写并发安全的程序了。


另一部分是针对JVM实现的,为了尽可能少的对编译器和处理器做约束,从而提高性能,JMM在不影响程序执行结果的前提下对其不做要求,即允许优化重排序。 我们只需要关注前者就好了,也就是理解happens-before规则。毕竟我们是做程序员的,术业有专攻,能写出安全的并发程序就好了。


对于 java 程序员来说,happens-before 规则简单易懂,它避免 java 程序员为了理解 JMM 提供的内存可见性保证而去学习复杂的重排序规则以及这些规则的具体实现;


结束语


  • 由于博主才疏学浅,难免会有纰漏,假如你发现了错误或偏见的地方,还望留言给我指出来,我会对其加以修正。
  • 如果你觉得文章还不错,你的转发、分享、点赞、留言就是对我最大的鼓励。
  • 感谢您的阅读,十分欢迎并感谢您的关注。


目录
相关文章
|
4天前
|
安全 Java 程序员
深入理解Java内存模型与并发编程####
本文旨在探讨Java内存模型(JMM)的复杂性及其对并发编程的影响,不同于传统的摘要形式,本文将以一个实际案例为引子,逐步揭示JMM的核心概念,包括原子性、可见性、有序性,以及这些特性在多线程环境下的具体表现。通过对比分析不同并发工具类的应用,如synchronized、volatile关键字、Lock接口及其实现等,本文将展示如何在实践中有效利用JMM来设计高效且安全的并发程序。最后,还将简要介绍Java 8及更高版本中引入的新特性,如StampedLock,以及它们如何进一步优化多线程编程模型。 ####
12 0
|
1月前
|
存储 Java 编译器
Java内存模型(JMM)深度解析####
本文深入探讨了Java内存模型(JMM)的工作原理,旨在帮助开发者理解多线程环境下并发编程的挑战与解决方案。通过剖析JVM如何管理线程间的数据可见性、原子性和有序性问题,本文将揭示synchronized关键字背后的机制,并介绍volatile关键字和final关键字在保证变量同步与不可变性方面的作用。同时,文章还将讨论现代Java并发工具类如java.util.concurrent包中的核心组件,以及它们如何简化高效并发程序的设计。无论你是初学者还是有经验的开发者,本文都将为你提供宝贵的见解,助你在Java并发编程领域更进一步。 ####
|
2月前
|
缓存 easyexcel Java
Java EasyExcel 导出报内存溢出如何解决
大家好,我是V哥。使用EasyExcel进行大数据量导出时容易导致内存溢出,特别是在导出百万级别的数据时。以下是V哥整理的解决该问题的一些常见方法,包括分批写入、设置合适的JVM内存、减少数据对象的复杂性、关闭自动列宽设置、使用Stream导出以及选择合适的数据导出工具。此外,还介绍了使用Apache POI的SXSSFWorkbook实现百万级别数据量的导出案例,帮助大家更好地应对大数据导出的挑战。欢迎一起讨论!
186 1
|
6天前
|
存储 监控 算法
Java内存管理深度剖析:从垃圾收集到内存泄漏的全面指南####
本文深入探讨了Java虚拟机(JVM)中的内存管理机制,特别是垃圾收集(GC)的工作原理及其调优策略。不同于传统的摘要概述,本文将通过实际案例分析,揭示内存泄漏的根源与预防措施,为开发者提供实战中的优化建议,旨在帮助读者构建高效、稳定的Java应用。 ####
20 8
|
12天前
|
Java
java内存区域
1)栈内存:保存所有的对象名称 2)堆内存:保存每个对象的具体属性 3)全局数据区:保存static类型的属性 4)全局代码区:保存所有的方法定义
19 1
|
26天前
|
缓存 算法 Java
本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制
在现代软件开发中,性能优化至关重要。本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制。通过调整垃圾回收器参数、优化堆大小与布局、使用对象池和缓存技术,开发者可显著提升应用性能和稳定性。
45 6
|
3天前
|
存储 监控 算法
Java内存管理的艺术:深入理解垃圾回收机制####
本文将引领读者探索Java虚拟机(JVM)中垃圾回收的奥秘,解析其背后的算法原理,通过实例揭示调优策略,旨在提升Java开发者对内存管理能力的认知,优化应用程序性能。 ####
17 0
|
1月前
|
存储 缓存 安全
Java内存模型(JMM):深入理解并发编程的基石####
【10月更文挑战第29天】 本文作为一篇技术性文章,旨在深入探讨Java内存模型(JMM)的核心概念、工作原理及其在并发编程中的应用。我们将从JMM的基本定义出发,逐步剖析其如何通过happens-before原则、volatile关键字、synchronized关键字等机制,解决多线程环境下的数据可见性、原子性和有序性问题。不同于常规摘要的简述方式,本摘要将直接概述文章的核心内容,为读者提供一个清晰的学习路径。 ####
39 2
|
1月前
|
存储 安全 Java
什么是 Java 的内存模型?
Java内存模型(Java Memory Model, JMM)是Java虚拟机(JVM)规范的一部分,它定义了一套规则,用于指导Java程序中变量的访问和内存交互方式。
64 1
|
1月前
|
存储 运维 Java
💻Java零基础:深入了解Java内存机制
【10月更文挑战第18天】本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
34 1