Java并发 - JMM 内存模型

左手的ㄟ右手 2022-09-07 05:49 265阅读 0赞

## 一、CPU缓存 ##

### 1、CPU性能优化手段 - 缓存 ###

为了提高程序运行的性能，现代CPU在很多方面对程序进行了优化。例如：CPU高速缓存。尽可能的避免处理器访问主存的时间开销，处理器大多会利用缓存来提高性能。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70]

**多级缓存**

CPU的缓存分为三个级别，离CPU越远等级越大：

*  L1 Cache(一级缓存)是CPU第一层高速缓存，分为**数据缓存**和**指令缓存**。一般服务器CPU的L1缓存容量通常在 32-4096KB（实在是太小了）。
 *  L2 Cache(二级缓存) 由于L1级高速缓存容量的限制，为了再次提高CPU的运算速度，在CPU外部放置一个高速存储器（由于在外部，有延迟导致速度还是不够快）。
 *  L3 现在的都是内置的。L3缓存的应用可以进一步降低内存延迟，同时提升大数据量计算时的处理器性能。具有较大L3缓存的处理器提供更有效的文件系统缓存行为，及较短消息和处理器队列长度。一般是多核共享一个L3缓存。

**缓存的同步协议**

多CPU读取同样的数据进行缓存，进行不同的运算之后，最终写入主内存，那么以哪个CPU为准？

这些 CPU 厂商就制定了一个缓存一致性的协议，就是 MESI协议，规定每条缓存有一个状态位，同时定义了四个状态：

*  修改态(Modified) ：此cache行已被修改过(脏行)，内容已不同于主存，为此cache专有
 *  专有态(Exclusive)：此cache行内容同于主存，但不出现于其他cache中；
 *  共享态(Shared)：此cache行内容同于主存，但也出现于其他cache中；
 *  无效态(Invalid)：此cache行内容无效(空行)；

多处理器时，单个CPU对缓存中数据进行了改动，需通知给其他CPU。也就是说，CPU处理要控制自己的读写操作，还要监听其他CPU发出的通知，从而保证数据的**最终一致**。

缓存中的数据与主存的数据并不是实时同步的，各CPU核心间的缓存数据也不是实时同步的。在同一时间点，各个CPU所看到同一内存地址的数据可能是不一致的，就会存在线程安全问题。

### 2、CPU性能优化手段 - 运行时指令重排 ###

指令重排：当CPU**写缓存时**发现缓存区块正被其他CPU占用，为了提高CPU处理性能，可能将后面的**读缓存命令优先执行**。例如：

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 1]

**重排需要遵循 as-if-serial 语义**：不管怎么重排序(编译器和处理器为了提高并行度)，(单线程)程序的执行结果不能被改变。编译器，runtime 和处理器都必须遵守 as-if-serial 语义。也就是说：编译器和处理器**不会对存在数据依赖关系的操作做重排序**。

`as-if-serial语义`把单线程程序保护了起来，换句话说：`as-if-serial语义`仅在单CPU单线程的情况下能保证结果正确。多核多线程中，指令逻辑无法分辨因果关系，可能会出现**乱序执行**，导致程序运行结果错误，就会存在线程安全问题。

## 二、内存屏障 ##

不论是缓存同步还是指令重排，都是线程不安全的。

处理器提供了两个内存屏障指令(Memory Barrier)用于解决缓存同步和指令重排的问题。

*  读内存屏障(Load Memory Barrier)：在指令前插入Load Barrier，可以让高速缓存中的数据失效，强制重新从主内存加载数据。强制读取主内存内容，让CPU缓存与主内存保持一致，避免了缓存导致的一致性问题。
 *  写内存屏障(Store Memory Barrier)：在指令后插入Store Barrier，能让写入缓存中的最新数据更新写入主内存，让其他线程可见。强制写入主内存，这种显示调用，CPU就不会因为性能考虑而去对指令重排。

## 三、JMM 内存模型 ##

首先，先要了解JVM分区的概念。在JVM中堆（heap）和方法区是线程共享区域，虚拟机栈、本地方法栈和程序计数器是线程独占部分。虚拟机栈中有多个线程，每个线程对应一个栈帧，每个栈帧中存放有局部变量表、操作数栈、方法返回地址等。线程与线程之间是不能够直接建立沟通的，需要借助于共享区域才来建立沟通。

内存模型的含义：Java编程语言内存模型通过检查执行跟踪中的每个读操作，并根据某些规则检查该读操作观察到的写操作是否有效来工作。只要程序的所有执行产生的结果都可以由内存模型预测。具体的实现者任意实现，包括操作的重新排序和删除不必要的同步。

JMM 内存模型是一种虚拟机的规范，描述程序的可能行为。

1、线程解锁前，必须把共享变量立刻刷回主存。

2、线程加锁前，必须读取主存中的最新值到工作内存中。

3、加锁和解锁是同一把锁。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 2]

线程A从主存中读到值flag=true，加载到自己的工作内存中，由执行引擎处理后将值再赋值给工作内存，写入存储过程（存储过程就是把store操作从工作内存中得到的变量放入主存中的操作）。

lock 作用于主内存的变量，把一个变量标识为线程独占状态，unlock 也是作用于主内存的变量，将被锁定的变量释放出来，释放后才能被其它线程锁定。

问题：Java 内存模型中存在多线程操作变量时，变量被其中一个线程修改后，不能实时修改其它线程正在使用该变量的值，如下例：

