JVM—Java内存模型

悠悠 2021-11-17 09:46 324阅读 0赞

## JVM—Java内存模型 ##

并发处理的广泛应用是使得Amdahl定律代替摩尔定律 成为计算机性能发展源动力的根本原因, 也是人类"压榨"计算机运算能力的最有利武器

*  由于计算机的运算速度与它的存储和通信子系统差距太大, 大量的时间都花费在磁盘I/O,网络通信或者数据库访问上, 如果不希望处理器在大部分时间里都处于等待其他资源的状态, 让计算机同时处理几项任务是非常有效的"压榨’'手段

### 1.Java内存模型 ###

Java虚拟机规范中试图定义一种Java内存模型, 来屏蔽掉各种硬件和操作系统的内存访问差异, 以实现让Java程序在各种平台下都能达到一致的内存访问效果

#### 1>主内存与工作内存 ####

Java内存模型的主要目标是定义程序中各个变量的访问规则, 即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节.(这里的"变量"指的是实例字段, 静态字段和构成数组对象的元素, 但不包括局部变量和方法参数,因为后者是线程私有的)

*  java内存模型规定了所有的变量都存储在主内存中, 每条线程还有自己的工作内存(处理器的高速缓存), 线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝(可能是该对象的引用或者 对象中某个在线程中访问的字段), 线程对变量的所有操作(读取, 赋值等)都不必须在工作内存中进行, 而不能直接读写主内存中的变量.不同的线程之间也无法直接访问对方工作内存中的变量, 线程之间变量值的传递需要通过主内存来完成

线程, 主内存, 工作内存三者的交互关系如图 :

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

这里讲的主内存, 工作内存与之前java内存区域中的Java堆,栈,方法区等不是同一个层次的内存划分, 二者基本没有关系, 如果一定要勉强对应起来, 主内存主要对应于Java堆中的对象实例数据部分, 而工作内存则对应虚拟机栈中的部分区域. 从更低层次来说, 主内存就直接对应于物理硬件的内存, 而为了更好的运行速度, 虚拟机可能会让工作内存优先存储与寄存器和高速缓存中, 因为程序运行时主要访问读写的是工作内存

#### 2>内存间交互操作 ####

关于主内存与工作内存之间具体的交互协议, 即一个变量如何从主内存拷贝到工作内存, 如何从工作内存同步回主内存之类的实现细节, Java内存模型中定义了以下8种操作来完成, 虚拟机实现时必须保证下面提及的每一种操作都是原子的, 不可再分的

*  lock(锁定) : 作用于主内存的变量, 把一个变量标识为一条线程独占的状态
 *  unlock(解锁) : 作用与主内存的变量, 把一个处于锁定状态的变量释放出来, 释放后的变量才可以被其他线程锁定
 *  read(读取) : 作用于主内存的变量, 它把一个变量的值从主内存传输到线程的工作内存中, 以便于随后的load动作
 *  load(载入) : 作用于工作内存的变量, 它把read操作从主内存中得到的变量值放入工作内存的变量副本中
 *  use(使用) : 作用域工作内存的变量, 它把工作内存中一个变量的值传递给执行引擎, 每当虚拟机遇到一个需要使用到变量的值的字节码指令时会执行这个操作
 *  assign(赋值) : 作用于工作内存的变量, 它把一个从执行引擎接收到的值付给工作内存中的变量, 每当虚拟机遇到一个给变量赋值的字节码指令时执行这个操作
 *  store(存储) : 作用于工作内存的变量, 它把工作内存中一个变量的值传送到主内存中 , 以便随后的write使用
 *  write(写入) : 作用于主内存的变量, 把store操作从工作内存汇总得到的 变量 值放入主内存的变量中

如果要把一个变量从主内存复制到工作内存, 那就需要 顺序的执行read, load操作, 如果要把变量从工作内存同步回主内存, 就要顺序的执行store和write操作. Java内存模型只要求 上述两个操作必须按顺序执行, 而没有保证是连续执行, 也就是说两个操作之间是可以插入其他指令的

除此之外, Java内存模型还规定了而在上述8种基本操作时必须满足如下规则 :

