java内存模型八个操作 java内存模型jmm

转载

数据科学探索者 2023-07-18 20:14:24

文章标签 java内存模型八个操作缓存 Java 主存 文章分类 Java 后端开发

文章目录

CPU缓存模型
JMM数据原子操作
JMM缓存不一致性问题

总线加锁（性能太低）
MESI缓存一致性协议
Volatile缓存可见性实现原理
Volatile可见性、原子性与有序性

关于并发编程

线程之间的通信
线程之间的同步

Java内存模型

JVM对Java内存模型的实现
硬件内存架构
Java内存模型和硬件架构之间的桥接
共享对象的可见性
竞争现象

基础原理

指令重排序
数据依赖性
as-if-serial
内存屏障（Memory Barrier ）
happens-before

实例

Java内存模型即Java Memory Model，简称JMM。JMM定义了Java 虚拟机(JVM)在计算机内存(RAM)中的工作方式。JVM是整个计算机虚拟模型，所以JMM是隶属于JVM的。

CPU缓存模型

java内存模型八个操作 java内存模型jmm_Java

java线程模型根CPU模型类似，是基于CPU的缓存模型来建立的，java线程内存模型是标准化的，屏蔽掉了底层不同计算机的区别。

java内存模型八个操作 java内存模型jmm_java内存模型八个操作_02

JMM数据原子操作

read（读取）：从主内存读取数据
load（载入）：将主内存读取到的数据写入工作内存
use（使用）：从工作内存读取数据来计算
assign（赋值）：将计算好的值重新赋值到工作内存中
store（存储）：将工作内存数据写入主内存
write（写入）：将store过去的变量值赋值给主内存中的变量
lock（锁定）：将主内存变量加锁，标识为线程独占状态
unlocl（解锁）：将主内存变量解锁，解锁后其他线程可以锁定改变量

未加volatile

public class VolatileVisiableTest {

    private static   boolean initFlag = false;  //改了感知不到，副本本都是false
//    private static volatile  boolean initFlag = false;
    public static void main(String[] args) throws InterruptedException {
      //模拟一个线程等待
        new Thread(new Runnable() {
            @Override
            public void run() {
                System.out.println("waitting data...");
                while (!initFlag){

                }
                System.out.println("============success");
            }
        }).start();

        Thread.sleep(2000);

        //模拟一个线程等待数据
        new Thread(new Runnable() {
            @Override
            public void run() {
            prepareData();
            }
        }).start();
    }

    public static void prepareData(){
        System.out.println("preparing data ...");
        initFlag = true;
        System.out.println("preparing data end...");
    }
}

结果
waitting data...
preparing data ...
preparing data end...

java内存模型八个操作 java内存模型jmm_java内存模型八个操作_03

其中store 后已经写入在主内存还没有wite。

JMM缓存不一致性问题

总线加锁（性能太低）

java内存模型八个操作 java内存模型jmm_缓存_04

cpu从主内存读取数据到高速缓存，会在总线对这个数据加锁，这样其他cpu没法去读或写这个数据，知道这个cpu使用完数据释放锁之后其他cpu才能读取该数据。虽然解决了不同线程的可见性问题，并行执行变成串行执行，性能不行。

MESI缓存一致性协议

多个cpu从主内存读取同一个数据到各自的高速缓存，当其中某个cpu修改了缓存里的数据，该数据会马上同步回主内存，其他cpu通过总线嗅探机制可以感知到数据的变化从而将自己缓存里的数据失效。然后使用数据会重新从主内存读取。

java内存模型八个操作 java内存模型jmm_Java_05

volatile变量底层开启缓存一致性协议。

Volatile缓存可见性实现原理

底层实现主要通过汇编lock前缀指令，它会锁定折扣内存区域1的缓存（缓存行锁定）并回写到主内存。

IA-32架构软件开发者手册对lock指令的解释：

1）会将当前处理器缓存行的数据立即写回到系统内存。

