方法调用
方法调用并不等同于方法执行,方法调用阶段唯一的任务就是确定被调用方法的版本(即调用的哪一个方法),暂时还不涉及方法内部具体的运行过程.在程序运行时,进行方法调用是最普遍的,最频繁的操作.但是Class文件的编译过程中不包含传统编译中的连接步骤,一切方法调用在Class文件里面存储的只是符号引用,而不是方法在实际运行时内存布局中的入口地址(相当于之前说的直接引用).这个特性给Java带来了更加强大的动态扩展能力,但也使得Java方法调用过程变得相对复杂起来,需要在类加载期间,甚至到运行期间才能确定目标方法的直接引用.
解析
所有方法调用中的目标方法在Class文件里面都是一个常量池的符号引用,在类加载的解析阶段,会将其中的一部分符号引用转化为直接引用,这中捷信能成立的前提是:方法在程序真正运行之前就有一个可确定的调用版本,并且这个方法的调用版本在运行期是不可改变的.换句话说,调用目标在程序代码写好,编译器进行编译时就必须确定下来.这类方法的调用成为解析(Resolution).
在Java语言中符合“编译期可知运行期不可变”这个要求的的方法主要包括静态方法和私有方法两大类
这两种方法不能被通过继承或者是背的方式被重写,因此他们适合在类的加载阶段进行解析
- 静态方法:与类型直接关系
- 私有方法:在外部不可访问
与之相对应的是,在Java虚拟机里面提供了5条方法调用字节码指令
- invokestatic：调用静态方法。
- invokespecial：调用实例构造器＜init＞方法、私有方法和父类方法。
- invokevirtual：调用所有的虚方法。
- invokeinterface：调用接口方法，会在运行时再确定一个实现此接口的对象。
- invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法，在此之前的4条调用指令，分派逻辑是固化在Java虚拟机内部的，而invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。
只要能被invokestatic和invokespecial指令调用的方法,都可以在解析阶段确定为宜的调用版本,符合这个条件的有静态方法,私有方法,实例构造方法,父类方法4类方法,他们在类加载的时候就会把符号引用解析为该方法的直接引用.这些方法可以称为非虚方法,与其相反,其他方法称为虚方法(出去final方法).
Java中的非虚方法除了使用invokestatic,invokespecial调用方法之外还有一种,就是被final修饰的方法.虽然final方法是使用invokevirtual指令调用,但是由于它无法被覆盖,没有其他版本,所以也无须对方法接收方进行多态选择,又或者说多态选择的结果肯定是唯一的.在Java语言规范当中明确说明了final方法是一种非虚方法.
解析调用一定是一个静态过程,在编译期就完全确定,在类装载的解析阶段就会把涉及的符号引用全部转换为可用的直接引用,不会延迟到运行期再去完成.而分派(Dispath)调用则可能是静态的也可能是动态的,根据分派依据的宗量数可分为单分派和多分派。这两类分派方式的两两组合就构成了静态单分派、静态多分派、动态单分派、动态多分派4种分派组合情况.
JVM运行原理🎥
分派
Java的三大基本特性,继承,封装,多态.
1.静态分派
方法静态分派演示
public class StaticDispatch {
static abstract class Human{
}
static class Woman extends Human{
}
static class Man extends Human{
}
public void sayHello(Human gay){
System.out.println("Hello guy!");
}
public void sayHello(Woman gay){
System.out.println("Hello lady!");
}
public void sayHello(Man gay){
System.out.println("Hello gentleman!");
}
public static void main(String[] args) {
Human man = new Man();
Human woman=new Woman();
StaticDispatch sr=new StaticDispatch();
sr.sayHello(man);
sr.sayHello(woman);
}
}
运行结果
Hello guy!
Hello guy!
先按照代码定义两个重要的概念;
Human man = new Human();
把上述代码中的"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指令的参数中.
所有依赖静态类型来定位方法执行版本的分派动作称为静态分派.静态分配的典型应用是方法重载.静态分派发生在编译阶段,因此确定静态分派的动作实际上不是由虚拟机来执行的.另外,编译器虽然能确定出方法的重载版本,但在很多的情况下这个重载版本并不是"唯一的",往往只能确定一个"更加适合的版本".这种模糊的结论在由0和1构成的计算机世界中算是比"罕见"的事情,产生这种模糊结论的主要原因是字面量不需要定义,所以字面量没有显式的静态类型,它的静态类型型只能通过语言上的规则去理解和推断.
public class Overload {
public static void sayHello(Object arg){
System.out.println("Hello Object");
}
public static void sayHello(long arg){
System.out.println("Hello long");
}
public static void sayHello(int arg){
System.out.println("Hello int");
}
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');
}
}
运行结果
Hello char
因为'a'是一个char类型的数据,自然会寻找参数类型为char的重载方法,如果注释掉sayHello(char arg)方法,那输出就会变为
Hello int
这时发生了一次自动类型转换，'a'除了可以代表一个字符串，还可以代表数字97（字符'a'的Unicode数值为十进制数字97），因此参数类型为int的重载也是合适的。我们继续注释掉sayHello（int arg）方法，那输出会变为：
Hello long
发生了两次自动类型转换，'a'转型为整数97之后，进一步转型为长整数97L，匹配了参数类型为long的重载。实
际上自动转型还能继续发生多次按照char-＞int-＞long-＞float-＞double的顺序转型进行匹配。但不会匹配到byte和short类型的重载，因为char到byte或short的转型是不安全的。继续注释掉sayHello(long arg),那么输出就会变为:
Hello Character
这时发生了一次自动装箱，'a'被包装为它的封装类型java.lang.Character，所以匹配到了参数类型为Character的重载
继续注释掉sayHello（Character arg）方法，那输出会变为：
Hello Serializable
出现Hello Serializable，是因为java.lang.Serializable是java.lang.Character类实现的一个接口，当自动装箱之后发现还是找不到装箱类，但是找到了装箱类实现了的接口类型，所以紧接着又发生一次自动转型。char可以转型成int，但是Character是绝对不会转型为Integer的，它只能安全地转型为它实现的接口或父类。Character还实现了另外一个接java.lang.Comparable＜Character＞，如果同时出现两个参数分别为Serializable和Comparable＜Character＞的重载方法，那它们在此时的优先级是一样的。编译器无法确定要自动转型为哪种类型，会提示类型模糊，拒绝编译。程序必须在调用时显式地指定字面量的静态类型，如：sayHello（（Comparable＜Character＞）'a'），才能编译通过。
下面继续注释掉sayHello（Serializable arg）方法，输出会变为:
Hello object
这时是char装箱后转型为父类了,如果有多个父类,那将在继承关系中从下往上开始搜索,越接近上层的优先级的越低.即使调用传入的参数值为null时,这个规则仍然适用.把sayHello（Object arg）也注释掉，输出将会变为：
Hello char...
可见变长参数的重载优先级是最低的，这时候字符'a'被当做了一个数组元素。
静态方法会在类加载期就进行解析，而静态方法显然也是可以拥有重载版本的，选择重载版本的过程也是通过静态分派完成的
2.动态分配
public class DynamicDispatch {
static abstract class Human{
protected abstract void sayHello();
}
static class Woman extends Human {
@Override
protected void sayHello() {
System.out.println("Woman say hello");
}
}
static class Man extends Human {
@Override
protected void sayHello() {
System.out.println("Man 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在两次调用中执行了不同的方法.这是因为这两个变量的实际类型不同
main()方法中的字节码
0～15行的字节码是准备动作，作用是建立man和woman的内存空间、调用Man和Woman类型的实例构造器，将这两个实例的引用存放在第1、2个局部变量表Slot之中，这个动作也就对应了代码中的这两句：
Human man = new Man();
Human woman = new Woman();
接下来的16～21句是关键部分，16、20两句分别把刚刚创建的两个对象的引用压到栈顶，这两个对象是将要执行的sayHello（）方法的所有者，称为接收者（Receiver）；17和21句是方法调用指令，这两条调用指令单从字节码角度来看，无论是指令（都是invokevirtual）还是参数（都是常量池中第22项的常量，注释显示了这个常量是Human.sayHello（）的符号引用）完全一样的，但是这两句指令最终执行的目标方法并不相同。原因就需要从invokevirtual指令的多态查找过程开始说起，invokevirtual指令的运行时解析过程大致分为以下几个步骤：
- 1)找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。
- 2）如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限校验，如果通过则返回这个方法的直接引用，查找过程结束；如果不通过，则返回java.lang.IllegalAccessError异常。
- 3）否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。
- 4）如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。
由于invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调用中的invokevirtual指令把常量池中的类方法符号引用解析到了不同的直接引用上，这个过程就是Java语言中方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的分派过程称为动态分派。
3.单分派和多分派
方法的宗量:方法接收者与方法的参数的统称.
根据分派基于多少种宗量，可以将分派划分为单分派和多分派两种。
- 单分派:根据一个宗量对目标方法进行选择.
- 多分派:根据多余一个宗量对目标进行选择
public class Dispatch {
static class QQ{}
static class _360{}
public static class Father{
public void hardChoice(QQ arg){
System.out.println("Father choice QQ");
}
public void hardChoice(_360 arg){
System.out.println("Father choice 360");
}
}
public static class Son extends Father{
@Override
public void hardChoice(QQ arg){
System.out.println("Son choice QQ");
}
@Override
public void hardChoice(_360 arg){
System.out.println("Son choice 360");
}
}
public static void main(String[] args) {
Father father = new Father();
Father son = new Son();
father.hardChoice(new _360());
son.hardChoice(new QQ());
}
}
运行结果
Father choice 360
Son choice QQ
编译阶段编译器的选择过程，也就是静态分派的过程。这时选择目标方法的依据有两点：一是静态类型是Father还是Son，二是方法参数是QQ还是360。这次选择结果的最终产物是产生了两条invokevirtual指令，两条指令的参数分别为常量池中指向Father.hardChoice（360）及Father.hardChoice（QQ）方法的符号引用。因为是根据两个宗量进行选择，所以Java语言的静态分派属于多分派类型。
运行阶段虚拟机的选择，也就是动态分派的过程。在执行“son.hardChoice（newQQ（））”这句代码时，更准确地说，是在执行这句代码所对应的invokevirtual指令时，由于编译期已经决定目标方法的签名必须为hardChoice（QQ），虚拟机此时不会关心传递过来的参数“QQ”到底是“腾讯QQ”还是“奇瑞QQ”，因为这时参数的静态类型、实际类型都对方法的选择不会构成任何影响，唯一可以影响虚拟机选择的因素只有此方法的接受者的实际类型是Father还是Son。因为只有一个宗量作为选择依据，所以Java语言的动态分派属于单分派类型。
4.虚拟机动态分派的实现
动态分派是非常频繁的动作,而且动态分配的方法版本选择过程需要在类方法数据中搜索合适的目标方法，因此在虚拟机的实际实现中基于性能的考虑，大部分实现都不会真正地进行如此频繁的搜索。
面对这种情况，最常用的“稳定优化”手段就是为类在方法区中建立一个虚方法表（Vritual Method Table，也称为vtable，与此对应的，在invokeinterface执行时也会用到接口方法表——Inteface Method Table，简称itable），使用虚方法表索引来代替元数据查找以提高性能。
上述代码虚方法表结构
虚方法表中存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都指向父类的实现入口。如果子类中重写了这个方法，子类方法表中的地址将会替换为指向子类实现版本的入口地址。
为了程序实现上的方便，具有相同签名的方法，在父类、子类的虚方法表中都应当具有一样的索引序号，这样当类型变换时，仅需要变更查找的方法表，就可以从不同的虚方法表中按索引转换出所需的入口地址。
方法表一般在类加载的连接阶段进行初始化,准备了类的变量初始化值后,虚拟机会把该类的方法表也初始化完毕.
动态语言支持
MethodHandle与与Reflection
从本质上讲，Reflection和MethodHandle机制都是在模拟方法调用，但Reflection是在模拟Java代码层次的方法调用，而MethodHandle是在模拟字节码层次的方法调用。
Reflection中的java.lang.reflect.Method对象远比MethodHandle机制中的java.lang.invoke.MethodHandle对象所包含的信息多。前者是方法在Java一端的全面映像，包含了方法的签名、描述符以及方法属性表中各种属性的Java端表示方式，还包含执行权限等的运行期信息。而后者仅仅包含与执行该方法相关的信息。用通俗的话来讲，Reflection是重量级，而MethodHandle是轻量级。
Reflection API的设计目标是只为Java语言服务的，而MethodHandle则设计成可服务于所有Java虚拟机之上的语言，其中也包括Java语言
基于栈的字节码解释执行引擎
解释执行
编译过程
现代经典编译原理的思路:在执行前先对程序源码进行词法分析和语法分析处理，把源码转化为抽象语法树（Abstract Syntax Tree,AST）。对于一门具体语言的实现来说，词法分析、语法分析以至后面的优化器和目标代码生成器都可以选择独立于执行引擎，形成一个完整意义的编译器去实现，这类代表是C/C++语言。也可以选择把其中一部分步骤（如生成抽象语法树之前的步骤）实现为一个半独立的编译器，这类代表是Java语言。又或者把这些步骤和执行引擎全部集中封装在一个封闭的黑匣子之中，如大多数的JavaScript执行器。
Java语言中，Javac编译器完成了程序代码经过词法分析、语法分析到抽象语法树，再遍历语法树生成线性的字节码指令流的过程。因为这一部分动作是在Java虚拟机之外进行的，而解释器在虚拟机的内部，所以Java程序的编译就是半独立的实现。
基于栈的指令集与基于寄存器的指令集
Java编译器输出的指令流，基本上[1]是一种基于栈的指令集架构（Instruction SetArchitecture,ISA），指令流中的指令大部分都是零地址指令，它们依赖操作数栈进行工作。与之相对的另外一套常用的指令集架构是基于寄存器的指令集，最典型的就是x86的二地址指令集，说得通俗一些，就是现在我们主流PC机中直接支持的指令集架构，这些指令依赖寄存器进行工作。
示例:分别使用这两种指令集计算“1+1”的结果
- 基于栈的指令集
iconst_1
iconst_1
iadd
istore_0
两条iconst_1指令连续把两个常量1压入栈后，iadd指令把栈顶的两个值出栈、相加，然后把结果放回栈顶，最后istore_0把栈顶的值放到局部变量表的第0个Slot中。
- 基于寄存器的指令集
mov eax，1
add eax，1
mov指令把EAX寄存器的值设为1，然后add指令再把这个值加1，结果就保存在EAX寄存器里面。
| 指令集 | 优点 | 缺点 |
|---|---|---|
| 基于栈的指令集 | 可移植,由硬件直接供给 | 受到硬件的约束 |
| 栈架构指令集 | 代码相对更加紧凑,编译器实现更加简单 | 执行速度相对来说会稍慢一些 |
栈实现在内存之中，频繁的栈访问也就意味着频繁的内存访问，相对于处理器来说，内存始终是执行速度的瓶颈。尽管虚拟机可以采取栈顶缓存的手段，把最常用的操作映射到寄存器中避免直接内存访问，但这也只能是优化措施而不是解决本质问题的方法。由于指令数量和内存访问的原因，所以导致了栈架构指令集的执行速度会相对较慢.
基于栈解释器执行过程
代码示例:
public int calc（）{
int a=100；
int b=200；
int c=300；
return（a+b）*c；
}
使用javap命令进行查看字节码指令
public int calc（）；
Code：
Stack=2，Locals=4，Args_size=1
0：bipush 100
2：istore_1
3：sipush 200
6：istore_2
7：sipush 300
10：istore_3
11：iload_1
12：iload_2
13：iadd
14：iload_3
15：imul
16：ireturn
}
javap提示这段代码需要深度为2的操作数栈和4个Slot的局部变量空间
执行偏移地址为0的指令的情况
执行偏移地址为1的指令的情况
执行偏移地址为11的指令的情况
执行偏移地址为12的指令的情况
执行偏移地址为13的指令的情况
执行偏移地址为14的指令的情况
执行偏移地址为16的指令的情况
上面的执行过程仅仅是一种概念模型，虚拟机最终会对执行过程做一些优化来提高性能，实际的运作过程不一定完全符合概念模型的描述……更准确地说，实际情况会和上面描述的概念模型差距非常大，这种差距产生的原因是虚拟机中解析器和即时编译器都会对输入的字节码进行优化.
网友评论