深入理解JVM2-3-虚拟机执行子系统-虚拟机字节码执行引擎

JVM PV:

概述

执行引擎是Java虚拟机核心的组成部分之一。“虚拟机”是一个相对于“物理机”的概念，这两种机器都有代码执行能力，其区别是物理机的执行引擎是直接建立在处理器、缓存、指令集和操作系统层面上的，而虚拟机的执行引擎则是由软件自行实现的，因此可以不受物理条件制约地定制指令集与执行引擎的结构体系，能够执行那些不被硬件直接支持的指令集格式。

在不同的虚拟机实现中，执行引擎在执行字节码的 时候，通常会有解释执行（通过解释器执行）和编译执行（通过即时编译器产生本地代码执行）两种选择，也可能两者兼备，还可能会有同时包含几个不同级别的即时编译器一起工作的执行引擎。

运行时栈帧结构

Java虚拟机以方法作为最基本的执行单元，“栈帧”（Stack Frame）则是用于支持虚拟机进行方法 调用和方法执行背后的数据结构，它也是虚拟机运行时数据区中的虚拟机栈（Virtual MachineStack）的栈元素。见深入理解JVM1-1-自动内存管理-Java内存区域与内存溢出异常

每一个栈帧都包括了局部变量表、操作数栈、动态连接、方法返回地址和一些额外的附加信息。在编译Java程序源码的时候，栈帧中需要多大的局部变量表，需要多深的操作数栈就已经被分析计算 出来，并且写入到方法表的Code属性之中。即一个栈帧需要分配多少内存，并不会受到程序 运行期变量数据的影响，而仅仅取决于程序源码和具体的虚拟机实现的栈内存布局形式。

一个线程中的方法调用链可能会很长，以Java程序的角度来看，同一时刻、同一条线程里面，在 调用堆栈的所有方法都同时处于执行状态。而对于执行引擎来讲，在活动线程中，只有位于栈顶的方 法才是在运行的，只有位于栈顶的栈帧才是生效的，其被称为“当前栈帧”（Current Stack Frame），与 这个栈帧所关联的方法被称为“当前方法”（Current Method）。执行引擎所运行的所有字节码指令都只针对当前栈帧进行操作。

局部变量表

局部变量表（Local Variables Table）是一组变量值的存储空间，用于存放方法参数和方法内部定义 的局部变量。在Java程序被编译为Class文件时，就在方法的Code属性的max_locals数据项中确定了该方法所需分配的局部变量表的最大容量。

局部变量表的容量以变量槽（Variable Slot）为最小单位，《Java虚拟机规范》中并没有明确指出 一个变量槽应占用的内存空间大小，只是很有导向性地说到每个变量槽都应该能存放一个boolean、 byte、char、short、int、float、reference或returnAddress类型的数据，这8种数据类型，都可以使用32位或更小的物理内存来存储。

栈帧结构

一个变量槽可以存放一个 32位以内的数据类型，Java中占用不超过32位存储空间的数据类型有boolean、byte、char、short、int、float、reference和returnAddress这8种类型。

对于64位的数据类型，Java虚拟机会以高位对齐的方式为其分配两个连续的变量槽空间。Java语言 中明确的64位的数据类型只有long和double两种。这里把long和double数据类型分割存储的做法与“long 和double的非原子性协定”中允许把一次long和double数据类型读写分割为两次32位读写的做法有些类似。由于局部变量表是建立在线程堆栈中的，属于线程私有的数据，无论读写两个连续的变量槽是否为原子操作，都不会引起数据竞争和线程安全问题。

操作数栈

操作数栈（Operand Stack）也常被称为操作栈，它是一个后入先出（Last In First Out，LIFO） 栈。同局部变量表一样，操作数栈的最大深度也在编译的时候被写入到Code属性的max_stacks数据项 之中。其特点如下：

  • 操作数栈的每一个元素都可以是包括long和double在内的任意Java数据类型。
  • 32位数据类型所占 的栈容量为1，64位数据类型所占的栈容量为2。
  • Javac编译器的数据流分析工作保证了在方法执行的任何时候，操作数栈的深度都不会超过在max_stacks数据项中设定的最大值。

