Java内存模型相关原则详解

简介: Java内存模型相关原则详解

在《Java内存模型(JMM)详解》一文中我们已经讲到了Java内存模型的基本结构以及相关操作和规则。而Java内存模型又是围绕着在并发过程中如何处理原子性、可见性以及有序性这三个特征来构建的。本篇文章就带大家了解一下相关概念、原则等内容。

原子性

原子性即一个操作或一系列是不可中断的。即使是在多个线程的情况下,操作一旦开始,就不会被其他线程干扰。

比如,对于一个静态变量int x两条线程同时对其赋值,线程A赋值为1,而线程B赋值为2,不管线程如何运行,最终x的值要么是1,要么是2,线程A和线程B间的操作是没有干扰的,这就是原子性操作,不可被中断的。

Java内存模型对以下操作保证其原子性:read,load,assign,use,store,write。我们可以大致认为基本数据类型的访问读写是具备原子性的(前面也提到了long和double类型的“半个变量”情况,不过几乎不会发生)。

从Java内存模型底层来看有上面的原子性操作,但针对用户来说,也就是我们编写Java的程序,如果需要更大范围的原子性保障,就需要同步关键字——synchronized来保障了。也就是说synchronized中的操作也具有原子性。

可见性

可见性是指当一个线程修改了共享变量的值,其他线程能够立即得知这个修改。

Java内存模型是通过变量修改后将新值同步回主内存,在变量读取前从主内存刷新变量值,将主内存作为传递媒介。可回顾一下上篇文章的图。image.png无论普通变量还是volatile变量都是如此,只不过volatile变量保证新值能够立马同步到主内存,使用时也立即从主内存刷新,保证了多线程操作时变量的可见性。而普通变量不能够保证。

除了volatile,synchronized和final也能够实现可见性。

synchronized实现的可见性是通过“对一个变量执行unlock操作之前,必须先把此变量同步回主内存中”来保证的。

主要有两个原则:线程解锁前,必须把共享变量的最新值刷新到主内存中;线程加锁时,将清空工作内存中共享变量的值,从而使用共享变量时需要从主内存中重新读取最新的值。

final的可见性是指:被final修饰的字段在构造器中一旦初始化完成,并且构造器没有把“this”的引用传递出去,那在其他线程中就能看见final的值。

有序性

在Java内存模型中有序性可归纳为这样一句话:如果在本线程内观察,所有操作都是有序的,如果在一个线程中观察另一个线程,所有操作都是无序的。

有序性是指对于单线程的执行代码,执行是按顺序依次进行的。但在多线程环境中,则可能出现乱序现象,因为在编译过程会出现“指令重排”,重排后的指令与原指令的顺序未必一致。

因此,上面归纳的前半句指的是线程内保证串行语义执行,后半句则指指“令重排现”象和“工作内存与主内存同步延迟”现象。

同样,Java语言提供了volatile和synchronized两个关键字来保证线程之间操作的有序性。

指令重排

计算机执行指令经过编译之后形成指令序列。一般情况,指令序列是会输出确定的结果,且每一次的执行都有确定的结果。

CPU和编译器为了提升程序执行的效率,会按照一定的规则允许进行指令优化。但代码逻辑之间是存在一定的先后顺序,并发执行时按照不同的执行逻辑会得到不同的结果。

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

举个例来说明一下多线程中可能出现的重排现象:

class ReOrderDemo {
    int a = 0;
    boolean flag = false;
    public void write() {
        a = 1;                   //1
        flag = true;             //2
    }
    public void read() {
        if (flag) {                //3
            int i =  a * a;        //4
            ……
        }
    }
}

在上面的代码中,单线程执行时,read方法能够获得flag的值进行判断,获得预期结果。但在多线程的情况下就可能出现不同的结果。

比如,当线程A进行write操作时,由于指令重排,write方法中的代码执行顺序可能会变成下面这样:

flag = true;             //2
a = 1;                   //1

也就是说可能会先对flag赋值,然后再对a赋值。这在单线程中并不影响最终输出的结果。

但如果与此同时,B线程在调用read方法,那么就有可能出现flag为true但a还是0,这时进入第4步操作的结果就为0,而不是预期的1了。

请记住,指令重排只会保证单线程中串行语义执行的一致性,不会关心多线程间语义的一致性。这也是为什么在写单例模式时需要考虑添加volatile关键词来修饰,就是为了防止指令重排导致的问题。