public static int n = 0;
    public void test() throws InterruptedException { 
        new Thread(() -> { 
            while (n == 0) { 
            }
        }, "A").start();
    	
        // 休眠 1s 后修改n=1，能否停止线程A？
        Thread.sleep(1000);
        n = 1;
        System.out.println("线程停止了吗？");
    }

分析：线程A从主内存中读取到n=0，加载到自己的工作内存，一秒钟后，main线程把n的值改为1后写回主内存，此时A还没有拿到最新的值。所以线程A是不会停止执行的。

解决：当主存中的值发生修改后，应该通知所有操作主存变量的线程。可以使用 volatile 关键字来解决这个问题。

下面对这个问题进行深入分析：

## 线程的可见性问题 ##

缓存引起的可见性问题。当主存中的data发生改变后，其他线程栈中的使用的 data 是不能够及时修改的。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 3]  
指令重排序引起的可见性问题。在Java层面，指令重排序不能够通过 javap 查看出class文件中的重排序，而是发生在运行时的编译器（JIT - Just In Time），将字节码进行重排序编译机器语言（汇编）。

什么是Just In Time编译器?
    Java程序一开始是通过解释器（Interpreter）进行解释执行的。当JVM发现某个方法或代码块运行特别频繁时，就会把这些代码认定为“热点代码（Hot Spot Code）”，然后JVM会把这些代码编译成与本地平台相关的机器码，并进行各种层次的优化，完成这个任务的编译器称为：即时编译器（Just In Time Compiler，JIT）。
    JIT编译器是“动态编译器”的一种，相对的“静态编译器”则是指的比如：C/C++的编译器。
    注意：
    JIT并不是JVM的必须部分，JVM规范并没有规定JIT必须存在，更没有限定和指导JIT。但是，JIT性能的好坏、代码优化程度的高低却是衡量一款JVM是否优秀的最关键指标之一，也是虚拟机中最核心且最能体现虚拟机技术水平的部分。

还可能发生等效替换。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 4]  
将上面这些代码java.exe 编译成class字节码加载到JVM之后，通过运行时编译器JIT将class字节码转成汇编指令后进行重排序或等效替换。

在运行时，JVM会根据代码的调用情况进行判断：如果 n=0，那么while(n0) 就相当于是一个死循环成为热点代码，那么JIT就会认为可以执行成为 if(n0)\{while(true)\{\}\} 这样的优化，就不会再回去读取 n 的值，相当于执行了一次Java层面的重排序。

// 刚开始int n = 0;
    while (n == 0) { }  被JIT编译器指令重排序为 if(n==0){ while(true){ }}

如果代码改为加锁的方式，虚拟机对于这种关键的代码段是不会进行优化处理的。

new Thread(() -> { 
        while (n == 0) { 
            synchronized(this){ 
                add();
            }
        }
    }, "A").start();

## 线程操作的定义 ##

write要写的变量以及要写的值。  
read要读的变量以及可见的写入值(由此，我们可以确定可见的值)。  
lock要锁定的管程(监视器monitor)。  
unlock要解锁的管程。  
外部操作(socket等等…)  
启动和终止

（线程间）程序顺序：如果一个程序没有数据竞争，那么程序的所有执行看起来都是顺序一致的。

## happen—before 先行发生原则 ##

happen-before是JMM最核心的概念之一。在JMM中如果一个操作的结果需要对另一个线程可见，那么这两个操作之间必须 要存在happens-before规则。

规则内容：

1、程序次序原则：一个线程内，按照程序代码顺序，书写在前面的操作先行发生与书写在后面的操作。

2、监视器锁规则：一个unlock操作先行发生与后面对同一个锁的lock操作者，这里必须指同一个锁，后面指的是时间上的先后顺序。

3、volatile变量规则：对一个volatile变量的写操作先行发生于后面对这个变量的读操作，这里的后面同样指时间上的先后顺序。

4、线程启动规则：Thread 对象的 start() 方法先行发生于此线程的任意动作。

5、线程终止规则：线程中的所有操作都先行发生于对此线程的终止检测，我们可以通过thread.join方法结束，thread.isAlive的返回值等手段检测到线程已经终止执行。

6、线程中断原则：对线程interrupt方法的调用先行发生于被中断线程的代码监测到中断时间的发生，可以通过interrupt方法检测到是否又中断发生。

7、对象终结规则：一个对象的初始化完成，先行发生于它的finalize方法的开始。

8、传递性：如果A先行发生于B，B先行发生于C，则A先行发生于C。

## final 在JMM中的处理 ##

在下面这个实例中，在read() 方法中，一个变量加了final修饰，一个没加，在多线程的情况下未加final修饰符变量的值，有可能为0，不保证值为构造函数中的赋值。

class A { 
        final int x;
        int y;
        static A a;
        
        public A() { 
            x=3;
            y=4;
        }
        
        static void write(){ 
            a = new A();
        }
       
        static void read(){ 
            if(f!=null){ 
                int i = a.x; // 肯定是3
                int j = a.y; // 可能是0
            }
        }
    }

读取该共享对象的final成员变量之前，先要读取共享的对象。伪代码示例：r = bew A()；k = r.a 这两个操作不能重排序。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70]: /images/20220829/c6680e5790c14ea2b2c2bfade7de1010.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 1]: /images/20220829/f6de0603a2a441e6a0caf25ba9056e93.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 2]: /images/20220829/ada98ffdcb3247b5a473a45f72ce8fc4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 3]: /images/20220829/366779bdc66b4f70a51833d947acc750.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQxNjQ3OTk5_size_16_color_FFFFFF_t_70 4]: /images/20220829/640cbc2d6c46419b85bc7194beec17b9.png