Java虚拟机内存模型

最新推荐文章于 2024-09-18 09:58:58 发布

学之以恒_大道至简

最新推荐文章于 2024-09-18 09:58:58 发布

阅读量215

点赞数 1

分类专栏： jvm 文章标签： java jvm内存模型

本文链接：https://blog.csdn.net/cb_lcl/article/details/81062467

版权

jvm 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

1. 概述

在说Java虚拟机内存模型之前，先了解一下物理计算机中的并发问题，物理机遇到的并发问题与虚拟机中的情况有不少相似之处，物理机对并发的处理方案对于虚拟机的实现也有相当大的参考意义。

由于计算机的存储设备与处理器的运算速度有几个数量级的差距，所以现代计算机系统不得不加入一层读写速度尽可能接近处理器运算速度的高速缓存(Cache)来作为内存与处理器之间的缓冲：将运算需要使用到的数据复制到缓存中，让运算能快速进行，当运算结束后再从缓存同步回内存之中，这样处理器就无须等待缓慢的内存读写了。

加入缓存机制引入了另外一个问题:缓存的一直性(Cache Coherence)。

在多处理器系统中，每个处理器都有自己的高速缓存，而它们又共享同一个主内存(虚拟机内存的一部分，所以的变量都存储其中)，如图1所示。当多个处理器的运算恩物都设计同一块主内存区域时，可能导致缓存数据不一致。

为了解决一致性的问题，需要各个处理器访问缓存时都遵循一些协议，在读写时要根据协议来进行操作，这类协议有MSI、MESI、MOSI、Synapse、Firefly及Dragon Protocal等。

下面要介绍的“内存模型”可以理解为：在特定的操作协议下，对特定的内存或高速缓存进行读写访问的过程抽象。

2. Java虚拟器内存模型

Java内存模型的主要目标是：定义程序中各个变量的访问规则，即在虚拟机中将变量存储到内存和从内存中取出变量这样的底层细节。达到屏蔽掉各种硬件和操作系统的内存访问差异，以实现让Java程序在各种平台下都能得到一致的内存访问效果。

2.1 主内存与工作内存

Java内存模型规定了所以的变量都存储主内存(Main Memory)中（此处的主内存与介绍物理机时的主内存名字一样，两者可以相互类比，但此处仅是虚拟机内存的一部分）。

每条线程还有自己的工作内存(Working Memory,与介绍物理机时的处理器高速缓存类比)，线程的工作内存中保存了被该线程使用到的变量的主内存副本拷贝。

线程对变量的所有操作(读取、赋值等)都必须在工作内存中进行，而不能直接读写主内存中的变量。

不同的线程之间也无法直接访问对方内存中的变量，线程间变量值的传递均需要通过主内存来完成。

线程、主内存、工作内存之间的交互关系如下图2:

此处将的主内存、工作内存与Java内存区域中的Java堆、栈、方法区等并不是同一个层次的内存划分，两者基本上没有什么关系。如果两个一定要勉强对应起来，那么主内存主要对应于Java堆中的对象实例数据部分，而工作内存则对应于虚拟机栈中的部分区域。

从更低层次上说，主内存直接对应于物理硬件的内存，而为了获取更好的运行速度，虚拟机可能会让工作内存有限存储于寄存器和高速缓存中，因为程序运行时主要访问读写的是工作内存。

2.2 内存间交互操作

关于主内存与工作内存之间具体的交互协议，即一个变量如何从主内存拷贝到工作内存、如何从工作内存同步回主内存之类的实现细节，Java内存模型中定义了以下8种操作来完成，虚拟机实现时必须保证这8种操作都是原子的、不可再分的(对于64位的long和double类型的变量来说，load、store、read、write操作在某些平台上允许有例外，后面会讲)：

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

如果要把主内存的变量从复制到工作内存中，则要顺序执行read、load操作。

如果要把工作内存的变量回写到主内存中，则要顺序执行store、write操作。

注意：java内存模型只要是上述的操作的是顺序执行的，而没有保证是连续执行的，所以这些指令之间是可以插入其他执行的，如：read a read b load b load a。除此之外，Java内存模型还规定了指定上述8项基本操作时还必须满足如下规则：

不允许read和load、store和write操作之一单独出现。即：不允许一个变量从主内存读取了但工作内存不接受，或者从工作内存回写了但主内存不接受的情况出现。
不允许一个线程丢弃它的最近的assign操作，即：变量在工作内存中改变了之后必须把该表同步到主内存中，以保证主内存是永远是最新的值。
不允许一个线程无原因地（没有发生过任何assign操作）把数据从线程的工作内存中同步回主内存。(我的理解是有变动才执行同步操作，以避免不必要的资源损耗)
一个新的变量只能在主内存中“诞生”，不允许在工作内存中直接使用一个未被初始化（load或者assign）的变量，换句话说，就是对一个变量实施user、store操作之前，必须先执行过了assign或load操作。
一个变量在同一时刻只允许一条线程对其记性lock操作，但是lock操作可以被同一条线程重复多次执行，多次执行lock后，只有执行相同次数的unlock操作，变量才会被解锁
如果对一个变量执行了lock操作，那将会清空工作内存中此变量的值，在执行引擎使用这个变量前，需要重新执行load或assgin操作初始化变量的值。
如果一个变量事先没有被lock操作锁定，那就不允许对它执行unlock操作，也不允许去unlock一个被其他线程锁定的变量。（有了lock，才会有unlock）
对一个变量执行unlock操作之前，必须先把此变量同步回主内存中(这样的话unlock操作之后该变量才可以被其他线程调用)。

