深入理解JVM第八章笔记

深入理解JVM第八章笔记

背景

执行引擎是JVM最核心的组成部分之一,“虚拟机”是一个相对于“物理机”的概念,这两种机器都有代码执行的能力,区别是物理机的执行引擎是直接建立在处理器,硬件,指令集,操作系统层面上的,而虚拟机的执行引擎则是由自己实现的。所以可以自行制定指令集与执行引擎的结构体系。

运行时栈帧

每一个线程都有一个栈,也就是前文中提到的虚拟机栈,栈中的基本元素我们称之为栈帧。

栈帧是用于支持虚拟机进行方法调用和方法执行的数据结构。每个栈帧都包括了一下几部分:

  • 局部变量表

  • 操作数栈

  • 动态连接

  • 方法的返回地址

  • 一些额外的附加信息

栈帧中需要多大的局部变量表和多深的操作数栈在编译代码的过程中已经完全确定,并写入到方法表的Code属性中。在活动的线程中,位于当前栈顶的栈帧才是有效的,称之为当前帧,与这个栈帧相关联的方法称为当前方法。执行引擎运行的所有字节码指令只针对当前栈帧进行操作。需要注意的是一个栈中能容纳的栈帧是受限,过深的方法调用可能会导致StackOverFlowError,当然,我们可以认为设置栈的大小。

图示:

图1.png

局部变量表

变量值的存储空间,由方法参数和方法内部定义的局部变量组成,其容量用Slot1作为最小单位。

在编译期间,就在方法的Code属性的max_locals数据项中确定了该方法所需要分配的局部变量表的最大容量。

由于局部变量表是建立在线程的栈上,是线程的私有数据,因此不存在数据安全问题。在方法执行时,虚拟机通过使用局部变量表完成参数值到参数变量列表的传递过程。

如果是实例方法,那局部变量表第0位索引的Slot存储的是方法所属对象实例的引用,因此在方法内可以通过关键字this来访问到这个隐含的参数。其余的参数按照参数表顺序排列,参数表分配完毕之后,再根据方法体内定义的变量的顺序和作用域分配。

我们知道类变量表有两次初始化的机会,第一次是在“准备阶段”,执行系统初始化,对类变量设置零值,另一次则是在“初始化”阶段,赋予程序员在代码中定义的初始值。和类变量初始化不同的是,局部变量表不存在系统初始化的过程,这意味着一旦定义了局部变量则必须人为的初始化,否则无法使用

操作数栈

操作数栈也叫操作栈,是一个后入先出的栈,同局部变量表一样,操作数栈的最大深度也在编译的时候写入到Code属性的max_stacks数据项中。

操作数栈的每一个元素可以是任意的Java数据类型,包括long和double,在方法执行的任何时候,操作数栈的深度都不会超过在max_stacks数据项中设定的最大值。

在方法的执行过程中,会有各种字节码指令往操作数中写入和提取内容,也就是出栈/入栈操作。操作数栈中元素的数据类型必须与字节码指令的序列严格匹配,这由编译器在编译器期间进行验证,同时在类加载过程中的类检验阶段的数据流分析阶段要再次验证。另外我们说Java虚拟机的解释引擎是基于栈的执行引擎,其中的栈指的就是操作数栈。

动态连接

每个栈帧都包含一个指向运行时常量池中该栈帧所属方法的引用,持有该引用是为了支持方法调用过程中的动态连接。

class文件的常量池中存有大量的符号引用,字节码中的方法调用指令就以常量池中指向方法的符号引用作为参数:

  • 这些符号引用一部分会在类加载阶段或者第一次使用的时候就转化为直接引用,这种转化叫做静态解析

  • 另外一部分将在每一次运行期间转化为直接引用,叫做动态连接

方法返回地址

存放调用该方法的pc计数器的值。当一个方法开始之后,只有两种方式可以退出这个方法:

  • 1、执行引擎遇到任意一个方法返回的字节码指令,也就是所谓的正常完成出口

  • 2、在方法执行的过程中遇到了异常,并且这个异常没有在方法内进行处理,也就是只要在本方法的异常表中没有搜索到匹配的异常处理器,就会导致方法退出,这种方式成为异常完成出口。

正常完成出口和异常完成出口的区别在于:通过异常完成出口退出的不会给他的上层调用者产生任何的返回值

