[JUC第四天]Java内存模型基础知识

偏执的太偏执、 2023-07-12 09:00 37阅读 0赞

### 文章目录 ###

*  Java内存模型概述
 *   *  JMM是什么
     *  JMM抽象结构
 *  JMM缓存一致性
 *   *  不一致问题
     *  MESI
 *  8个原子操作
 *   *  基本概念
     *  执行规则
 *  重排序
 *   *  重排序分类
     *  数据依赖性
 *  内存屏障
 *   *  内存屏障分类
     *  volatile和内存屏障
     *  Happens-Before

# Java内存模型概述 #

## JMM是什么 ##

首先区分量名词：`爪哇内存分区`和`爪哇内存模型`

爪哇内存分区是指的这个：

![image-20200307151909602][]

爪哇内存模型是指的这个：

![image-20200307152142382][]

现在进入正题：

爪哇内存模型，即`Java Memory Model`（JMM），属于语言级内存模型，指的是用爪哇语言抽象出来的一套对内存的管理机制，因为爪哇的虚拟机是跨平台跑的，对于各种不同的操作系统，都需要抽象出一套统一的规范，来屏蔽底层的不同，使得爪哇程序对内存的操作也能跨平台

JMM负责了各种变量在虚拟机中的储存管理，变量的可见性就是由JMM决定的，同时JMM也要负责线程通信，JMM的线程之间的通讯是采用的`共享内存`的方式来实现的…可以简单理解成，你CPU有对不同进程有自己的内存缓存管理方式，对于我爪哇JVM而言，我这个进程内部也有自己方式来管理我的线程

而JMM的设计的抽象的工作结构，大概是下面这个样子的：

## JMM抽象结构 ##

在JMM中，有两个概念：`工作内存`和`主内存`

主内存里存放了一些共享变量（就是JVM分区里Heap堆里放的那些东西）

每个线程有自己独自的工作内存，包含了自己的运行时栈，还有对主内存中共享变量的拷贝

![image-20200307152839200][]

工作内存每次需要操作共享变量的时候，并不是从主内存中取了然后直接进行操作，而是先拷贝一份然后放到自己的工作内存空间中，对这个拷贝的变量来进行操作然后再做写回操作

这个操作自然而然就让人想起了CPU的缓存设计：

![image-20200303205119392][]

其实JMM的设计就是照着缓存设计来的：

![image-20200307153834061][]

所以，对于JMM来说，他也就会存在缓存不一致的问题了

# JMM缓存一致性 #

## 不一致问题 ##

看这样一段代码：

/**
     * @author Lehr
     * @create: 2020-03-06
     */
    public class WorkingMemory {
        
    
        private static Boolean flag = false;
    
        public static void main(String[] args) {
        
    
            new Thread(()->{
        
               while(!flag){
        };
                System.out.println("我跳出了循环！");
            }).start();
    
            new Thread(()->{
        
                System.out.println("我现在看到的flag是："+flag);
                System.out.println("我要开始修改了");
                flag = true;
                System.out.println("我好了");
                System.out.println("我现在看到的flag是："+flag);
            }).start();
    
    
        }
    }

运行这段代码，则输出的情况（多半）是这样：

![image-20200307154648973][]

注意看左边的运行状态，程序依然在运行，但是第一个程序始终没有跳出循环，说明他看到的flag还是false

这就可以用我们上面说过的JMM的模型来解释了：

![image-20200307154918647][]

一开始的时候，对于两个线程而言，他们都会把flag=false拷贝到自己的工作内存中

![image-20200307155152471][]

然而后来，线程2修改了自己工作内存中的副本值，并写回到主内存，可是对于线程1来说，暂时没有情况触发他刷新自己的拷贝副本，所以他一直以为flag的值还是false，所以他会一直进行while循环

## MESI ##

为了解决上面的问题，我们可以使用`volatile`关键字来修饰（用AtomicBoolean也可以，但是他底层还不是用`volatile`来做的）

