深入并发编程底层原理

声明:尊重他人劳动成果,转载请附带原文链接!学习交流,仅供参考!

1、什么是底层原理?为什么要研究底层原理?

在平常,我们写一个java程序,写完后,接下来就该运行此程序,控制台也会输出和我们想要的结果。但是你知道我们将程序运行起来后,背后做了什么吗?这里详细讲解一下:

1、最开始,我们编写的Java代码,是*.java文件
2、在使用javac命令编译后,从刚才的*.java文件会变成一个新的Java字节文件*.class
3、JVM会执行刚才编译好的字节码*.class文件,并且把字节码文件转化为机器指令
4、机器指令可以直接在CPU上运行,也就是最终的程序执行。

在这里做个假设,如果我们不知道其中背后的原理,当我们在windows上运行代码,可能并没有任何问题,但当拿到其他操作系统的时候,出现了问题,这时候则不是无能为力,所谓这就是我们为什么要研究底层原理!

2、JVM内存结构、Java内存模型、Java对象模型有什么区别?

2.1、什么是JVM内存结构?(Java Virtual Model,JVM)

对于Java程序员来说,在虚拟机自动内存管理机制的帮助下,不再需要手动释放内存,不容易出现内存泄露和内存溢出问题。一旦出现内存泄露和溢出方面的问题,如果不了解虚拟机是怎样使用内存的,排查错误将会异常艰难。

JVM的内部结构如下图所示
<<深入理解Java虚拟机>>这本书讲的很清楚,它是和Java虚拟机的运行区域有关。
在这里插入图片描述

2.1.1 程序计数器:

  它是一块较小的内存空间,它可以看作是当前线程所执行的字节码的行号指示器,在Java虚拟机的概念模型里,字节码解释器工作时就是通过改变这个计数器的值来选取下一条需要执行字节码指令,它是程序控制流的指示器等。
  由于Java虚拟机的多线程是通过线程轮流切换并分配处理器执行时间的方式来实现的,在任何一个确定的时刻,一个处理器都只会执行一条线程中的指令。因此,为了线程切换后能恢复到正确的执行位置,每条线程都需要有一个独立的程序计数器,各条线程之间计数器互不影响,独立存储,我们称这类内存区域为“线程私有”的内存。
如果线程正在执行的是一个Java方法,这个计数器记录的是正在执行的虚拟机字节码指令的地址;如果正在执行的是Native方法,这个计数器值则为空(Undefined)。此内存区域是唯一 一个在Java虚拟机规范中没有规定OutOfMemoryError情况的区域

2.1.2 Java虚拟机栈

  与程序计数器一样,Java虚拟机栈(Java Virtual Machine Stacks)也是线程私有的,它的生命周期与线程相同。虚拟机栈描述的是Java方法执行的内存模型:每个方法在执行的同时都会创建一个栈帧(Stack Frame)用于存储局部变量表、操作数栈、动态链接、方法出口等信息。每一个方法从调用直至执行完成的过程,就对应着一个栈帧在虚拟机栈中入栈到出栈的过程。
  经常有人把Java内存区分为堆内存(Heap)栈内存(Stack),其中所指的“堆”就是Java堆,而所指的“栈”就是现在所讲的虚拟机栈,或者说是虚拟机栈中局部变量表部分。
局部变量表存放了编译期可知的各种基本数据类型(boolean、byte、char、short、int、float、long、double)、对象引用(reference类型,它不等同于对象本身,可能是一个指向对象起始地址的引用指针,也可能是指向一个代表对象的句柄或其他与此对象相关位置)和returnAddress类型(指向了一条字节码指令的地址)。
  其中64为长度的long和double类型的数据会占用2个局部变量空间(Slot),其余的数据类型只占用1个。局部变量表所需的内存空间在编译期间完成分配,当进入一个方法时,这个方法需要在帧中分配多大的局部变量空间是完全确定的,在方法运行期间不会改变局部变量表的大小。
  在Java虚拟机规范中,对这个区域规定了两种异常状况:如果线程请求的栈深度大于虚拟机所允许的深度,将抛出StackOverflowError异常;如果虚拟机栈可以动态扩展(当前大部分的Java虚拟机都可动态扩展,只不过Java虚拟机规范中也允许固定长度的虚拟机栈),如果扩展时无法申请到足够的内存,就会抛出OutOfMemoryError异常。