操作数栈中元素的数据类型必须与字节码指令的序列严格匹配，在编译程序代码的时候，编译器 必须要严格保证这一点，在类校验阶段的数据流分析中还要再次验证这一点。

另外在概念模型中，两个不同栈帧作为不同方法的虚拟机栈的元素，是完全相互独立的。但是在 大多虚拟机的实现里都会进行一些优化处理，令两个栈帧出现一部分重叠。让下面栈帧的部分操作数栈与上面栈帧的部分局部变量表重叠在一起，这样做不仅节约了一些空间，更重要的是在进行方法调用时就可以直接共用一部分数据，无须进行额外的参数复制传递了。

两个栈帧之间的数据共享

动态链接

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

通过第6章的讲解，我们知道Class文件的常量池中存 有大量的符号引用，字节码中的方法调用指令就以常量池里指向方法的符号引用作为参数。这些符号 引用一部分会在类加载阶段或者第一次使用的时候就被转化为直接引用，这种转化被称为静态解析。另外一部分将在每一次运行期间都转化为直接引用，这部分就称为动态连接。

方法返回地址

当一个方法开始执行后，只有两种方式退出这个方法:

  1. 执行引擎遇到任意一个方法 返回的字节码指令，这时候可能会有返回值传递给上层的方法调用者（调用当前方法的方法称为调用 者或者主调方法），方法是否有返回值以及返回值的类型将根据遇到何种方法返回指令来决定，这种退出方法的方式称为“正常调用完成”（Normal Method Invocation Completion）。
  2. 方法执行的过程中遇到了异常，并且这个异常没有在方法体内得到妥善处理。无论是Java虚拟机内部产生的异常，还是代码中使用athrow字节码指令产生的异常，只要在本方 法的异常表中没有搜索到匹配的异常处理器，就会导致方法退出，这种退出方法的方式称为“异常调用完成（Abrupt Method Invocation Completion）”。

无论采用何种退出方式，在方法退出之后，都必须返回到最初方法被调用时的位置，程序才能继续执行。方法返回时可能需要在栈帧中保存一些信息，用来帮助恢复它的上层主调方法的执行状态。

  • 方法正常退出时，主调方法的PC计数器的值就可以作为返回地址，栈帧中很可能会保存这 个计数器值。

  • 方法异常退出时，返回地址是要通过异常处理器表来确定的，栈帧中就一般不会保存 这部分信息。

方法退出的过程实际上等同于把当前栈帧出栈，因此退出时可能执行的操作有：恢复上层方法的局部变量表和操作数栈，把返回值（如果有的话）压入调用者栈帧的操作数栈中，调整PC计数器的值以指向方法调用指令后面的一条指令等。

附加信息

《Java虚拟机规范》允许虚拟机实现增加一些规范里没有描述的信息到栈帧之中，例如与调试、 性能收集相关的信息，这部分信息完全取决于具体的虚拟机实现。

方法调用

方法调用并不等同于方法中的代码被执行，方法调用阶段唯一的任务就是确定被调用方法的版本 （即调用哪一个方法），暂时还未涉及方法内部的具体运行过程。

Class文件的编译过程中不包含传统程序语言编译的连接步骤，一切方法调用在Class文件里面存储的都只是符号引用，而不是方法在实际运行时内存布局中的入口地址（也就是之前说的直接引用）。这个特性给Java带来了更强大的动态扩展能力，但也使 得Java方法调用过程变得相对复杂，某些调用需要在类加载期间，甚至到运行期间才能确定目标方法的直接引用。

解析

由于所有方法调用的目标方法在Class文件里面都是一个常量池中的符号引用。在类加载阶段确定具体的方法并转化为直接引用。这种行为就称为方法的解析，其前提是方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。

在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要有静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了它们都不可能通过继承或别的方式重写出其他版本，因此它们都适合在类加载阶段进行解析。