volatile修饰变量的可见性是通过MESI协议实现的，MESI是一个基于失效的缓存一致性协议，是支持回写（write-back）缓存的最常用协议，大概就是，共享变量会有一个有效位标记，如果这个标记变了，则工作线程里的副本也作废了（以后研究研究再细讲）

![image-20200307160437442][]

由于volatile关键字具有特殊的内存语义，所以在使用volatile关键词的时候，会触发CPU总线嗅探机制，强制使得其他工作内存的变量失效，迫使他们不得不去主内存获取最新的值，从而保证了共享变量的可见性(具体内容后续volatile内存语义的博客会讲到)

# 8个原子操作 #

## 基本概念 ##

为了完成内存交换的操作过程，Java中定义了8个原子操作和一系列规范

8个原子操作如下：

<table> 
 <thead> 
  <tr> 
   <th align="center">名称</th> 
   <th align="center">用途</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td align="center">read</td> 
   <td align="center">把一个变量从<code>主内存</code>传送到<code>工作内存</code></td> 
  </tr> 
  <tr> 
   <td align="center">load</td> 
   <td align="center">把read得到的值放入工作内存的变量副本中</td> 
  </tr> 
  <tr> 
   <td align="center">use</td> 
   <td align="center">从工作内存变量副本中取出来操作</td> 
  </tr> 
  <tr> 
   <td align="center">assign</td> 
   <td align="center">把操作好了的值再赋值给副本</td> 
  </tr> 
  <tr> 
   <td align="center">store</td> 
   <td align="center">把副本的值存回到工作内存</td> 
  </tr> 
  <tr> 
   <td align="center">write</td> 
   <td align="center">把刚刚存回的值写到之前那个变量中</td> 
  </tr> 
  <tr> 
   <td align="center">lock</td> 
   <td align="center">把主内存中的某个变量锁了，不解释</td> 
  </tr> 
  <tr> 
   <td align="center">unlock</td> 
   <td align="center">解锁，不解释</td> 
  </tr> 
 </tbody> 
</table>

光看这个可能有点懵，所以我结合上面那个不一致问题中的流程画一下整个过程（lock不讲）：

![image-20200307162433423][]

*  第一步，read操作，把变量flag的值取到线程2的工作内存中
 *  第二步，load操作，把之前取到的false这个值放入到自己的flag变量副本中去
 *  第三步，use操作，拿去给执行引擎执行
 *  第四步，assign操作，把执行后的结果赋值给自己的副本变量
 *  第五步，store操作，把副本的值false保存回主内存
 *  第六步，write操作，把这个false写回到主内存中的flag变量，完成

## 执行规则 ##

上面这几个原子操作，很显然，有些是必须成队出现的，所以，有下面这些规则（别问问就是全背XD）：

*  把变量从主内存复制到工作内存：read+load
 *  把变量从工作内存写回到主内存：store+write
 *  发生assign操作后，就会触发写回主内存的操作
 *  没assign就不能写回去
 *  一个新变量只能在主内存中诞生，对一个变量进行,use,store操作之前，必然已经执行过assign,load操作
 *  一个变量同一时刻只能被一个线程lock，并且可以重复lock多次，多次lock之后，只有执行相同次数的unlock操作，线程才会释放这个变量
 *  如果对一个变量执行lock，工作内存里的变量副本就会被清空，工作内存会去重同步一份最新的
 *  对一个变量进行unlock之前必须把值同步回主内存中去
 *  JMM规定这些操作必须按时间顺序执行，但是并不一定是连续执行，比如我这里有3个参数a，b，c，我可以这样执行：
    
    > read a read b load a read c load c load b

# 重排序 #

编译器和处理器为了提高性能，会对指令做重排序，重排序分为了三种类型

## 重排序分类 ##