2.1.2 本地方法栈

  本地方法栈(Native Method Stack)与虚拟机栈所发挥的作用是非常相似的,它们之间的区别不过是虚拟机栈为虚拟机执行Java方法(也就是字节码)服务,而本地方法栈则为虚拟机使用到的Native方法服务。在虚拟机规范中对本地方法栈中方法使用的语言、使用方式与数据结构并没有强制规定。HotSpot虚拟机直接把本地方法栈和虚拟机栈合二为一。与虚拟机栈一样,本地方法栈区域也会抛出StackOverflowErrorOutOfMemoryError异常。

2.1.3 Java堆

  对于大多数应用来说,Java堆(Java Heap)是Java虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域,在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例,几乎所有的对象实例都在这里分配内存。这一点在Java虚拟机规范中的描述是:所有的对象实例以及数组都要在堆上分配,但是随着JIT编译器的发展以及逃逸分析技术逐渐成熟,栈上分配、标量替换优化技术将会导致一些微妙的变化发生,所有的对象都分配在堆上也渐渐变得不是那么“绝对”了。
  Java堆是垃圾收集器管理的主要区域,因此很多时候也被称做“GC堆”(Garbage Collected Heap)。从内存回收的角度来看,由于现在收集器基本都采用分代收集算法,所以Java堆中还可以细分为:新生代和老年代;再细致一点的,新生代可以有Eden空间、From Survivor空间、To Survivor空间等。从内存分配的角度来看,线程共享的Java堆中可能划分出多个线程私有的分配缓冲区(Thread Local Allocation Buffer,TLAB)。不过无论如何划分,都与存放内容无关,无论哪个区域,存储的都仍然是对象实例,进一步划分的目的是为了更好地回收内存,或者更快地分配内存。
  根据Java虚拟机规范的规定,Java堆可以处于物理上不连续的内存空间中,只要逻辑上是连续的即可,就像我们的磁盘空间一样。在实现时,既可以实现成固定大小的,也可以是扩展的,不过当前主流的虚拟机都是按照可扩展来实现的(通过-Xmx和-Xms控制)。如果在堆中没有内存完成实例分配,并且堆也无法再扩展时,将会抛出OutOfMemoryError异常。

2.1.4 方法区(永久代)

  方法区(Method Area)与Java堆一样,是各个线程共享的内存区域,它用于存储已被虚拟机加载的类信息、常量、静态变量、即时编译器编译后的代码等数据,即存放静态文件,如Java类、方法等。虽然Java虚拟机规范把方法区描述为堆的一个逻辑部分,但是它却有一个别名叫做Non-Heap(非堆),目的应该是与Java堆区分开来。
  对于习惯在HotSpot虚拟机上开发、部署程序的开发者来说,很多人都更愿意把方法区称为“永久代”(Permanent Generation),本质上两者并不等价,仅仅是因为HotSpot虚拟机的设计团队选择把GC分代收集扩展至方法区,或者说使用永久代来实现方法区而已,这样HotSpot的垃圾收集器可以像管理Java堆一样管理这部分内存、能够省去专门为方法区编写内存管理代码的工作。
  根据Java虚拟机规范的规定,当方法区无法满足内存分配需求时,将抛出OutOfMemoryError异常。

2.2 什么Java内存模型?(Java Memory Model,JMM)

  它是一组规范,用来屏蔽掉各种硬件和操作系统的差异,让Java程序在各种平台上都能达到一致的效果。需要各个JVM都需要遵守这种规范,这样我们开发者才能更好地开发多线程程序。
  假如没有这样的规范,那么很可能经过了不同的JVM的不同规则的重排序之后,导致不同的虚拟机上运行的结果不一样,那就会出现很大的问题!
  例如:无法保证并发安全依赖处理器,不同处理器结果不一样、所以我们就需要一种规范,让多线程运行的结果可预期。