调用不同类型的方法，字节码指令集里设计了不同的指令。在Java虚拟机支持以下5条方法调用字 节码指令，分别是：

  • invokestatic：用于调用静态方法。
  • invokespecial：用于调用实例构造器<init>()方法、私有方法和父类中的方法。
  • invokevirtual：用于调用所有的虚方法。
  • invokeinterface：用于调用接口方法，会在运行时再确定一个实现该接口的对象。
  • invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法。前面4 条调用指令，分派逻辑都固化在Java虚拟机内部，而invokedynamic指令的分派逻辑是由用户设定的引导方法来决定的。

只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中确定唯一的调用版本， Java语言里符合这个条件的方法共有静态方法、私有方法、实例构造器、父类方法4种，再加上被final 修饰的方法（尽管它使用invokevirtual指令调用），这5种方法调用会在类加载的时候就可以把符号引 用解析为该方法的直接引用。这些方法统称为“非虚方法”（Non-Virtual Method），与之相反，其他方法就被称为“虚方法”（Virtual Method）。

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

分派

分派 （Dispatch）调用则要复杂许多，它可能是静态的也可能是动态的，按照分派依据的宗量数可分为单分派和多分派。这两类分派方式两两组合就构成了静态单分派、静态多分派、动态单分派、动态多分派4种分派组合情况，下面我们来看看虚拟机中的方法分派是如何进行的。

静态分派

为了解释静态分派和重载（Overload），笔者准备了一段经常出现在面试题中的程序代码，读者 不妨先看一遍，想一下程序的输出结果是什么。后面的话题将围绕这个类的方法来编写重载代码，以分析虚拟机和编译器确定方法版本的过程。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
package org.fenixsoft.polymorphic; /** * 方法静态分派演示 * @author zzm */
    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); sr.sayHello(woman);
    }
}

结果：

1
2
hello, guy!
hello, guy!

下面从例子中引出两个基本概念：

1
Human man = new Man();
  • 上面代码中的“Human”称为变量的“静态类型”（Static Type），或者叫“外观类 型”（Apparent Type）。
  • 后面的“Man”则被称为变量的“实际类型”（Actual Type）或者叫“运行时类 型”（Runtime Type）

静态类型和实际类型在程序中都可能会发生变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的；

而实际类型变化的结果在运行期才可确定，编译器在编译程序的时候并不知道一个对象的实际类型是什么。

例如：

1
2
3
4
5
// 实际类型变化 
Human human = (new Random()).nextBoolean() ? new Man() : new Woman();
// 静态类型变化 
sr.sayHello((Man) human)
sr.sayHello((Woman) human)

对象human的实际类型是可变的，编译期间它完全是个“薛定谔的人”，到底是Man还是Woman，必 须等到程序运行到这行的时候才能确定。

而human的静态类型是Human，也可以在使用时（如 sayHello()方法中的强制转型）临时改变这个类型，但这个改变仍是在编译期是可知的，两次sayHello()方法的调用，在编译期完全可以明确转型的是Man还是Woman。

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

所有依赖静态类型来决定方法执行版本的分派动作，都称为静态分派。静态分派的最典型应用表 现就是方法重载。静态分派发生在编译阶段，因此确定静态分派的动作实际上不是由虚拟机来执行的，这点也是为何一些资料选择把它归入“解析”而不是“分派”的原因。

需要注意Javac编译器虽然能确定出方法的重载版本，但在很多情况下这个重载版本并不是“唯 一”的，往往只能确定一个“相对更合适的”版本。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
package org.fenixsoft.polymorphic; public class Overload {
    public static void sayHello(Object arg) { 
        System.out.println("hello Object");
    }
    public static void sayHello(int arg) { 
        System.out.println("hello int");
    }
    public static void sayHello(long arg) { 
        System.out.println("hello long");
    }
    public static void sayHello(Character arg) { 
        System.out.println("hello Character");
    }
    public static void sayHello(char arg) { 
        System.out.println("hello char");
    }
    public static void sayHello(char... arg) { 
        System.out.println("hello char ...");
    }
    public static void sayHello(Serializable arg) { 
        System.out.println("hello Serializable");
    }
    public static void main(String[] args) { 
        sayHello('a');
    }
}

