zoukankan      html  css  js  c++  java
  • JMM模型

    概念

    Java内存模型(Java Memory Model简称JMM)是一种抽象的概念,并不真实存在,它描述的是一组规则或规范,通过这组规范定义了程序中各个变量(包括实例字段,静态字段和构成数组对象的元素)的访问方式。JVM运行程序的实体是线程,而每个线程创建时JVM都会为其创建一个工作内存(有些地方称为栈空间),用于存储线程私有的数据。

    而Java内存模型中规定所有变量都存储在主内存,主内存是共享内存区域,所有线程都可以访问,但线程对变量的操作(读取赋值等)必须在工作内存中进行,首先要将变量从主内存拷贝的自己的工作内存空间,然后对变量进行操作,操作完成后再将变量写回主内存,不能直接操作主内存中的变量,工作内存中存储着主内存中的变量副本拷贝,前面说过,工作内存是每个线程的私有数据区域,因此不同的线程间无法访问对方的工作内存,线程间的通信(传值)必须通过主内存来完成。

    概念图:

     

     

    JMM与JVM内存的不同

    JMM内存

    主内存

    主要存储的是Java实例对象(堆内存),所有线程创建的实例对象都存放在主内存中,不管该实例对象是成员变量还是方法中的本地变量(也称局部变量),当然也包括了共享的类信息、常量、静态变量。由于是共享数据区域,多条线程对同一个变量进行访问可能会发生线程安全问题。

    工作内存

    主要存储当前方法的所有本地变量信息(工作内存中存储着主内存中的变量副本拷贝),每个线程只能访问自己的工作内存,即线程中的本地变量对其它线程是不可见的,就算是两个线程执行的是同一段代码,它们也会各自在自己的工作内存中创建属于当前线程的本地变量,也包括了字节码行号指示器、相关Native方法的信息(也就是栈帧)。注意由于工作内存是每个线程的私有数据,线程间无法相互访问工作内存,因此存储在工作内存的数据不存在线程安全问题。(如上图所示)

     

    JMM模型与硬件内存

    毋庸置疑的是,多线程的执行最终都是归于硬件处理器去执行的。

    对于硬件内存来说只有寄存器、缓存内存、主内存的概念,并没有工作内存(线程私有数据区域)和主内存(堆内存)之分,也就是说JMM对内存的划分对硬件内存并没有任何影响。

    而JMM只是一种抽象的概念和规则,并没有实际存在,不管是在工作内存还是主内存的数据,在计算机硬件的层次上都是存储在计算机主内存中的,或者是可能存储在CPU缓存或者寄存器上。

    总的来说,JMM和硬件内存是一个相互交叉的关系,是一种抽象概念与真实物理硬件的交叉。

    概念图:

     

     

    JMM模型的重要性

    引言

    在JVM中,运行程序的实体是线程,而每个线程创建时,JVM都会为其创建一个工作内存(栈空间),用于存放现场私有的数据,而现场对于主内存的变量操作必须通过在其工作内存中操作完成。

    大概过程是:

    • 从主内存中拷贝需要的变量数据到线程的工作内存空间
    • 在工作内存中对变量进行操作
    • 操作完成后,再将变量写回主内存中(同步)

    暂引出问题:

    如果此时有两个甚至多个线程同时处理主内存中的某个变量,如x=1时,则可能诱发线程安全问题, 该如何解决呢?

     

    数据同步的八大原子操作

    定义

    关于主内存与工作内存之间的交互协议,即一个变量如何从主内存拷贝到工作内存。如何从工作内存同步到主内存中的实现细节。java内存模型定义了8种操作来完成,这8种操作每一种都是原子操作。

    (1)lock(锁定):作用于主内存的变量,把一个变量标记为一条线程独占状态

    (2)unlock(解锁):作用于主内存的变量,把一个处于锁定状态的变量释放出来,释放后的变量才能被其他线程锁定

    (3)read(读取):作用于主内存的变量,把一个变量值从主内存传输到线程的工作内存中,以便随后的load动作使用

    (4)load(载入):作用于工作内存的变量,它把read操作从主内存中得到的变量值放入工作内存的变量副本中

    (5)use(使用):作用于工作内存的变量,把工作内存中的一个变量值传递给执行引擎

    (6)assign(赋值):作用于工作内存的变量,它把一个从执行引擎接收到的值赋给工作内存的变量

    (7)store(存储):作用于工作内存的变量,把工作内存中的一个变量的值传送到主内存中,以便随后的write的操作

    (8)write(写入):作用于工作内存的变量,它把store操作从工作内存中的一个变量的值传送到主内存的变量中

     

    大致过程:

    规则

    1、不允许read和load、store和write操作之一单独出现(即不允许一个变量从主存读取了但是工作内存不接受,或者从工作内存发起会写了但是主存不接受的情况),以上两个操作必须按顺序执行,但没有保证必须连续执行,也就是说,read与load之间、store与write之间是可插入其他指令的。
    2、不允许一个线程丢弃它的最近的assign操作,即变量在工作内存中改变了之后必须把该变化同步回主内存
    3、不允许一个线程无原因地(没有发生过任何assign操作)把数据从线程的工作内存同步回主内存中。
    4、一个新的变量只能从主内存中“诞生”,不允许在工作内存中直接使用一个未被初始化(load或assign)的变量,换句话说就是对一个变量实施use和store操作之前,必须先执行过了assign和load操作。
    5、一个变量在同一个时刻只允许一条线程对其执行lock操作,但lock操作可以被同一个条线程重复执行多次,多次执行lock后,只有执行相同次数的unlock操作,变量才会被解锁。
    6、如果对一个变量执行lock操作,将会清空工作内存中此变量的值,在执行引擎使用这个变量前,需要重新执行load或assign操作初始化变量的值。
    7、如果一个变量实现没有被lock操作锁定,则不允许对它执行unlock操作,也不允许去unlock一个被其他线程锁定的变量。
    8、对一个变量执行unlock操作之前,必须先把此变量同步回主内存(执行store和write操作)。

     

     

    并发三大特性

    原子性

    定义:即一个操作或者多个操作,要么全部执行并且执行的过程不会被任何因素打断,要么就都不执行。

    注:Java里,对基本数据类型的变量的读取和赋值操作是原子性操作有点要注意的是,对 于32位系统的来说,long类型数据和double类型数据(对于基本数据类型,byte,short,int,float,boolean,char读写是原子操作),它们的读写并非原子性的,因为对于32位虚拟机来说,每次原子读写是32位的,而long和double则是64位的存储单元。可能会出现不同现场读取数值不同的情况,如一个线程读的前32位,另一个线程读的后32位。

    可见性

    定义:当一个线程修改了某个共享变量的值,其他线程是否能够马上得知这个修改的值。对于串行程序来说,可见性是不存在的,因为我们在任何一个操作中修改了某个变量的值,后续的操作中都能读取这个变量值,并且是修改过的新值。

    引出:从JMM模型中可以看出,当多线程操作时可能会出现问题,当某一个线程修改了某个共享变量时,另一个线程也在修改的话,哪一个线程最先修改完,且怎么通知另一个正在修改的线程是一个问题?因为数据同步回主内存是有一定的延迟的。以及指令重排、编译器优化等也可能导致可见性问题。

    有序性

    定义:指对于单线程的执行代码,我们总是认为代码的执行是按顺序依次执行的,这样的理解并没有毛病,毕竟对于单线程而言确实如此,但对于多线程环境,则可能出现乱序现象,因为程序编译成机器码指令后可能会出现指令重排现象,重排后的指令与原指令的顺序未必一致。

     

    JMM与三大特性

    实现原子性

    JVM自身提供的对基本数据那些读写操作可保证原子性。synchronized和Lock(保证任一时刻只有一个线程可访问某一处代码)可实现原子性。

    实现可见性

    volatile关键字可实现可见性(类似通知功能,通知别的线程)。synchronized和Lock也可保证可见性(原子性基础上,释放锁之前会刷新值到内存中)。

    实现有序性

    volatile关键字可保证一定的有序性(内存屏障、happens-before)。synchronized和Lock也可保证有序性(线程加锁,相当于顺序执行)

     

    指令的重排序

    java语言规范规定JVM线程内部维持顺序化语义。即只要程序的最终结果与它顺序化情况的结果相等,那么指令的执行顺序可以与代码顺序不一致,此过程叫指令的重排序。

    指令重排序的意义是什么?JVM能根据处理器特性(CPU多级缓存系统、多核处理器等)适当的对机器指令进行重排序,使机器指令能更符合CPU的执行特性,最大限度的发挥机器性能以提高运行效率

     

     

    重排序分三种类型(排序即顺序):

    1.编译器优化的重排序

    编译器在不改变单线程程序语义的前提下(代码中不包含synchronized关键字),可以重新安排语句的执行顺序。

    2.指令级并行的重排序

    现代处理器采用了指令级并行技术(Instruction-Level Parallelism, ILP)来将多条指令重叠执行。如果不存在数据依赖性,处理器可以改变语句对应机器指令的执行顺序。

    3.内存系统的重排序
    由于处理器使用缓存和读/写缓冲区,这使得加载和存储操作看上去可能是在乱序执行

     

    as-if-serial原则

    as-if-serial语义的意思是:不管怎么重排序(编译器和处理器为了提高并行度),(单线程)程序的执行结果不能被改变。编译器、runtime和处理器都必须遵守as-if-serial语义。

    为了遵守as-if-serial语义,编译器和处理器不会对存在数据依赖关系的操作做重排序,因为这种重排序会改变执行结果。但是,如果操作之间不存在数据依赖关系,这些操作就可能被编译器和处理器重排序。

    如: a=1;b=a ; 先给a赋值为1(a初始为0),假设重排了变成b=a ;a=1;那b的值不是一致的,则不会重排。

     

    happens-before原则

    cpu的运行极快,而读取主存对于cpu而言有点慢了,在读取主存的过程中cpu一直闲着(也没数据可以运行),这对资源来说造成极大的浪费。所以慢慢的cpu演变成了多级cache结构,cpu在读cache的速度比读内存快了n倍。当线程在执行时,会保存临界资源的副本到私有work memory中,这个memory在cache中,修改这个临界资源会更新work memory但并不一定立刻刷到主存中,那么什么时候应该刷到主存中呢?什么时候和其他副本同步?而且编译器为了提高指令执行效率,是可以对指令重排序的,重排序后指令的执行顺序不一样,有可能线程2读取某个变量时,线程1还未进行写入操作。这就是线程可见性的来源,解决办法就是happens-before规则

     

    定义

    • 如果操作1 happens-before 操作2,那么操作1的执行结果将对操作2可见,而且操作1的执行顺序排在操作2之前。
    • 两个操作之间存在happens-before关系,并不意味着一定要按照happens-before原则制定的顺序来执行。如果重排序之后的执行结果与按照happens-before关系来执行的结果一致,那么这种重排序并不非法。

     

    八大原则

    • 程序顺序原则:在一个线程内必须保证语义的串行行,即按照代码书写的顺序执行语句。
    • 锁定规则:一个解锁(unlock)操作先行发生于后面对同一个锁的加锁(lock)操作。即无论在单线程还是多线程中,同一个锁如果处于被锁定状态,那么必须先对锁进行解锁,后面才能继续执行加锁操作。
    • volatile规则:对于一个被volatile修饰的变量,写操作先行于读操作。这就可以保证变量的可见性,当volatile变量被线程访问时,都需要从主内存中读取;当某个线程已经修改了volatile变量时,会强行将最新的值刷新到主内存,同时某些线程读取了之前的值会被通知作废,别的线程总是能读取到最新的值。
    • 传递规则:操作A先行与操作B,操作B先行与操作C,那么操作A先行与操作C。
    • 线程启动规则:Thread对象的start()方法先行发生于此线程的每一个动作。如果线程A在线程B start之前修改了主内存中的变量C(共享的),那么线程B start后,也可以看到修改后的变量C值。
    • 线程中断规则:对线程interrupt()方法的调用先行发生于被中断线程的代码检测到中断事件的发生。
    • 线程终止规则:线程中所以的操作都先行发生于线程的终止检测,通过Thread.join()方法(等待当前执行的线程终止)、Thread.isAlive()的返回值手段检测到线程已经终止执行。
    • 对象终结规则:一个对象的初始化完成先行于它的finalize(()方法的开始。
    我始终记住:青春是美丽的东西,而且对我来说,它永远是鼓舞的源泉。——(现代)巴金
  • 相关阅读:
    HTML DOM教程 9HTML DOM Window 对象
    HTML DOM教程 11HTML DOM Screen 对象
    Android项目中把bin文件夹里面的.apk文件删除,怎么让它再生成
    Qt把ping www.baidu.com之后的内容的内容输出到一个名为output的文档
    Qt之QProcess 和 c语言对比
    Git的Windows版本Msysgit的中文乱码解决
    多系统 grub之ubuntu的 grub
    QT中调用外部程序:QProcess的使用
    repo的小结
    恢复Ubuntu默认的面板
  • 原文地址:https://www.cnblogs.com/flyinglion/p/15077525.html
Copyright © 2011-2022 走看看