多线程(十二) -- 内存(一) -- java内存模型JMM

leo_messi94

已于 2022-11-06 17:08:17 修改

阅读量313

点赞数 1

分类专栏：多线程文章标签： java 开发语言后端

于 2020-07-19 22:53:30 首次发布

本文链接：https://blog.csdn.net/weixin_39724194/article/details/107451450

版权

多线程专栏收录该内容

32 篇文章 7 订阅

订阅专栏

配合volatile一起看，这里先简单记录下，回头再好好理解下。

1. 什么是JMM

java内存模型是不存在的东西。是一个概念，一个约定。

JMM 即 Java Memory Model，它从java层面定义了主存（所有线程共享数据，静态变量等）、工作内存（私有线程，局部变量）抽象概念，底层对应着 CPU 寄存器、缓存、硬件内存、CPU 指令优化等。JMM 体现在以下几个方面

原子性 - 保证指令不会受到线程上下文切换的影响
可见性 - 保证指令不会受 cpu 缓存的影响
有序性 - 保证指令不会受 cpu 指令并行优化的影响

2. 关于JMM的一些同步的约定

线程解锁前，必须把共享变量立刻刷回主存。
线程加锁前，必须读取主存中的最新值到工作内存中
加锁和解锁是同一把锁

3. 主内存和工作内存

3.1 图解内存间的交互操作：

在这里插入图片描述
上述图中先store再write。
图中三组，再加上lock和unlock。

3.2 内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可再分的（对于double和long类型的变量来说，load、store、read和write操作在某些平台上允许例外）

lock （锁定）：作用于主内存的变量，把一个变量标识为线程独占状态
unlock （解锁）：作用于主内存的变量，它把一个处于锁定状态的变量释放出来，释放后的变量才可以被其他线程锁定
read （读取）：作用于主内存变量，它把一个变量的值从主内存传输到线程的工作内存中，以便随后的load动作使用
load （载入）：作用于工作内存的变量，它把read操作从主存中变量放入工作内存中
use （使用）：作用于工作内存中的变量，它把工作内存中的变量传输给执行引擎，每当虚拟机遇到一个需要使用到变量的值，就会使用到这个指令
assign （赋值）：作用于工作内存中的变量，它把一个从执行引擎中接受到的值放入工作内存的变量副本中
store （存储）：作用于主内存中的变量，它把一个从工作内存中一个变量的值传送到主内存中，以便后续的write使用
write 　（写入）：作用于主内存中的变量，它把store操作从工作内存中得到的变量的值放入主内存的变量中

3.3 JMM对这八种指令的使用，制定了如下规则：

不允许read和load、store和write操作之一单独出现。即使用了read必须load，使用了store必须write
不允许线程丢弃他最近的assign操作，即工作变量的数据改变了之后，必须告知主存
不允许一个线程将没有assign的数据从工作内存同步回主内存
一个新的变量必须在主内存中诞生，不允许工作内存直接使用一个未被初始化的变量。就是怼变量实施use、store操作之前，必须经过assign和load操作
一个变量同一时间只有一个线程能对其进行lock。多次lock后，必须执行相同次数的unlock才能解锁
如果对一个变量进行lock操作，会清空所有工作内存中此变量的值，在执行引擎使用这个变量前，必须重新load或assign操作初始化变量的值
如果一个变量没有被lock，就不能对其进行unlock操作。也不能unlock一个被其他线程锁住的变量
对一个变量进行unlock操作之前，必须把此变量同步回主内存

JMM对这八种操作规则和对volatile的一些特殊规则就能确定哪里操作是线程安全，哪些操作是线程不安全的了。但是这些规则实在复杂，很难在实践中直接分析。所以一般我们也不会通过上述规则进行分析。更多的时候，使用java的happen-before规则来进行分析。

3.4 存在的问题：

在这里插入图片描述

volatile解决。

2. 可见性

2.1 退不出的循环

先来看一个现象，main线程对run变量的修改对于t线程不可见，导致t线程无法终止：

public class TestJMM {
    static boolean run = true;
    public static void main(String[] args) throws InterruptedException {
        Thread t = new Thread(()->{
            while(run){
                // ....
                // 如果加上这个代码就会停下来
                // System.out.println(2323);
            }
        });
        t.start();
        Thread.sleep(100);
        System.out.println(3434);
        run = false; // 线程t不会如预想的停下来
    }
}

结果：
在这里插入图片描述
放开输出语句结果：

为什么呢？分析一下：

初始状态， t 线程刚开始从主内存读取了 run 的值到工作内存
因为t1线程频繁地从主存中读取run的值，jit即时编译器会将run的值缓存至自己工作内存中的高速缓存中，减少对主存中run的访问以提高效率
1 秒之后，main 线程修改了 run 的值，并同步至主存，而 t 是从自己工作内存中的高速缓存中读取这个变量的值，结果永远是旧值

2.2 解决方法：

volatile（表示易变关键字的意思），它可以用来修饰成员变量和静态成员变量，他可以避免线程从自己的工作缓存中查找变量的值，必须到主存中获取它的值，线程操作 volatile 变量都是直接操作主存
使用synchronized关键字也有相同的效果！在Java内存模型中，synchronized规定，线程在加锁时，先清空工作内存→在主内存中拷贝最新变量的副本到工作内存 →执行完代码→将更改后的共享变量的值刷新到主内存中→释放互斥锁。

while(true){
   synchronized(lock) {
   		if (!run) {
   			break;
   		}
   }
}

2.3 可见性vs原子性

前面例子体现的实际就是可见性，它保证的是在多个线程之间一个线程对 volatile 变量的修改对另一个线程可见，而不能保证原子性，仅用在一个写线程，多个读线程的情况。上例从字节码理解是这样的：

getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
getstatic run // 线程 t 获取 run true
putstatic run // 线程 main 修改 run 为 false， 仅此一次
getstatic run // 线程 t 获取 run false

比较一下之前我们将线程安全时举的例子：两个线程一个 i++ 一个 i-- ，只能保证看到最新值，不能解决指令交错：

// 假设i的初始值为0
getstatic i // 线程2-获取静态变量i的值 线程内i=0

getstatic i // 线程1-获取静态变量i的值 线程内i=0
iconst_1 // 线程1-准备常量1
iadd // 线程1-自增 线程内i=1
putstatic i // 线程1-将修改后的值存入静态变量i 静态变量i=1

iconst_1 // 线程2-准备常量1
isub // 线程2-自减 线程内i=-1
putstatic i // 线程2-将修改后的值存入静态变量i 静态变量i=-1

有同学会问，volatile的作用不是让修改可见么？这里的可见是保证getstatic读到的是最新的值，但是这里getstatic指令已经读取过了，并且读到的是0，并不能让他重新读取。

注意：
synchronized 语句块既可以保证代码块的原子性，也同时保证代码块内变量的可见性。但缺点是 synchronized 是属于重量级操作，性能相对更低。

如果在前面示例的死循环中加入 System.out.println() 会发现即使不加 volatile 修饰符，线程 t 也能正确看到对 run 变量的修改了，想一想为什么？
因为println方法里面有synchronized修饰。

3. 有序性

JVM会在不影响正确性的前提下，可以调整语句的执行顺序，思考下面一段代码：

static int i;
static int j;
// 在某个线程内执行如下操作：
i = 1;
j = 1;

可以看到，至于先执行i还是先执行j，对结果并不会产生影响。所以上述代码执行时，既可以先执行i的赋值操作，也可以先执行j的赋值操作。

这种特性称之为【指令重排】，多线程下指令重排会影响正确性。为什么要有指令重排这项优化呢？从CPU执行指令的原理来理解下吧：
现代CPU支持多级指令流水线，例如支持同时执行取指令 - 指令译码 - 内存访问 - 数据写回的处理器，就可以称之为五级指令流水线。这时CPU可以在一个时钟周期内，同时运行五条指令的不同阶段（相当于一条执行时间最长的复杂指令），IPC = 1，本质上，流水线技术并不能缩短单条指令的执行时间，但它变相地提高了指令的吞吐率。
在这里插入图片描述

3.1 诡异的结果：

int num = 0;

// volatile 修饰的变量，可以禁用指令重排 volatile boolean ready = false; 可以防止变量之前的代码被重排序
boolean ready = false; 
// 线程1 执行此方法
public void actor1(I_Result r) {
 if(ready) {
 	r.r1 = num + num;
 } else {
 	r.r1 = 1;
 }
}
// 线程2 执行此方法
public void actor2(I_Result r) {
 num = 2;
 ready = true;
}

分别执行上面两个线程

I_Result 是一个对象，有一个属性 r1 用来保存结果，问可能的结果有几种？有同学这么分析：

情况1：线程1 先执行，这时 ready = false，所以进入 else 分支结果为 1
情况2：线程2 先执行 num = 2，但没来得及执行 ready = true，线程1 执行，还是进入 else 分支，结果为1
情况3：线程2 执行到 ready = true，线程1 执行，这回进入 if 分支，结果为 4（因为 num 已经执行过了）

但我告诉你，结果还有可能是 0 ，信不信吧！这种情况下是：

线程2 执行 ready = true，切换到线程1，进入 if 分支，相加为 0，再切回线程2 执行 num = 2。

这种现象叫做指令重排，是 JIT 编译器在运行时的一些优化，这个现象需要通过大量测试才能复现，可以使用jcstress工具进行测试。上面仅是从代码层面体现出了有序性问题，下面在讲到 double-checked locking 问题时还会从java字节码的层面了解有序性的问题。

3.2 重排序也需要遵守一定规则：

重排序操作不会对存在数据依赖关系的操作进行重排序。比如：a=1;b=a; 这个指令序列，由于第二个操作依赖于第一个操作，所以在编译时和处理器运行时这两个操作不会被重排序。
重排序是为了优化性能，但是不管怎么重排序，单线程下程序的执行结果不能被改变。比如：a=1;b=2;c=a+b这三个操作，第一步（a=1)和第二步(b=2)由于不存在数据依赖关系，所以可能会发生重排序，但是c=a+b这个操作是不会被重排序的，因为需要保证最终的结果一定是c=a+b=3。

重排序在单线程模式下是一定会保证最终结果的正确性，但是在多线程环境下，问题就出来了。解决方法：volatile 修饰的变量，可以禁用指令重排

注意：使用synchronized并不能解决有序性问题，但是如果是该变量整个都在synchronized代码块的保护范围内，那么变量就不会被多个线程同时操作，也不用考虑有序性问题！在这种情况下相当于解决了重排序问题！参考double-checked locking 问题里的代码，第一个代码片段中的instance变量都在synchronized代码块中，第二个代码片段中instance不全在synchronized中所以产生了问题。视频 P151

leo_messi94

关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
多线程(十二) -- 内存(一) -- java内存模型JMM

配合volatile一起看，这里先简单记录下，回头再好好理解下。什么是JMMjava内存模型，不存在的东西。是一个概念，一个约定。关于JMM的一些同步的约定线程解锁前，必须把共享变量立刻刷回主存。线程加锁前，必须读取主存中的最新值到工作内存中加锁和解锁是同一把锁主内存和工作内存图解内存间的交互操作：上述图中先store再write。图中三组，再加上lock和unlock。内存交互操作有8种，虚拟机实现必须保证每一个操作都是原子的，不可在分的（对于double和long类型的变量来
复制链接

扫一扫

专栏目录