这8中内存访问操作以及上述规则限定，再加上volatile的一些特殊规定(后面会单独对volatile进行解释)，就已经完全确定了java程序中哪些内存访问操作在并发下是安全的。

另外：先行发生原则，也可以用来确定一个访问在并发环境下是否安全。

2.3 对于volatile型变量的特殊规则

关键字volatile可以说是Java虚拟机提供的最轻量级的同步机制，Java内存模型对于volatile专门定义了一些特殊的访问规则，先介绍一下volatile的作用。

当一个变量定义为volatile之后，它将具备两种特性。

第一种：保证此变量对所有线程的可见性，这里的“可见性”是指当一条线程修改了这个变量的值，新值对于其他线程来说立即得知的。而普通变量如上面所说，普通变量的值在线程间传递均需要通过主内存来完成。volatile变量在各个线程的工作内存中不存在不一致性问题，但是Java里面的运算并非原子操作，导致volatile变量的运算在并发下一样是不安全的。

我们可以通过一段简单的演示来说明原因，看如下代码：

public class VolatileTest
{
	public static volatile int race = 0;

	public static void increase() {
		race++;
	}

	private 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(new Runnable() {
				public void run() {
					for(int i=0;i<10000;i++) {
						increase();
					}
				}
			});
			threads[i].start();
		}

		//等待所有累加线程都结束
		while(Thread.activeCount() > 1) {
			Thread.yield();
			System.out.println(race);
		}
	}
}

这段代码发起了20个线程，每个线程对race变量进行10000次自增操作，如果代码正确并发的话，结果应该是200000，执行多次后，发现每次的结果都不一样而且都小于200000.

为什么呢？我们用Javap反编译这段代码后得到代码清单

问题就出现在自增运算“race++”之中，原因：当getstatci指令把race的值渠道操作栈顶时，volatile关键字保证了race的值在此时是正确的，但是在执行了iconst_1、iadd这些指令的时候，其他线程可能已经把race的值加大了，而操作栈顶的值就变成了过期的数据，所以putstatic指令执行后就可能把较小的race值同步到主内存之中。

可以用以下两种方案保证运算结果正确：

使用 synchronized 或者是锁的方式来保证原子性
用 Atomic 包中 AtomicInteger 来替换 int，它利用了 CAS 算法来保证了原子性。

public synchronized static void increase() {
		race++;
	}

public static AtomicInteger  race = new AtomicInteger ();

由于volatile变量只能保证可见性，在不符合以下两条规则的运算场景中，我们仍然要通过加锁来保证原子性。

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

第二种：使用volatile变量的第二个语义是禁止指令重排序优化。

普遍的变量仅仅会保证在该方法的执行过程中所有依赖赋值结果的地方都能获取到正确的结果，而不能保证变量赋值操作的顺序与程序代码中的执行顺序一致。因为在一个线程的方法执行过程中无法感知到这点，这也是Java内存模型中描述的所谓的“线程内表现为串行的语义”。

举一个伪代码:

int a = 1;//1
int b = 2;//2
int c = 3;//3

理想情况执行顺序是1->2->3,但是经过JVM优化后执行顺序可能是1->3->2.

指令重排的的应用

一个经典的使用场景就是双重懒加载的单例模式了:

public class Singleton {

    private static volatile Singleton singleton;

    private Singleton() {
    }

    public static Singleton getInstance() {
        if (singleton == null) {
            synchronized (Singleton.class) {
                if (singleton == null) {
                    //防止指令重排
                    singleton = new Singleton();
                }
            }
        }
        return singleton;
    }
}

这里的 volatile 关键字主要是为了防止指令重排。

如果不用，singleton = new Singleton();，这段代码其实是分为三步：

分配内存空间。
初始化对象。
将 singleton 对象指向分配的内存地址。

加上 volatile 是为了让以上的三步操作顺序执行，反之有可能第二步在第三步之前被执行就有可能某个线程拿到的单例对象是还没有初始化的，以致于报错。

在了volatile关键字修饰实际上会指定一个内存屏蔽的操作“lock***”。

2.4 对于long和double型变量的特殊规则

Java内存模型要求lock、unlock、read、load、use、assgin、store、write这8个操作是原子性，但是对于64位的数据类型（long和double），在模型中特别定义了一条相对宽松的规定：运行虚拟机将没有被volatile修饰的64位数据的读写操作划分为两次32位的操作来进行，即允许虚拟机实现选择可以不保证64位数据类型的read、load、store、write这4个操作的原子性。这点就是所谓的Long和double的非原子性协定。

在实际开发中，目前各种平台下的商用虚拟机几乎都选择把64位数据的读写操作作为原子性操作来对待，因此在编写代码时一般不需要把用到的long和double变量专门声明为volatile。