JVM动态分派、静态分派

最新推荐文章于 2023-06-27 17:43:57 发布

懒惰的吴Sir

最新推荐文章于 2023-06-27 17:43:57 发布

阅读量320

点赞数

分类专栏： JVM 文章标签： jvm java 开发语言 Powered by 金山文档

本文链接：https://blog.csdn.net/weixin_58321767/article/details/128927282

版权

JVM 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

java是一门面向对象的程序语言，因为java具备面向对象的3个基本特征：继承、封装和多态。

分派调用过程中将会揭示多态特征的一些最基本的体现，如“重载”和“重写”在java虚拟机之中是如何实现的。

1.静态分派

静态分派代码演示

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 sr = new StaticDispatch();
        sr.sayHello((Man) man);
        sr.sayHello(woman);
    }
}

运行结果：

hello,guy!

 Human man = new Man();

我们把上面代码中的“Human”称为变量的静态类型（Static Type），或者叫做的外观类型(Apparent Type），后面的“Man”则称为变量的实际类型（Actual Type），静态类型和实际类型在程序中都可以发生一些变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的；而实际类型变化的结果在运行期才可确定，编译器在编译程序的时候并不知道一个对象的实际类型是什么。例如下面的代码

        //实际类型变化
        Human man = new Man();
        man = new Woman();
        //静态类型变化
        sr.sayHello((Man) man);
        sr.sayHello((Woman) man);

在main( )里面的两次sayHello( )方法调用，在方法接收者已经确定是对象“sr”的前提下，使用哪个重载版本，就完全取决于传入参数的数量和数据类型。代码中刻意地定义了两个静态类型相同但实际类型不同的变量，但虚拟机（准确地说是编译器）在重载时是通过参数的静态类型而不是实际类型作为判定依据的。并且静态类型是编译期可知的，因此，在编译阶段，Javac编译器会根据参数的静态类型决定使用哪个重载版本，所以选择了sayHello(Human)作为调用目标，并把这个方法的符号引用写到main()方法里的两条invokevirtual指令的参数中。所有依赖静态类型来定位方法执行版本的分派动作称为静态分派。

静态分派的典型应用是方法重载。静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行的。另外，编译器虽然能确定出方法的重载版本，但在很多情况下这个重载版本并不是“唯一的”，往往只能确定一个“更加合适的”版本。产生这种模糊结论的主要原因是字面量不需要定义，所以字面量没有显式的静态类型，它的静态类型只能通过语言上的规则去理解和推断。在继承关系中从下往上开始搜索，越接近上层优先级越低。

另外，静态方法也会类加载期就进行解析，而静态方法显然也是可以拥有重载版本的，选择重载版本的过程也是通过静态分派完成的

2.动态分派

动态态分派代码演示

public class DynamicDispatch {

    static abstract class Human {
        protected abstract void say();
    }

    static class Man extends Human {
        @Override
        protected void say() {
            System.out.println("Man");
        }
    }

    static class Woman extends Human {
        @Override
        protected void say() {
            System.out.println("Woman");
        }
    }


    public static void main(String[] args) {
        Human man = new Man();
        Human woman = new Woman();
        man.say();
        woman.say();
        man = new Woman();
        man.say();
    }
}

运行结果：

Man

Woman

显然这里不是采用静态类型来决定的，因为静态类型都是Human的2个变量man和woman调用say()方法执行了不同的版本，原因很明显，2个变量的实际类型不同，Java虚拟机根据将符号引用转成直接引用的过程中产生了不同的解析，而这也是Java语言中重写的本质，这种运行期间根据实际类型确定方法调用版本的分派过程称为动态分派。原因就需要从invokevirtual指令的多态查找过程开始说起，invokevirtual指令的运行时解析过程大致分为以下几个步骤

找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。

如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回java.lang. IllegalAccessError异常。

否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。

如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

由于invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的invokevirtual指令把常量池中的类方法符号引用解析到了不同的直接引用上，这个过程就是Java语言中方法重写的本质。

（当然可以也通过javap查看字节码，分析字节码，更能直观的看出动态分派的实现过程）

2.1虚拟机动态分派的实现：

由于动态分派是非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在类的方法元数据中搜索合适的目标方法，因此在虚拟机的实际实现中基于性能的考虑，大部分实现都不会真正地进行如此频繁的搜索。面对这种情况，最常用的“稳定优化”手段就是为类在方法区中建立一个虚方法表（Vritual Method Table，也称为vtable，与此对应的，在invokeinterface执行时也会用到接口方法表——Inteface Method Table，简称itable），使用虚方法表索引来代替元数据查找以提高性能

虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实现版本的入口地址。Son重写了来自Father的全部方法，因此Son的方法表没有指向Father类型数据的箭头。但是Son和Father都没有重写来自Object的方法，所以它们的方法表中所有从Object继承来的方法都指向了Object的数据类型。

为了程序实现上的方便，具有相同签名的方法，在父类、子类的虚方法表中都应当具有一样的索引序号，这样当类型变换时，仅需要变更查找的方法表，就可以从不同的虚方法表中按索引转换出所需的入口地址。方法表一般在类加载的连接阶段进行初始化，准备了类的变量初始值后，虚拟机会把该类的方法表也初始化完毕

方法表是分派调用的“稳定优化”手段，虚拟机除了使用方法表之外，在条件允许的情况下，还会使用内联缓存（Inline Cache）和基于“类型继承关系分析”（Class Hierarchy Analysis，CHA）技术的守护内联（Guarded Inlining）两种非稳定的“激进优化”手段来获得更高的性能，