*  不允许read和load , store和write操作之一单独出现, 即不允许一个变量从主内存读取了但工作内存不接受, 或者从工作内存发起回写了但主内存不敢接收的情况出现
 *  不允许一个线程 丢弃它的最近assign操作, 即变量在工作内存中改了之后必须把该变化同步回主内存
 *  不允许一个线程无原因的(没有发生assign操作)把数据从工作内存中同步回主内存中
 *  一个新的变量只能在主内存中"诞生", 不允许在工作内存中直接使用一个未被初始化(load或者assign)的变量, 换句话说就是对一个变量实施use,store操作之前, 必须先执行过了assign和load操作
 *  一个变量在同一时刻只允许一条线程对其进行lock操作, 但lock操作可以被同一条线程执行多次, 多次执行lock之后,只有执行相同次数的unlock操作,变量才会被解锁
 *  如果对一个变量执行lock操作, 那将会清空工作内存中此变量的值,在执行引擎使用这个变量前,需要重新执行load或者assign操作初始化变量的值
 *  如果一个变量事先没有被lock操作锁定, 那就不允许对它执行unlock操作,也不允许去unlock一个被其他线程锁定住的变量
 *  对一个变量执行unlock操作之前,必须先把此变量同步回主内存中(执行store,write操作)

#### 3.对于volatile变量的特殊规则 ####

**关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制**

当一个变量被定义为volatile之后, 它有两种特性

*  1.保证此变量对所有线程的可见性, 这里的"可见性"是指当一条线程修改了这个变量的值,新值对于其他线程来说是可以立即得知的. 而对于普通变量, 线程A修改了一个普通变量的值, 然后向主内存进行回写, 另外一条线程B在线程A完成回写之后再从主内存进行读取操作, 新变量值才会对线程B可见
 *  2.禁止指令重排序优化, 普通的变量仅仅会保证在该 方法执行过程中所有依赖 复制结果的 地方都能获取到正确的结果, 而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致, 只是"线程内表现为串行的语义"

尽管volatile变量在各个工作内存中不存在一致性问题(在 各个线程的工作内存中,volatile也可以存在不一致的情况, 但由于每次使用之前都要先刷新,执行引擎看不到不一致的情况, 因此可以认为不存在一致性问题), 但是java里面的运算并不是原子操作,导致volatile变量的运算在并发下一样是不安全的

public class VolatileTest {
        
        public static volatile int race = 0;
    
        public static void increase() {
        
            race++;
        }
    
        public static final int THREADS_COUNT = 20;
    
        public static void main(String[] args) {
        
    
            Thread[] threads = new Thread[THREADS_COUNT];
            for (int i = 0; i < THREADS_COUNT; i++) {
        
                threads[i] = new Thread(() -> {
        
                    for (int j = 0; j < 10000; j++) {
        
                        increase();
                    }
                });
                threads[i].start();
            }
    
            while (Thread.activeCount() > 2)
                Thread.yield();
    
            System.out.println(race);
        }
    }

在idea中运行上述代码, 如果volatile变量的运算是线程安全的, 那么预期结果会输出200000,但 实际上每次的输出值都小于这个数, 也就说明volatile变量的运算并不是线程安全的

由于volatile变量只能保证可见性, 在不符合以下两条规则的运算场景中, 我们仍然要通过加锁(使用synchronized或java.util.concurrent中的原子类)来保证原子性

*  运算结果并不依赖变量的当前值, 或者能够确保只有单一的线程修改变量的值
 *  变量不需要与其他的状态变量共同参与不变约束

关于volatile关键字对于指令重排序, 在分析对一个volatile变量赋值的字节码时,我们发现其与普通变量的区别在于,赋值后, 多了一个 "lock addl $0x0, (%esp)“操作, 这个操作相当于一个"内存屏障”, 指令重排序时不能把后面的指令重排序到内存屏障之间的位置

addl $0x0 , (%esp) (把ESP寄存器变量增加0),显然是一个空操作, 关键在于lock前缀, 其作用是使得本CPU的Cache写入了内存, 该写入动作也会引起别的CPU或者别的内核无效化其Cache, 相当于对Cache中的变量进行了一次store和write操作, 所以通过这样一个空操作, 可以让volatile变量的修改对其他CPU立即可见