无论通过哪种方式退出,在方法退出后都返回到该方法被调用的位置,方法正常退出时,调用者的pc计数器的值作为返回地址,而通过异常退出的,返回地址是要通过异常处理器表来确定,栈帧中一般不会保存这部分信息。本质上,方法的退出就是当前栈帧出栈的过程。

方法调用

方法调用并不等于方法执行,方法调用阶段的唯一任务就是:

确定被调用方法的版本(调用哪一个方法?),暂时不涉及方法内部的具体运行过程

Class文件的编译过程中不包含传统编译中的连接步骤,一切方法调用在Class文件中存储的都只是符号引用,而不是方法在实际运行时内存布局的入口地址(相当于之前的直接引用)

这个特性个Java带来了更强大的动态扩展能力,但也使得Java方法调用过程更加复杂,需要在类加载期间,甚至到运行期间才能确定目标方法的直接引用。

解析

在Class文件中,所有方法调用中的目标方法都是常量池中的符号引用,在类加载的解析阶段,会将一部分符号引用转为直接引用,也就是在编译阶段就能够确定唯一的目标方法,这类方法的调用成为解析调用。此类方法主要包括静态方法和私有方法两大类,前者与类型直接关联,后者在外部不可访问,因此决定了他们都不可能通过继承或者别的方式重写该方法,符合这两类的方法主要有以下几种:

  • 静态方法

  • 私有方法

  • 实例构造器

  • 父类方法

虚拟机中提供了以下几条方法调用指令:

  • invokestatic:调用静态方法,解析阶段确定唯一方法版本

  • invokespecial:调用 < init > 方法、私有及父类方法,解析阶段确定唯一方法版本

  • invokevirtual:调用所有虚方法

  • invokeinterface:调用接口方法

  • invokedynamic:动态解析出需要调用的方法,然后执行

前四条指令固化在虚拟机内部,方法的调用执行不可认为干预,而invokedynamic指令则支持由用户确定方法版本。

其中invokestatic指令和invokespecial指令调用的方法称为非虚方法,其余的(final修饰的除外)称为虚方法。

解析调用一个是个静态的过程,在编译期间就完全确定,在类加载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用,不会延迟到运行期间再去完成

而分派引用则可能是静态的也可能是动态的,根据分派依据的宗教数可分为:

  • 单分派

  • 多分派

分派

静态分派

例子:



public class StaticDispatch {

    /*

    方法静态分派演示

     */

    static abstract class Human {

    }


    static class Man extends Human {

    }

    static class Woman extends Human {

    }

    public void sayHello(Human guy) {
        System.out.println("hello guy");
    }

    public void sayHello(Man guy) {
        System.out.println("hello gentleman");
    }

    public void sayHello(Woman guy) {
        System.out.println("hello lady");
    }

    public static void main(String[] args) {

        Human man = new Man();

        Human woman = new Woman();

        StaticDispatch staticDispatch = new StaticDispatch();

        staticDispatch.sayHello(man);

        staticDispatch.sayHello(woman);

        /*

        Human man = new Man()

        Human 变量的静态类型  或者叫  外观类型


        Man  变量的实际类型

        静态和实际类型在程序中都可以发生变化

        区别是

        静态:

        仅仅在使用时发生 变量本身的静态类型不会被改变 并且最终的静态类型在编译期是可知的

        实际类型变化的结果在运行期才可以确定

        编译器在编译程序时并不知道一个对象的实际类型是什么

        // 实际类型变化

        Human man = new Man();

        man = new Woman();

        // 静态类型变化

        sr.sayHello( (Man) man);

        sr.sayHello( (Woman) man);



        上面例子中:

        main中的两次sayHello方法调用

        在方法接受者已经确定对象是staticDispatch的前提下

        使用哪个重载版本,就完全取决于参数的数量和数据类型

        代码中刻意定义两个:

        静态类型相同  实际类型不同的变量

        但是编译器在重载时是通过参数的静态类型而不是实际类型作为判断依据的

        并且静态类型是编译器可知的

        因此,编译阶段,Javac编译器会根据参数的静态类型决定使用哪个重载版本

        所以选择了sayHello(Human)作为调用目标

         */

    }

}



所有依赖静态类型来定位方法执行版本的分派动作叫做—静态分派。

静态分派的典型应用:方法重载