上面的代码运行后会输出：

1
hello char

这很好理解，’a’是一个char类型的数据，自然会寻找参数类型为char的重载方法，如果注释掉 sayHello(char arg)方法，那输出会变为：

1
hello int

这时发生了一次自动类型转换，’a’除了可以代表一个字符串，还可以代表数字97（字符’a’的 Unicode数值为十进制数字97），因此参数类型为int的重载也是合适的。

继续注释掉sayHello(int arg)方法，那输出会变为：

1
hello long

这时发生了两次自动类型转换，’a’转型为整数97之后，进一步转型为长整数97L，匹配了参数类型 为long的重载。

实际上自动转型还能继 续发生多次，按照char>int>long>float>double的顺序转型进行匹配，但不会匹配到byte和short类型的重载，因为char到byte或short的转型是不安全的。

继续注释掉sayHello(long arg)方法，那输出会变 为：

1
hello Character

这时发生了一次自动装箱，’a’被包装为它的封装类型java.lang.Character，所以匹配到了参数类型为 Character的重载，继续注释掉sayHello(Character arg)方法，那输出会变为：

1
hello Serializable

出现hello Serializable， 是因为java.lang.Serializable是java.lang.Character类实现的一个接口，当自动装箱之后发现还是找不到装 箱类，但是找到了装箱类所实现的接口类型，所以紧接着又发生一次自动转型。char可以转型成int， 但是Character是绝对不会转型为Integer的，它只能安全地转型为它实现的接口或父类。Character还实现 了另外一个接口java.lang.Comparable<Character>，如果同时出现两个参数分别为Serializable和 Comparable<Character>的重载方法，那它们在此时的优先级是一样的。编译器无法确定要自动转型为哪种类型，会提示“类型模糊”（Type Ambiguous），并拒绝编译。

但是要注意的是，有一些 在单个参数中能成立的自动转型，如char转型为int，在变长参数中是不成立的。

动态分派

动态分派与Java语言的另一个特征-重写有密切的关系。

还是从例子看起

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
package org.fenixsoft.polymorphic; /** * 方法动态分派演示 * @author zzm */
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();
    }
}

结果：

1
2
3
man say hello 
woman say hello
woman say hello

显然这里选择调用的方法版本是不可能再根据静态类型来决定的，因为静态类型同样都是Human 的两个变量man和woman在调用sayHello()方法时产生了不同的行为，甚至变量man在两次调用中还执行了两个不同的方法。导致这个现象的原因很明显，是因为这两个变量的实际类型不同。

这里的调用在字节码层面上即使用了invokevirtual指令。根据《Java虚拟机规范》， invokevirtual指令的运行时解析过程[4]大致分为以下几步：

  • 找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。
  • 如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果 通过则返回这个方法的直接引用，查找过程结束；不通过则返回java.lang.IllegalAccessError异常。
  • 否则，按照继承关系从下往上依次对C的各个父类进行第二步的搜索和验证过程。
  • 如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。

正是因为invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的 invokevirtual指令并不是把常量池中方法的符号引用解析到直接引用上就结束了，还会根据方法接收者的实际类型来选择方法版本，这个过程就是Java语言中方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。

单分派与多分派

方法的接收者与方法的参数统称为方法的宗量，这个定义最早应该来源于著名的《Java与模式》 一书。

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

单分派是根据一个宗量对目标方法进行选择，多分派则是根据多于一个宗量对目标方法进行选择。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
/** * 单分派、多分派演示 * @author zzm */
public class Dispatch {
    static class QQ {} 
    static class _360 {}
    public static class Father {
        public void hardChoice(QQ arg) { 
            System.out.println("father choose qq");
    	}
        public void hardChoice(_360 arg) { 
            System.out.println("father choose 360");
        }
    }
    
    public static class Son extends Father { 
         public void hardChoice(QQ arg) { 
                System.out.println("son choose qq");
    	}
        public void hardChoice(_360 arg) { 
            System.out.println("son choose 360");
        }
    }
    