指令重排序在硬件架构上讲是将CPU采用了允许将多条不同指令不按程序规定的顺序分发给各相应电路单元处理, 但并不是指令任意重排, 所以在本CPU中, 重排序看起来依然是有序的. 因此, lock addl $0x0 , (%esp) 指令把修改同步到内存时, 意味着之前的操作都已经执行完成了, 这样就形成了"指令重排序无法越过内存屏障"的效果

volatile变量读操作的性能与普通变量几乎没有什么差别, 但是写操作可能会慢一些, 因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行

#### 4.对于long和double型变量的特殊规则 ####

java内存模型要求lock,unlock,read,load,use,assign,store,write这八个操作都具有原子性, 但是对于64位的数据类型(long和double),则规定: 允许虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行, 也就是允许虚拟机实现选择可以不保证64位数据类型的load, store, read和write这4个操作的原子性, 这点就是所谓的long和doule的非原子性协定.

但在实际开发中, 目前各种平台下商用虚拟机几乎都选择把64位数据的读写操作作为原子操作来对待

#### 5.原子性,可见性与有序性 ####

*  原子性 : 基本数据类型的访问读写是具备原子性的, 如果需要更大范围的原子性保证, java内存模型提供了lock和unlock操作来满足这种需求, 我们可以在Java代码中使用synchronized关键字, 其在编译后生成了monitorenter和monitorexit字节码指令, 来使synchronized块之间的操作也具备原子性
 *  可见性 : 可见性是指一个线程修改了共享变量的值, 其他线程能够立即得知这个修改, Java内存模型是通过在变量修改后将新值同步回主内存, 在变量读取前从主内存刷新变量值这种依赖主内存作为传递媒介的方式来实现同步的, 无论是普通变量还是volatile变量都是如此, 但两者的区别是 : volatile的特殊规则保证了新值能立即同步到主内存, 以及每次使用前从主内存刷新,所以volatile变量保证了多线程操作时变量的可见性. 除此之外, java中的synchronized和final关键字也可以实现可见性
 *  有序性 : 如果在本线程内观察, 所有的刀座都是有序的. 但在一个线程中观察另一个线程, 所有的操作是无序的. 前半句是指"线程内表现为串行的语义", 后半句是指 “指令重排序"和"工作内存与主内存同步延迟”

#### 6.先行发生原则 ####

先行发生原则是判断数据是否存在竞争, 线程是否安全的主要依据.

下列是Java内存模型中的一些"天然的"先行发生关系, 这些先行发生关系无须任何同步器协助就已经存在, 可以在编码中 直接使用. 如果两个操作之间的关系不在此列, 并且无法从下列关系推导出来的话, 它们就没有顺序性保障, 虚拟机可以随意地对他们进行重排序

*  程序次序规则 : 在**一个线程**内, 按照程序代码顺序, 书写在前面的操作先行发生在后面的操作(控制流顺序)
 *  管程锁定规则 : 一个unlock操作先行发生于后面对同一个锁的lock操作
 *  volatile变量规则 : 对于一个volatile变量的写操作先行发生于后面对这个变量的读操作
 *  线程启动规则 : Thread对象的start()方法先行发生与对此线程的每一个动作
 *  线程终止规则, 线程中的所有操作都先行发生与此线程的终止检测, 我们可以通过Thread.join()方法结束, Thread.isAlive()的返回值等手段检测到线程已经终止执行
 *  线程中断规则 : 对线程的interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生
 *  对象终结规则 : 一个对象的初始化完成(构造函数执行结束)先行发生于它的finalize()方法的开始
 *  传递性 : 如果A操作先行发生于B, B操作线程发生于C, 则 A操作先行发生于C

最后有一个结论 : 时间先后顺序与先行发生原则之间基本没有太大的关系, 所以衡量并发安全问题的时候不要受到时间顺序的干扰, 一切必须以先行发生原则为准

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dpbnRlcnNoaWk_size_16_color_FFFFFF_t_70]: /images/20211116/3bed5da6e31f43e9a6fd773efc20397d.png