2）这个写回内存的操作会引起其他CPU里缓存了改内存地址的数据无效（MESI协议）

volatile关键字在store 前加锁lock，写会主内存后unlock。

java内存模型八个操作 java内存模型jmm_java内存模型八个操作_06

Volatile可见性、原子性与有序性

并发编程三大特性：可见性，原子性，有序性。
Volatile保证可见性和有序性，但是不保证原子性，保证原子性需要借助synchronized这样的锁机制。其他并发写的时候

public class AtomicIntegerTest {

    private static final int THREADS_CONUT = 20;
    public static volatile int count = 0; //也可能<20000
//    public static AtomicInteger count = new AtomicInteger(0); //等于20000



    public static void increase() {
        count++;  //不保证原子性，某个线程count++后assign后没有拿到lock，监听总线，将工作内存count失效，丢失本次++
//        count.incrementAndGet();  //保证原子性
        System.out.println(count);
    }

    public static void main(String[] args) {
        Thread[] threads = new Thread[THREADS_CONUT];
        for (int i = 0; i < THREADS_CONUT; i++) {
            threads[i] = new Thread(new Runnable() {
                @Override
                public void run() {
                    for (int i = 0; i < 1000; i++) {
                        increase();
                    }
                }
            });
            threads[i].start();
        }
}

java内存模型八个操作 java内存模型jmm_缓存_07

关于并发编程

在并发编程领域，有两个关键问题：线程之间的通信和同步。

线程之间的通信

线程的通信是指线程之间以何种机制来交换信息。在命令式编程中，线程之间的通信机制有两种共享内存和消息传递。

在共享内存的并发模型里，线程之间共享程序的公共状态，线程之间通过写-读内存中的公共状态来隐式进行通信，典型的共享内存通信方式就是通过共享对象进行通信(全局变量)。

在消息传递的并发模型里，线程之间没有公共状态，线程之间必须通过明确的发送消息来显式进行通信，在java中典型的消息传递方式就是wait()和notify()。

线程之间的同步

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

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

Java内存模型

上面讲到了Java线程之间的通信采用的是过共享内存模型，这里提到的共享内存模型指的就是Java内存模型(简称JMM)，JMM决定一个线程对共享变量的写入何时对另一个线程可见。从抽象的角度来看，JMM定义了线程和主内存之间的抽象关系：线程之间的共享变量存储在主内存（main memory）中，每个线程都有一个私有的本地内存（local memory），本地内存中存储了该线程以读/写共享变量的副本。本地内存是JMM的一个抽象概念，并不真实存在。它涵盖了缓存，写缓冲区，寄存器以及其他的硬件和编译器优化。

java内存模型八个操作 java内存模型jmm_缓存_08

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

首先，线程A把本地内存A中更新过的共享变量刷新到主内存中去。
然后，线程B到主内存中去读取线程A之前已更新过的共享变量。
下面通过示意图来说明这两个步骤：

如上图，本地内存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程序员提供内存可见性保证。

上面也说到了，Java内存模型只是一个抽象概念，那么它在Java中具体是怎么工作的呢？为了更好的理解上Java内存模型工作方式，下面就JVM对Java内存模型的实现、硬件内存模型及它们之间的桥接做详细介绍。

JVM对Java内存模型的实现

在JVM内部，Java内存模型把内存分成了两部分：线程栈区和堆区，下图展示了Java内存模型在JVM中的逻辑视图：

java内存模型八个操作 java内存模型jmm_主存_09

JVM中运行的每个线程都拥有自己的线程栈，线程栈包含了当前线程执行的方法调用相关信息，我们也把它称作调用栈。随着代码的不断执行，调用栈会不断变化。

线程栈还包含了当前方法的所有本地变量信息。一个线程只能读取自己的线程栈，也就是说，线程中的本地变量对其它线程是不可见的。即使两个线程执行的是同一段代码，它们也会各自在自己的线程栈中创建本地变量，因此，每个线程中的本地变量都会有自己的版本。

所有原始类型(boolean,byte,short,char,int,long,float,double)的本地变量都直接保存在线程栈当中，对于它们的值各个线程之间都是独立的。对于原始类型的本地变量，一个线程可以传递一个副本给另一个线程，当它们之间是无法共享的。

堆区包含了Java应用创建的所有对象信息，不管对象是哪个线程创建的，其中的对象包括原始类型的封装类（如Byte、Integer、Long等等）。不管对象是属于一个成员变量还是方法中的本地变量，它都会被存储在堆区。

下图展示了调用栈和本地变量都存储在栈区，对象都存储在堆区：

java内存模型八个操作 java内存模型jmm_Java_10

一个本地变量如果是8大原始类型，那么它会被完全存储到栈区。

一个本地变量也有可能是一个对象的引用，这种情况下，这个本地引用会被存储到栈中，但是对象本身仍然存储在堆区。

对于一个对象的成员方法，这些方法中包含本地变量，仍需要存储在栈区，即使它们所属的对象在堆区。
对于一个对象的成员变量，不管它是原始类型还是包装类型，都会被存储到堆区。

Static类型的变量以及类本身相关信息都会随着类本身存储在堆区。

堆中的对象可以被多线程共享。如果一个线程获得一个对象的应用，它便可访问这个对象的成员变量。如果两个线程同时调用了同一个对象的同一个方法，那么这两个线程便可同时访问这个对象的成员变量，但是对于本地变量，每个线程都会拷贝一份到自己的线程栈中。

下图展示了上面描述的过程:

java内存模型八个操作 java内存模型jmm_java内存模型八个操作_11

硬件内存架构

不管是什么内存模型，最终还是运行在计算机硬件上的，所以我们有必要了解计算机硬件内存架构，下图就简单描述了当代计算机硬件内存架构：

java内存模型八个操作 java内存模型jmm_缓存_12

现代计算机一般都有2个以上CPU，而且每个CPU还有可能包含多个核心。因此，如果我们的应用是多线程的话，这些线程可能会在各个CPU核心中并行运行。

在CPU内部有一组CPU寄存器，也就是CPU的储存器。CPU操作寄存器的速度要比操作计算机主存快的多。在主存和CPU寄存器之间还存在一个CPU缓存，CPU操作CPU缓存的速度快于主存但慢于CPU寄存器。某些CPU可能有多个缓存层（一级缓存和二级缓存）。计算机的主存也称作RAM，所有的CPU都能够访问主存，而且主存比上面提到的缓存和寄存器大很多。

当一个CPU需要访问主存时，会先读取一部分主存数据到CPU缓存，进而在读取CPU缓存到寄存器。当CPU需要写数据到主存时，同样会先flush寄存器到CPU缓存，然后再在某些节点把缓存数据flush到主存。

Java内存模型和硬件架构之间的桥接

正如上面讲到的，Java内存模型和硬件内存架构并不一致。硬件内存架构中并没有区分栈和堆，从硬件上看，不管是栈还是堆，大部分数据都会存到主存中，当然一部分栈和堆的数据也有可能会存到CPU寄存器中，如下图所示，Java内存模型和计算机硬件内存架构是一个交叉关系：

java内存模型八个操作 java内存模型jmm_主存_13

当对象和变量存储到计算机的各个内存区域时，必然会面临一些问题，其中最主要的两个问题是：

共享对象对各个线程的可见性
共享对象的竞争现象

共享对象的可见性

当多个线程同时操作同一个共享对象时，如果没有合理的使用volatile和synchronization关键字，一个线程对共享对象的更新有可能导致其它线程不可见。

想象一下我们的共享对象存储在主存，一个CPU中的线程读取主存数据到CPU缓存，然后对共享对象做了更改，但CPU缓存中的更改后的对象还没有flush到主存，此时线程对共享对象的更改对其它CPU中的线程是不可见的。最终就是每个线程最终都会拷贝共享对象，而且拷贝的对象位于不同的CPU缓存中。

下图展示了上面描述的过程。左边CPU中运行的线程从主存中拷贝共享对象obj到它的CPU缓存，把对象obj的count变量改为2。但这个变更对运行在右边CPU中的线程不可见，因为这个更改还没有flush到主存中：

java内存模型八个操作 java内存模型jmm_Java_14

要解决共享对象可见性这个问题，我们可以使用java volatile关键字。 Java’s volatile keyword. volatile 关键字可以保证变量会直接从主存读取，而对变量的更新也会直接写到主存。volatile原理是基于CPU内存屏障指令实现的，后面会讲到。

竞争现象

如果多个线程共享一个对象，如果它们同时修改这个共享对象，这就产生了竞争现象。

如下图所示，线程A和线程B共享一个对象obj。假设线程A从主存读取Obj.count变量到自己的CPU缓存，同时，线程B也读取了Obj.count变量到它的CPU缓存，并且这两个线程都对Obj.count做了加1操作。此时，Obj.count加1操作被执行了两次，不过都在不同的CPU缓存中。

如果这两个加1操作是串行执行的，那么Obj.count变量便会在原始值上加2，最终主存中的Obj.count的值会是3。然而下图中两个加1操作是并行的，不管是线程A还是线程B先flush计算结果到主存，最终主存中的Obj.count只会增加1次变成2，尽管一共有两次加1操作。

java内存模型八个操作 java内存模型jmm_Java_15

要解决上面的问题我们可以使用synchronized代码块。synchronized代码块可以保证同一个时刻只能有一个线程进入代码竞争区，synchronized代码块也能保证代码块中所有变量都将会从主存中读，当线程退出代码块时，对所有变量的更新将会flush到主存，不管这些变量是不是volatile类型的。

基础原理

指令重排序

在执行程序时，为了提高性能，编译器和处理器会对指令做重排序。但是，JMM确保在不同的编译器和不同的处理器平台之上，通过插入特定类型的Memory Barrier来禁止特定类型的编译器重排序和处理器重排序，为上层提供一致的内存可见性保证。

编译器优化重排序：编译器在不改变单线程程序语义的前提下，可以重新安排语句的执行顺序。
指令级并行的重排序：如果不存在数据依赖性，处理器可以改变语句对应机器指令的执行顺序。
内存系统的重排序：处理器使用缓存和读写缓冲区，这使得加载和存储操作看上去可能是在乱序执行。

数据依赖性

如果两个操作访问同一个变量，其中一个为写操作，此时这两个操作之间存在数据依赖性。
编译器和处理器不会改变存在数据依赖性关系的两个操作的执行顺序，即不会重排序。

as-if-serial

不管怎么重排序，单线程下的执行结果不能被改变，编译器、runtime和处理器都必须遵守as-if-serial语义。

内存屏障（Memory Barrier ）

上面讲到了，通过内存屏障可以禁止特定类型处理器的重排序，从而让程序按我们预想的流程去执行。内存屏障，又称内存栅栏，是一个CPU指令，基本上它是一条这样的指令：

保证特定操作的执行顺序。
影响某些数据（或则是某条指令的执行结果）的内存可见性。
编译器和CPU能够重排序指令，保证最终相同的结果，尝试优化性能。插入一条Memory Barrier会告诉编译器和CPU：不管什么指令都不能和这条Memory Barrier指令重排序。

Memory Barrier所做的另外一件事是强制刷出各种CPU cache，如一个Write-Barrier（写入屏障）将刷出所有在Barrier之前写入 cache 的数据，因此，任何CPU上的线程都能读取到这些数据的最新版本。

这和java有什么关系？上面java内存模型中讲到的volatile是基于Memory Barrier实现的。

如果一个变量是volatile修饰的，JMM会在写入这个字段之后插进一个Write-Barrier指令，并在读这个字段之前插入一个Read-Barrier指令。这意味着，如果写入一个volatile变量，就可以保证：

一个线程写入变量a后，任何线程访问该变量都会拿到最新值。
在写入变量a之前的写入操作，其更新的数据对于其他线程也是可见的。因为Memory Barrier会刷出cache中的所有先前的写入。

happens-before

从jdk5开始，java使用新的JSR-133内存模型，基于happens-before的概念来阐述操作之间的内存可见性。

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

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

程序顺序规则：一个线程中的每个操作，happens-before于该线程中任意的后续操作。
监视器锁规则：对一个锁的解锁操作，happens-before于随后对这个锁的加锁操作。
volatile域规则：对一个volatile域的写操作，happens-before于任意线程后续对这个volatile域的读。
传递性规则：如果 A happens-before B，且 B happens-before C，那么A happens-before C。
注意：两个操作之间具有happens-before关系，并不意味前一个操作必须要在后一个操作之前执行！仅仅要求前一个操作的执行结果，对于后一个操作是可见的，且前一个操作按顺序排在后一个操作之前。

实例

不同的CPU可能采用不同的架构，而这样的问题在多核处理器和多处理器系统中变得尤其复杂。而Java的目标是要实现“编写一次，到处运行”，因此就有必要对Java程序访问和操作主存的方式做出规范，以保证同样的程序在不同的CPU架构上的运行结果是一致的。Java内存模型（Java Memory Model）就是为了这个目的而引入的。JSR 133则进一步修正了之前的内存模型中存在的问题。总得来说，Java内存模型描述了程序中共享变量的关系以及在主存中写入和读取这些变量值的底层细节。Java内存模型定义了Java语言中的synchronized、volatile和final等关键词对主存中变量读写操作的意义。Java开发人员使用这些关键词来描述程序所期望的行为，而编译器和JVM负责保证生成的代码在运行时刻的行为符合内存模型的描述。比如对声明为volatile的变量来说，在读取之前，JVM会确保CPU中缓存的值首先会失效，重新从主存中进行读取；而写入之后，新的值会被马上写入到主存中。而synchronized和volatile关键词也会对编译器优化时候的代码重排带来额外的限制。比如编译器不能把 synchronized块中的代码移出来。对volatile变量的读写操作是不能与其它读写操作一块重新排列的。
Java 内存模型中一个重要的概念是定义了“在之前发生（happens-before）”的顺序。如果一个动作按照“在之前发生”的顺序发生在另外一个动作之前，那么前一个动作的结果在多线程的情况下对于后一个动作就是肯定可见的。最常见的“在之前发生”的顺序包括：对一个对象上的监视器的解锁操作肯定发生在下一个对同一个监视器的加锁操作之前；对声明为volatile的变量的写操作肯定发生在后续的读操作之前。有了“在之前发生”顺序，多线程程序在运行时刻的行为在关键部分上就是可预测的了。编译器和JVM会确保“在之前发生”顺序可以得到保证。比如下面的一个简单的方法：

public void increase() {
    this.count++;
}

这是一个常见的计数器递增方法，this.count++实际是this.count = this.count + 1，由一个对变量this.count的读取操作和写入操作组成。如果在多线程情况下，两个线程执行这两个操作的顺序是不可预期的。如果 this.count的初始值是1，两个线程可能都读到了为1的值，然后先后把this.count的值设为2，从而产生错误。错误的原因在于其中一个线程对this.count的写入操作对另外一个线程是不可见的，另外一个线程不知道this.count的值已经发生了变化。如果在increase() 方法声明中加上synchronized关键词，那就在两个线程的操作之间强制定义了一个“在之前发生”顺序。一个线程需要首先获得当前对象上的锁才能执行，在它拥有锁的这段时间完成对this.count的写入操作。而另一个线程只有在当前线程释放了锁之后才能执行。这样的话，就保证了两个线程对 increase()方法的调用只能依次完成，保证了线程之间操作上的可见性。

参考：

http://www.360doc.com/content/14/0521/11/7385274_379575711.shtml

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。