    public static void main(String[] args) { 
        Father father = new Father(); 
        Father son = new Son(); 
        father.hardChoice(new _360()); 
        son.hardChoice(new QQ());
    }
}

结果：

1
2
father choose 360 
son choose qq

此时看在编译阶段中编译器的选择过程，也就是静态分派过程。

这时候选择目标方法的依据有两点：

  • 静态类型是Father还是Son，
  • 方法参数是QQ还是360。

这次选择结果的最终产物是产生了两条invokevirtual指令，两条指令的参数分别为常量池中指向 Father::hardChoice(360)及Father::hardChoice(QQ)方法的符号引用。因为是根据两个宗量进行选择，所以Java语言的静态分派属于多分派类型。

再看运行阶段中虚拟机的选择，也就是动态分派的过程。

在执行“son.hardChoice(new QQ())”这 行代码时，更准确地说，是在执行这行代码所对应的invokevirtual指令时，由于编译期已经决定目标方法的签名必须为hardChoice(QQ)，虚拟机此时不会关心传递过来的参数“QQ”到底是“腾讯QQ”还是“奇 瑞QQ”，因为这时候参数的静态类型、实际类型都对方法的选择不会构成任何影响，唯一可以影响虚拟机选择的因素只有该方法的接受者的实际类型是Father还是Son。因为只有一个宗量作为选择依据，所以Java语言的动态分派属于单分派类型。

虚拟机动态分派的实现

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

例如下面方法表结构：

方法表结构

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

动态类型语言支持

Java虚拟机的字节码指令集的数量自从Sun公司的第一款Java虚拟机问世至今，二十余年间只新增 过一条指令，它就是随着JDK 7的发布的字节码首位新成员——invokedynamic指令。这条新增加的指 令是JDK 7的项目目标：实现动态类型语言（Dynamically Typed Language）支持而进行的改进之一，也是为JDK 8里可以顺利实现Lambda表达式而做的技术储备。

动态类型语言

动态类型语言的关键特征是它的类型检查的主体过程是在运行期而不是编译期进行的。如Groovy、 JavaScript、Lisp、Lua等。

那相对地，在编译期就 进行类型检查过程的语言，譬如C++和Java等就是最常用的静态类型语言。

Java与动态类型

Java虚拟机层面对动态类型语言的支持一直都还有所欠缺，主要表现在方法调用方 面：JDK 7以前的字节码指令集中，4条方法调用指令（invokevirtual、invokespecial、invokestatic、invokeinterface）的第一个参数都是被调用的方法的符号引用。前面已经提到过，方法的符号引用在编译时产生，而动 态类型语言只有在运行期才能确定方法的接收者。

所以，在Java虚拟机上实现的动态类型语言就不得不采用更复杂的方法（如编译时留个占位符类型，运行时动态生成字节码实现具体类型到占位符 类型的适配）。这样肯定会带来更大的开销。

例如下面的代码：

1
2
3
4
var arrays = {"abc", new ObjectX(), 123, Dog, Cat, Car..} 
for(item in arrays){ 
    item.sayHello();
}

在动态类型语言下这样的代码是没有问题。

但在Java的处理方法中，由于在运行时arrays中的元素可以是任意类型，即使它们的类型中都有sayHello()方法，也肯定无法在编译优化的时候就确定具体sayHello()的代码在哪里， 编译器只能不停编译它所遇见的每一个sayHello()方法，并缓存起来供执行时选择、调用和内联，如果arrays数组中不同类型的对象很多，就势必会对内联缓存产生很大的压力，缓存的大小总是有限的，类型信息的不确定性导致了缓存内容不断被失效和更新，先前优化过的方法也可能被不断替换而无法重 复使用。所以这种动态类型方法调用的底层问题终归是应当在Java虚拟机层次上去解决才最合适。因此，在Java虚拟机层面上提供动态类型的直接支持就成为Java平台发展必须解决的问题，这便是JDK 7时JSR-292提案中invokedynamic指令以及java.lang.invoke包出现的技术背景。

java.lang.invoke包