JMM提供的解决方案

在了解了原子性、可见性以及有序性问题后,看看JMM是提供了什么机制来保证这些特性的。

原子性问题,除了JVM自身提供的对基本数据类型读写操作的原子性外,对于方法级别或者代码块级别的原子性操作,可以使用synchronized关键字或者重入锁(ReentrantLock)保证程序执行的原子性。

而工作内存与主内存同步延迟现象导致的可见性问题,可以使用synchronized关键字或者volatile关键字解决。它们都可以使一个线程修改后的变量立即对其他线程可见。

对于指令重排导致的可见性问题和有序性问题,则可以利用volatile关键字解决。volatile的另一个作用就是禁止重排序优化。

除了靠sychronized和volatile关键字之外,JMM内部还定义一套happens-before(先行发生)原则来保证多线程环境下两个操作间的原子性、可见性以及有序性。

先行发生原则

如果仅靠sychronized和volatile关键字来保证原子性、可见性以及有序性,那么编写并发程序会十分麻烦。为此在Java内存模型中,还提供了happens-before原则来辅助保证程序执行的原子性、可见性以及有序性的问题。该原则是判断数据是否存在竞争、线程是否安全的依据。

happens-before规则:

  • 程序次序规则:在一个线程内,程序前面的操作先于后面的操作。
  • 监视器锁规则:一个unlock操作先于后面对同一个锁的lock操作发生。
  • volatile变量规则:对一个volatile变量的写操作先行发生于后面对这个变量的读操作,也就是说读取的值肯定是最新的。
  • 线程启动规则:Thread对象的start()方法调用先行发生于此线程的每一个动作。
  • 线程加入规则:Thread对象的结束先行发生于join()方法返回。
  • 线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生,可以通过interrupted()方法检测到是否有中断发生。
  • 对象终结规则:一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始。
  • 传递性:如果操作A先行发生于操作B,操作B先行发生于操作C,那么操作A先行发生于操作C。

还拿上面的具体代码来进行说明:

class ReOrderDemo {
    int a = 0;
    boolean flag = false;
    public void write() {
        a = 1;                   //1
        flag = true;             //2
    }
    public void read() {
        if (flag) {                //3
            int i =  a * a;        //4
            ……
        }
    }
}

线程A调用write()方法,线程B调用read()方法,线程A先(时间上的先后)于线程B启动,那么线程B读取到a的值是多少呢?

现在依据8条原则来进行对照。

两个方法分别由线程A和线程B调用,不在同一个线程中,因此程序次序原则不适用。

没有write()方法和read()方法都没有使用同步手段,监视器锁规则不适用。

没有使用volatile关键字,volatile变量原则不适用。

与线程启动、终止、中断、对象终结规则、传递性都没有关系,不适用。

因此,线程A和线程B的启动时间虽然有先后,但线程B执行结果却是不确定,也是说上述代码没有适合8条原则中的任意一条,所以线程B读取的值自然也是不确定的,换句话说就是线程不安全的。

修复这个问题的方式很简单,要么给write()方法和read()方法添加同步手段,如synchronized。或者给变量flag添加volatile关键字,确保线程A修改的值对线程B总是可见。

小结

在这篇文章中介绍了Java内存模型中一些原则,其衍生出来保证这些原则的方式和方法。也是为我们下面学习volatile这个面试官最爱问的关键字的做好铺垫。欢迎关注微信公众号“程序新视界”继续学习。