volatilesynchronizedLock等原理都是JMM
假如没有了JMM,那就需要我们自己指定什么时候用内存栅栏等,那是相当麻烦的,幸好有了JMM,让我们只需要用同步工具与关键字就可以开发并发程序。

2.3 什么是Java对象模型?

  和Java对象在虚拟机中的表现形式有关。
在这里插入图片描述
JVM会给这个类创建一个instanceKlass,保存在方法区,用在JVM层表示该java类。当我们在Java代码中,使用new创建一个对象的时候,JVM会创建一个instanceOopDesc对象,这个对象中包含了对象头以及实例数据。

3、什么是重排序?

  假设我们写了一个 Java 程序,包含一系列的语句,我们会默认期望这些语句的实际运行顺序和写的代码顺序一致。
  但实际上,编译器、JVM 或者 CPU 都有可能出于优化等目的,对于实际指令执行的顺序进行调整,这就是重排序。
重排序的好处:提高处理速度

4、什么是可见性?

先用代码举出什么是可见性:

public class Demo {
    
    
    int x = 1, y = 2;

    public void changeNum() {
    
    
        x = 3;
        y = x;
    }

    public void printNum() {
    
    
        System.out.println("x=" + x + ",y=" + y);
    }

    public static void main(String[] args) throws InterruptedException {
    
    
        while (true) {
    
    
            Demo demo = new Demo();
            // 线程一
            Thread one = new Thread(new Runnable() {
    
    
                @Override
                public void run() {
    
    
                    demo.changeNum();
                }
            });
            // 线程二
            Thread twe = new Thread(new Runnable() {
    
    
                @Override
                public void run() {
    
    
                    demo.printNum();
                }
            });
            one.start();
            twe.start();

        }
    }
}

结果应该是四种情况:

1、线程one先执行,执行结果为x=3,y=3
2、线程twe先执行,执行结果为x=1,y=2
3、由于没有加同步关键字,就有可能当线程one执行到x=3,然后线程twe就开始执行,执行结果为x=3,y=2
4、还有种情况就是线程one确实已经修改完了x=3,y=3,但是结果执行结果还是x=1,y=2

上面前三种情况很容易得出结论,但是为什么还有第四种情况呢?这就是可见性的原因。

5、为什么出现可见性?JMM的抽象、主内存与本次内存详解?

在这里插入图片描述

因为由于CPU执行指令的速度是很快的,但是内存访问的速度就慢了很多,相差的不是一个数量级,所以搞处理器的那群人又在CPU里加了好几层高速缓存。然后由于每个核心都将自己需要的数据读到独占缓存中,数据修改后也是写入缓存中,然后等待刷入到主存中。所以会导致有些核心读取的值是一个过期的值。

由于Java是高级语言,屏蔽了这些底层细节,就不再让我们关心这些层级缓存、寄存器,JMM就抽象出主内存和本地内存。(本地内存不是给每个线程分配的内存,而是对于那些层级缓存、寄存器等的抽象)

在这里插入图片描述

主内存和本地内存的关系
1、所有的变量都存储在主内存中,同时每个线程也有自己独立的工作内存,工作内存的变量其实就是拷贝的主内存中的变量
2、线程不能直接去读写主内存中的变量,只能操作自己工作内存中的变量,然后再同步到主内存中
3、主内存是多个线程共享的,但线程之间不共享工作内存,如果线程之间需要通信,就必须借助主内存中转来完成

所以是由于共享变量是在主内存中,每个线程都有自己的本地内存,而且读写共享数据也是通过本地内存来交换的,所以可能才导致了可见性问题。

6、如何解决可见性?

可以用volitile 、synchronized关键字、Lock关键字、happens-before原则中的都可以解决可见性
一文了解volatile关键字
一文了解synchronized关键字

7、happens-before原则?

happens-before原则是用来解决可见性问题的,意思就是:在执行时间上,如果动作A发生在动作B之前,那么B保证能看见A 。在JMM中,happens-before的意思是前一个操作的结果可以被后续操作获取。

总结:

参考资料:

《深入理解Java虚拟机 JVM高级特性与最佳实践》第三版

Guess you like

Origin blog.csdn.net/qq_40805639/article/details/120999967