JDK 7时新加入的java.lang.invoke包是JSR 292的一个重要组成部分，这个包的主要目的是在之前 单纯依靠符号引用来确定调用的目标方法这条路之外，提供一种新的动态确定目标方法的机制，称为“方法句柄”（Method Handle）。

但在之前Java语言中做不到这一点，没有办法单独把一个函数作为参数进行传递。普遍的做法是设计 一个带有compare()方法的Comparator接口，以实现这个接口的对象作为参数。

不过，在拥有方法句柄之后，Java语言也可以拥有类似于函数指针或者委托的方法别名这样的工具了。

例如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
import static java.lang.invoke.MethodHandles.lookup; 
import java.lang.invoke.MethodHandle; 
import java.lang.invoke.MethodType;
/** * JSR 292 MethodHandle基础用法演示 * @author zzm */
public class MethodHandleTest {
    static class ClassA { 
        public void println(String s) { 
            System.out.println(s);
        } 
    }
    
    public static void main(String[] args) throws Throwable { 
        Object obj = System.currentTimeMillis() % 2 == 0 ? System.out : new ClassA(); // 无论obj最终是哪个实现类，下面这句都能正确调用到println方法。 
        getPrintlnMH(obj).invokeExact("icyfenix");
    }
    
    private static MethodHandle getPrintlnMH(Object reveiver) throws Throwable {
        // MethodType：代表“方法类型”，包含了方法的返回值（methodType()的第一个参数）和 具体参数（methodType()第二个及以后的参数）。
        MethodType mt = MethodType.methodType(void.class, String.class);
        // lookup()方法来自于MethodHandles.lookup，这句的作用是在指定类中查找符合给定的方法名称、方法类型，并且符合调用权限的方法句柄。
        // 因为这里调用的是一个虚方法，按照Java语言的规则，方法第一个参数是隐式的，代表该方法的接 收者，也即this指向的对象，这个参数以前是放在参数列表中进行传递，现在提供了bindTo() 方法来完成这件事情。
        return lookup().findVirtual(reveiver.getClass(), "println", mt).bindTo(reveiver); 
    }
}

方法getPrintlnMH()中实际上是模拟了invokevirtual指令的执行过程，只不过它的分派逻辑并非固 化在Class文件的字节码上，而是通过一个由用户设计的Java方法来实现。而这个方法本身的返回值（MethodHandle对象），可以视为对最终调用方法的一个“引用”。

仅站在Java语言的角度看，MethodHandle在使用方法和效果上与Reflection有众多相似之 处。不过，它们也有以下这些区别：

  • Reflection中的java.lang.reflect.Method对象远比MethodHandle机制中的 java.lang.invoke.MethodHandle对象所包含的信息来得多。前者是方法在Java端的全面映像，包含了方法 的签名、描述符以及方法属性表中各种属性的Java端表示方式，还包含执行权限等的运行期信息。而 后者仅包含执行该方法的相关信息。用开发人员通俗的话来讲，Reflection是重量级，而MethodHandle是轻量级。
  • 由于MethodHandle是对字节码的方法指令调用的模拟，那理论上虚拟机在这方面做的各种优化 （如方法内联），在MethodHandle上也应当可以采用类似思路去支持（但目前实现还在继续完善中），而通过反射去调用方法则几乎不可能直接去实施各类调用点优化措施。
  • Reflection API的设计目标是只为Java语言服务的，而MethodHandle 则设计为可服务于所有Java虚拟机之上的语言，其中也包括了Java语言而已，而且Java在这里并不是主角。

nvokedynamic指令

某种意义上可以说invokedynamic指令与MethodHandle机制的作用是一样的，都是为了解决原有4 条“invoke*”指令方法分派规则完全固化在虚拟机之中的问题，把如何查找目标方法的决定权从虚拟机 转嫁到具体用户代码之中，让用户（广义的用户，包含其他程序语言的设计者）有更高的自由度。而且，它们两者的思路也是可类比的，都是为了达成同一个目的，只是一个用上层代码和API来实现，另一个用字节码和Class中其他属性、常量来完成。