目录
相关文章
|
17天前
|
存储 Java 编译器
Java内存模型(JMM)深度解析####
本文深入探讨了Java内存模型(JMM)的工作原理,旨在帮助开发者理解多线程环境下并发编程的挑战与解决方案。通过剖析JVM如何管理线程间的数据可见性、原子性和有序性问题,本文将揭示synchronized关键字背后的机制,并介绍volatile关键字和final关键字在保证变量同步与不可变性方面的作用。同时,文章还将讨论现代Java并发工具类如java.util.concurrent包中的核心组件,以及它们如何简化高效并发程序的设计。无论你是初学者还是有经验的开发者,本文都将为你提供宝贵的见解,助你在Java并发编程领域更进一步。 ####
|
28天前
|
缓存 easyexcel Java
Java EasyExcel 导出报内存溢出如何解决
大家好,我是V哥。使用EasyExcel进行大数据量导出时容易导致内存溢出,特别是在导出百万级别的数据时。以下是V哥整理的解决该问题的一些常见方法,包括分批写入、设置合适的JVM内存、减少数据对象的复杂性、关闭自动列宽设置、使用Stream导出以及选择合适的数据导出工具。此外,还介绍了使用Apache POI的SXSSFWorkbook实现百万级别数据量的导出案例,帮助大家更好地应对大数据导出的挑战。欢迎一起讨论!
147 1
|
12天前
|
缓存 算法 Java
本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制
在现代软件开发中,性能优化至关重要。本文聚焦于Java内存管理与调优,介绍Java内存模型、内存泄漏检测与预防、高效字符串拼接、数据结构优化及垃圾回收机制。通过调整垃圾回收器参数、优化堆大小与布局、使用对象池和缓存技术,开发者可显著提升应用性能和稳定性。
34 6
|
16天前
|
存储 缓存 安全
Java内存模型(JMM):深入理解并发编程的基石####
【10月更文挑战第29天】 本文作为一篇技术性文章,旨在深入探讨Java内存模型(JMM)的核心概念、工作原理及其在并发编程中的应用。我们将从JMM的基本定义出发,逐步剖析其如何通过happens-before原则、volatile关键字、synchronized关键字等机制,解决多线程环境下的数据可见性、原子性和有序性问题。不同于常规摘要的简述方式,本摘要将直接概述文章的核心内容,为读者提供一个清晰的学习路径。 ####
35 2
|
17天前
|
存储 安全 Java
什么是 Java 的内存模型?
Java内存模型(Java Memory Model, JMM)是Java虚拟机(JVM)规范的一部分,它定义了一套规则,用于指导Java程序中变量的访问和内存交互方式。
42 1
|
23天前
|
存储 运维 Java
💻Java零基础:深入了解Java内存机制
【10月更文挑战第18天】本文收录于「滚雪球学Java」专栏,专业攻坚指数级提升,希望能够助你一臂之力,帮你早日登顶实现财富自由🚀;同时,欢迎大家关注&&收藏&&订阅!持续更新中,up!up!up!!
28 1
|
26天前
|
存储 算法 Java
Java虚拟机(JVM)的内存管理与性能优化
本文深入探讨了Java虚拟机(JVM)的内存管理机制,包括堆、栈、方法区等关键区域的功能与作用。通过分析垃圾回收算法和调优策略,旨在帮助开发者理解如何有效提升Java应用的性能。文章采用通俗易懂的语言,结合具体实例,使读者能够轻松掌握复杂的内存管理概念,并应用于实际开发中。
|
1月前
|
存储 监控 算法
Java中的内存管理与垃圾回收机制解析
本文深入探讨了Java编程语言中的内存管理方式,特别是垃圾回收机制。我们将了解Java的自动内存管理是如何工作的,它如何帮助开发者避免常见的内存泄漏问题。通过分析不同垃圾回收算法(如标记-清除、复制和标记-整理)以及JVM如何选择合适的垃圾回收策略,本文旨在帮助Java开发者更好地理解和优化应用程序的性能。
|
1月前
|
缓存 安全 Java
使用 Java 内存模型解决多线程中的数据竞争问题
【10月更文挑战第11天】在 Java 多线程编程中,数据竞争是一个常见问题。通过使用 `synchronized` 关键字、`volatile` 关键字、原子类、显式锁、避免共享可变数据、合理设计数据结构、遵循线程安全原则和使用线程池等方法,可以有效解决数据竞争问题,确保程序的正确性和稳定性。
38 2
|
26天前
|
监控 安全 Java
Java Z 垃圾收集器如何彻底改变内存管理
大家好,我是V哥。今天聊聊Java的ZGC(Z Garbage Collector)。ZGC是一个低延迟垃圾收集器,专为大内存应用场景设计。其核心优势包括:极低的暂停时间(通常低于10毫秒)、支持TB级内存、使用着色指针实现高效对象管理、并发压缩和去碎片化、不分代的内存管理。适用于实时数据分析、高性能服务器和在线交易系统等场景,能显著提升应用的性能和稳定性。如何启用?只需在JVM启动参数中加入`-XX:+UseZGC`即可。
145 0