静态分派发生在编译阶段,因此确定静态分派的动作实际上不是由虚拟机来执行的。

动态分派

动态分派与多态的另外一个重要体现—重写有密切联系

定义:根据 变量的动态类型 进行方法分派 的 行为

例子:



public class DynamicDispatch {


/*
方法动态分派演示
 */
    static abstract class Human {
        protected abstract void sayHello();
    }

    static class Man extends Human {


        @Override
        protected void sayHello() {
            System.out.println("man say hello");
        }
    }

    static class Woman extends Human {


        @Override
        protected void sayHello() {
            System.out.println("woman say hello");
        }
    }

    public static void main(String[] args) {

        Human man = new Man();

        Human woman = new Woman();

        man.sayHello();

        woman.sayHello();

        man = new Woman();

        man.sayHello();

        /*

        man say hello
        woman say hello
        woman say hello


         */

        /*

        这里不可能再根据静态类型来决定了

        因为静态类型同样都是 Human 的两个变量man 和woman在调用

        sayhello方法时执行了不同的行为

        并且变量man在两次调用中执行了不同的方法

        导致这个现象的原因很明显

        因为两个变量的实际类型不同

         */

    }


}


动态分派在Java中被大量使用,使用频率及其高,如果在每次动态分派的过程中都要重新在类的方法元数据中搜索合适的目标的话就可能影响到执行效率,因此JVM在类的方法区中建立虚方法表(virtual method table)来提高性能。

每个类中都有一个虚方法表,表中存放着各个方法的实际入口。如果某个方法在子类中没有被重写,那子类的虚方法表中该方法的地址入口和父类该方法的地址入口一样,即子类的方法入口指向父类的方法入口。如果子类重写父类的方法,那么子类的虚方法表中该方法的实际入口将会被替换为指向子类实现版本的入口地址。 那么虚方法表什么时候被创建?虚方法表会在类加载的连接阶段被创建并开始初始化,类的变量初始值准备完成之后,JVM会把该类的方法表也初始化完毕。

类型 分派原理 发生阶段 应用场景
静态分派 根据 变量的静态类型 编译器(不由JVM执行) Overload(方法重载)
动态分派 根据 变量的动态类型 运行期(JVM执行) Override(方法重写)

单分派与多分派

宗量的概念:

方法的接受者与方法的参数统称为方法的宗量

根据分派基于多少种宗量,可以将分派划分为单分派和多分派两种:

  • 单分派依据一个宗量对目标方法进行选择

  • 多分派根据多于一个宗量对目标方法进行选择

基于栈的字节码解释执行引擎

虚拟机是如何执行方法内部的字节码指令的?许多JVM的执行引擎在执行Java代码的时候有两种选择:

  • 解释执行:通过解释器执行

  • 编译执行:通过即时编译器产生本地代码执行

解释执行

在jdk 1.0时代,Java虚拟机完全是解释执行的,随着技术的发展,现在主流的虚拟机中大都包含了即时编译器(JIT)。因此,虚拟机在执行代码过程中,到底是解释执行还是编译执行,只有它自己才能准确判断了,但是无论什么虚拟机,其原理基本符合现代经典的编译原理

编译过程:

图2.png

在Java中,javac编译器完成了词法分析、语法分析以及抽象语法树的过程,最终遍历语法树生成线性字节码指令流的过程,此过程发生在虚拟机外部。

基于栈的指令集与基于寄存器的指令集

Java编译器输入的指令流基本上是一种基于栈的指令集架构,指令流中的指令大部分是零地址指令,其执行过程依赖于操作栈。

另外一种指令集架构则是基于 寄存器 的指令集架构,典型的应用是x86的二进制指令集,比如传统的PC以及Android的Davlik虚拟机。

两者之间最直接的区别是:

基于栈的指令集架构不需要硬件的支持,而基于寄存器的指令集架构则完全依赖硬件,这意味基于寄存器的指令集架构执行效率更高,单可移植性差,而基于栈的指令集架构的移植性更高,但执行效率相对较慢,除此之外,相同的操作,基于栈的指令集往往需要更多的指令

参考资料

<<深入理解Java虚拟机>>

https://blog.csdn.net/suifeng629/article/details/82349784

发布了229 篇原创文章 · 获赞 62 · 访问量 19万+

猜你喜欢

转载自blog.csdn.net/Coder_py/article/details/104892431
今日推荐