1.  编译器优化重排序：发生在编译过程中
2.  指令级并行重排序：现代处理器采用了指令级并行技术，可以把没有存在依赖关系的指令重叠执行，
3.  内存系统的重排序：由于处理器会采用读写缓冲区，所以加载和储存操作可能看起来就是乱序执行的

![image-20200307164344656][]

## 数据依赖性 ##

如果这几行代码换个顺序执行也没有关系，他们之间没有数据依赖性的话，就有可能被重排序，看下面这个例子：

public class OutofOrderExecution {
        
        private static int x = 0, y = 0;
        private static int a = 0, b = 0;
        
            public static void main(String[] args)
                throws InterruptedException {
        
            Thread t1 = new Thread(new Runnable() {
        
                public void run() {
        
                    a = 1;
                    x = b;
                }
            });
            Thread t2 = new Thread(new Runnable() {
        
                public void run() {
        
                    b = 1;
                    y = a;
                }
            });
            t1.start();
            t2.start();
            t1.join();
            t2.join();
            System.out.println("(" + x + "," + y + ")");
        }
    }

他的输出结果是4种情况(0,0)or(1,1)or(1,0)or(0,1)都有可能

因为每个线程里执行的两行代码都没有数据依赖性，他们有可能被重排序，比如对于`a = 1;x = b;`，换个位置变成`x = b;a = 1;`对当前线程也没有影响

下面给出书上的官话解释：

> 如果两个操作访问同一个变量，且这两个操作中有一个为写操作，此时就存在数据依赖性
> 
> 数据依赖性分为下面三种：
> 
> <table> 
>  <thead> 
>   <tr> 
>    <th>名称</th> 
>    <th>代码示例</th> 
>    <th>说明</th> 
>   </tr> 
>  </thead> 
>  <tbody> 
>   <tr> 
>    <td>写后读</td> 
>    <td>a=1；b=a；</td> 
>    <td>写一个变量，再读这个位置</td> 
>   </tr> 
>   <tr> 
>    <td>写后写</td> 
>    <td>a=1；a=2；</td> 
>    <td>写一个变量，再写这个变量</td> 
>   </tr> 
>   <tr> 
>    <td>读后写</td> 
>    <td>a=b；b=1；</td> 
>    <td>读一个变量之后，再写这个变量</td> 
>   </tr> 
>  </tbody> 
> </table>

总之，编译器重排序不会改变代码之间的数据依赖

他这里还遵守了一个叫做`as-if-serial`语义的东西：不管怎么重排序，对于`单线程`而言，程序的执行结果不能改变

所以注意一下，这里重排序保证的顺序不变只是针对单线程而言，所以，当我们上面那个案例是2个线程的情况的时候，就爆炸了（这里先挖一个坑，顺序一致性模型，以后来填）

# 内存屏障 #

为了保证内存可见性，Java会使用一种叫做内存屏障的东西来把指令划分开，插入一条内存屏障，就意味着，在这个内存屏障之前的指令必须先执行完了，才能通过内存屏障，继续去执行后面的指令，大概是这个意思：

> A
> 
> B
> 
> C
> 
> D
> 
> \-----内存屏障
> 
> E
> 
> F
> 
> G

对于上面的部分ABCD，他们之间的执行顺序是可以由编译器来随便调整的，但是必须等到他们执行完了之后，程序才会接着往下走，去执行EFG

btw：内存屏障还会强制刷出CPU的缓存数据，使得数据是最新的

## 内存屏障分类 ##

在Java中，JMM把内存屏障分成了4类

<table> 
 <thead> 
  <tr> 
   <th>名字</th> 
   <th>作用</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>LoadStore</td> 
   <td>前面的数据load完了后才能store</td> 
  </tr> 
  <tr> 
   <td>StoreStore</td> 
   <td>前面的数据store完了后才能store</td> 
  </tr> 
  <tr> 
   <td>StoreLoad</td> 
   <td>前面的数据store完了后才能load</td> 
  </tr> 
  <tr> 
   <td>LoadLoad</td> 
   <td>前面的数据load完了后才能load</td> 
  </tr> 
 </tbody> 