每一处含有invokedynamic指令的位置都被称作“动态调用点（Dynamically-Computed Call Site）”， 这条指令的第一个参数不再是代表方法符号引用的CONSTANT_Methodref_info常量，而是变为JDK 7 时新加入的CONSTANT_InvokeDynamic_info常量，从这个新常量中可以得到3项信息：引导方法 （Bootstrap Method，该方法存放在新增的BootstrapMethods属性中）、方法类型（MethodType）和 名称。引导方法是有固定的参数，并且返回值规定是java.lang.invoke.CallSite对象，这个对象代表了真正要执行的目标方法调用。根据CONSTANT_InvokeDynamic_info常量中提供的信息，虚拟机可以找到并且执行引导方法，从而获得一个CallSite对象，最终调用到要执行的目标方法上。

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

解释执行

无论是解释还是编译，也无论是物理机还是虚拟机，对于应用程序，机器都不可能如人那样阅 读、理解，然后获得执行能力。大部分的程序代码转换成物理机的目标代码或虚拟机能执行的指令集之前，都需要经过下图中的各个步骤。

编译过程

在Java语言中，Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法 树生成线性的字节码指令流的过程。因为这一部分动作是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译就是半独立的实现。

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

Javac编译器输出的字节码指令流，基本上是一种基于栈的指令集架构（Instruction Set Architecture，ISA），字节码指令流里面的指令大部分都是零地址指令，它们依赖操作数栈进行工作。

与之相对的另外一套常用的指令集架构是基于寄存器的指令集，最典型的就是x86的二地址指令 集，如果说得更通俗一些就是现在我们主流PC机中物理硬件直接支持的指令集架构，这些指令依赖寄存器进行工作。

例如分别使用这两种指令集去计算“1+1”的结果，基于栈的指令集会是这样子的：

1
2
3
4
iconst_1 
iconst_1 
iadd
istore_0

两条iconst_1指令连续把两个常量1压入栈后，iadd指令把栈顶的两个值出栈、相加，然后把结果 放回栈顶，最后istore_0把栈顶的值放到局部变量表的第0个变量槽中。这种指令流中的指令通常都是 不带参数的，使用操作数栈中的数据作为指令的运算输入，指令的运算结果也存储在操作数栈之中。

而如果用基于寄存器的指令集，那程序可能会是这个样子：

1
2
mov eax, 1 
add eax, 1

mov指令把EAX寄存器的值设为1，然后add指令再把这个值加1，结果就保存在EAX寄存器里面。 这种二地址指令是x86指令集中的主流，每个指令都包含两个单独的输入参数，依赖于寄存器来访问和存储数据。

基于栈的指令集优点

  • 可以由虚拟机实现来自行决定把一些访问最频繁的数据（程序计数器、栈顶缓存等）放到 寄存器中以获取尽量好的性能，这样实现起来也更简单一些。
  • 代码相对更加紧凑（字节码中每个字节就对应一条指令，而多地址指令集中还需要存放参数）
  • 编译器实现更加简单（不需要考虑空间分配的问题，所需空间都在栈上操作）

基于栈的指令集缺点

  • 理论上执行速度相对来说会稍慢一些（所有主流物理机的指令集都是 寄存器架构[3]也从侧面印证了这点）

其原因在于：

  • 在解释执行时，栈架构指令集的代码虽然紧凑，但是完成相同功能所需的指令数量一般会比寄存器架构来得更多，因为出栈、入栈操作本身就产生了相当大量的指令。
  • 更重要的是栈实现在内存中， 频繁的栈访问也就意味着频繁的内存访问，相对于处理器来说，内存始终是执行速度的瓶颈。尽管虚 拟机可以采取栈顶缓存的优化方法，把最常用的操作映射到寄存器中避免直接内存访问，但这也只是 优化措施而不是解决本质问题的方法。因此由于指令数量和内存访问的原因，导致了栈架构指令集的执行速度会相对慢上一点。

Powered by Hexo and Hexo-theme-hiker

Copyright © 2019 - 2024 My Wonderland All Rights Reserved.

UV : | PV :