</table>

其实就对应了上面几种数据依赖性

下面我用volatile关键字插入内存屏障来大概解释一下

## volatile和内存屏障 ##

JMM对volatile有这样一个策略：

> 在每个volatile写操作的**前面**插入一个StoreStore屏障；
> 
> 在每个volatile写操作的**后面**插入一个StoreLoad屏障；
> 
> 在每个volatile读操作的**后面**插入一个LoadLoad屏障；
> 
> 在每个volatile读操作的**后面**插入一个LoadStore屏障。

对于写操作，用图表示就是：

![image-20200307172244154][]

对于读操作，用图表示就是：

![image-20200307172223213][]

## Happens-Before ##

JDK 5开始，爪哇使用了新的JSR-133内存模型，然后用了一个叫做Happens-Before的概念来阐述操作之间的内存可见性，在JMM中，如果一个操作要对另外一个操作可见，则在两个操作之间需要满足Happens-Before关系

别问，问就是背，反正我没背，为了博客的完整性，网上找了一段贴上来了，还是挖坑以后补上

*  单一线程原则：在一个线程内，在程序前面的操作先行发生于后面的操作。
 *  管程锁定规则：先unlock再lock
 *  volatile 变量规则：对一个 volatile 变量的**写操作**先行发生于后面对这个变量的**读操作**
 *  线程启动规则：Thread 对象的 **start()** 方法调用先行发生于此线程的每一个动作
 *  线程加入规则：Thread 对象的结束先行发生于 join() 方法返回。
 *  线程中断规则：对线程 interrupt() 方法的调用先行发生于被中断线程的代码检测到中断事件的发生，可以通过 interrupted() 方法检测到是否有中断发生。
 *  对象终结规则：一个对象的初始化完成（构造函数执行结束）先行发生于它的 finalize() 方法的开始。
 *  传递性：如果操作 A 先行发生于操作 B，操作 B 先行发生于操作 C，那么操作 A 先行发生于操作 C。

[image-20200307151909602]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1MTkwOTYwMi5wbmc?x-oss-process=image/format,png
[image-20200307152142382]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1MjE0MjM4Mi5wbmc?x-oss-process=image/format,png
[image-20200307152839200]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1MjgzOTIwMC5wbmc?x-oss-process=image/format,png
[image-20200303205119392]: https://imgconvert.csdnimg.cn/aHR0cDovL3BpYy5pbWxlaHIuY29tL3VwbG9hZHMvdHlwb3JhL2ltYWdlLTIwMjAwMzAzMjA1MTE5MzkyLnBuZw?x-oss-process=image/format,png
[image-20200307153834061]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1MzgzNDA2MS5wbmc?x-oss-process=image/format,png
[image-20200307154648973]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1NDY0ODk3My5wbmc?x-oss-process=image/format,png
[image-20200307154918647]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1NDkxODY0Ny5wbmc?x-oss-process=image/format,png
[image-20200307155152471]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE1NTE1MjQ3MS5wbmc?x-oss-process=image/format,png
[image-20200307160437442]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE2MDQzNzQ0Mi5wbmc?x-oss-process=image/format,png
[image-20200307162433423]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE2MjQzMzQyMy5wbmc?x-oss-process=image/format,png
[image-20200307164344656]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE2NDM0NDY1Ni5wbmc?x-oss-process=image/format,png
[image-20200307172244154]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE3MjI0NDE1NC5wbmc?x-oss-process=image/format,png
[image-20200307172223213]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly9waWMuaW1sZWhyLmNvbS91cGxvYWRzL3R5cG9yYS9pbWFnZS0yMDIwMDMwNzE3MjIyMzIxMy5wbmc?x-oss-process=image/format,png