|
在Java方法调用的过程中，JVM是如何知道调用的是哪个类的方法源代码？ 这里面到底有什么内幕呢？ 这篇文章我们就将揭露JVM方法调用的静态(static binding) 和动态绑定机制(auto binding) 。 静态绑定机制 //被调用的类package hr.test;classFather{ publicstaticvoidf1(){ System.out.println("Father— f1()"); } }//调用静态方法import hr.test.Father;publicclassStaticCall{ publicstaticvoidmain(){ Father.f1(); //调用静态方法 } }上面的源代码中执行方法调用的语句(Father.f1())被编译器编译成了一条指令：invokestatic #13。我们看看JVM是如何处理这条指令的 (1) 指令中的#13指的是StaticCall类的常量池中第13个常量表的索引项(关于常量池详见《Class文件内容及常量池 》)。这个常量表(CONSTATN_Methodref_info) 记录的是方法f1信息的符号引用(包括f1所在的类名，方法名和返回类型)。JVM会首先根据这个符号引用找到方法f1所在的类的全限定名: hr.test.Father； (2) 紧接着JVM会加载、链接和初始化Father类； (3) 然后在Father类所在的方法区中找到f1()方法的直接地址，并将这个直接地址记录到StaticCall类的常量池索引为13的常量表中。这个过程叫常量池解析 ，以后再次调用Father.f1()时，将直接找到f1方法的字节码； (4) 完成了StaticCall类常量池索引项13的常量表的解析之后，JVM就可以调用f1()方法，并开始解释执行f1()方法中的指令了。 通过上面的过程，我们发现经过常量池解析之后，JVM就能够确定要调用的f1()方法具体在内存的什么位置上了。实际上，这个信息在编译阶段就已经在StaticCall类的常量池中记录了下来。这种在编译阶段就能够确定调用哪个方法的方式，我们叫做静态绑定机制 。 除了被static 修饰的静态方法，所有被private 修饰的私有方法、被final 修饰的禁止子类覆盖的方法都会被编译成invokestatic指令。另外所有类的初始化方法<init>和<clinit>会被编译成invokespecial指令。JVM会采用静态绑定机制来顺利的调用这些方法。 动态绑定机制 package hr.test;//被调用的父类classFather{ publicvoidf1(){ System.out.println("father-f1()"); } publicvoidf1(int i){ System.out.println("father-f1() para-int "+i); } }//被调用的子类classSonextendsFather{ publicvoidf1(){ //覆盖父类的方法 System.out.println("Son-f1()"); } publicvoidf1(char c){ System.out.println("Son-s1() para-char "+c); } }//调用方法import hr.test.*;publicclassAutoCall{ publicstaticvoidmain(String[] args){ Father father=new Son(); //多态 father.f1(); //打印结果： Son-f1() } }上面的源代码中有三个重要的概念：多态(polymorphism) 、方法覆盖 、方法重载 。打印的结果大家也都比较清楚，但是JVM是如何知道f.f1()调用的是子类Sun中方法而不是Father中的方法呢？在解释这个问题之前，我们首先简单的讲下JVM管理的一个非常重要的数据结构——方法表 。 在JVM加载类的同时，会在方法区中为这个类存放很多信息(详见《Java 虚拟机体系结构》)。其中就有一个数据结构叫方法表。它以数组的形式记录了当前类及其所有超类的可见方法字节码在内存中的直接地址 。下图是上面源代码中Father和Sun类在方法区中的方法表： 上图中的方法表有两个特点：(1) 子类方法表中继承了父类的方法，比如Father extends Object。 (2) 相同的方法(相同的方法签名：方法名和参数列表)在所有类的方法表中的索引相同。比如Father方法表中的f1()和Son方法表中的f1()都位于各自方法表的第11项中。 对于上面的源代码，编译器首先会把main方法编译成下面的字节码指令： 0new hr.test.Son [13] //在堆中开辟一个Son对象的内存空间，并将对象引用压入操作数栈3 dup 4 invokespecial #7 [15] // 调用初始化方法来初始化堆中的Son对象 7 astore_1 //弹出操作数栈的Son对象引用压入局部变量1中8 aload_1 //取出局部变量1中的对象引用压入操作数栈9 invokevirtual #15 //调用f1()方法12return其中invokevirtual指令的详细调用过程是这样的： (1) invokevirtual指令中的#15指的是AutoCall类的常量池中第15个常量表的索引项。这个常量表(CONSTATN_Methodref_info) 记录的是方法f1信息的符号引用(包括f1所在的类名，方法名和返回类型)。JVM会首先根据这个符号引用找到调用方法f1的类的全限定名: hr.test.Father。这是因为调用方法f1的类的对象father声明为Father类型。 (2) 在Father类型的方法表中查找方法f1，如果找到，则将方法f1在方法表中的索引项11(如上图)记录到AutoCall类的常量池中第15个常量表中(常量池解析 )。这里有一点要注意：如果Father类型方法表中没有方法f1，那么即使Son类型中方法表有，编译的时候也通过不了。因为调用方法f1的类的对象father的声明为Father类型。 (3) 在调用invokevirtual指令前有一个aload_1指令，它会将开始创建在堆中的Son对象的引用压入操作数栈。然后invokevirtual指令会根据这个Son对象的引用首先找到堆中的Son对象，然后进一步找到Son对象所属类型的方法表。过程如下图所示： (4) 这是通过第(2)步中解析完成的#15常量表中的方法表的索引项11，可以定位到Son类型方法表中的方法f1()，然后通过直接地址找到该方法字节码所在的内存空间。 很明显，根据对象(father)的声明类型(Father)还不能够确定调用方法f1的位置，必须根据father在堆中实际创建的对象类型Son来确定f1方法所在的位置。这种在程序运行过程中，通过动态创建的对象的方法表来定位方法的方式，我们叫做 动态绑定机制 。 上面的过程很清楚的反映出在方法覆盖的多态调用的情况下，JVM是如何定位到准确的方法的。但是下面的调用方法JVM是如何定位的呢？(仍然使用上面代码中的Father和Son类型) publicclassAutoCall{ publicstaticvoidmain(String[] args){ Father father=new Son(); char c='a'; father.f1(c); //打印结果：father-f1() para-int 97 } }问题是Fahter类型中并没有方法签名为f1(char)的方法呀。但打印结果显示JVM调用了Father类型中的f1(int)方法，并没有调用到Son类型中的f1(char)方法。 根据上面详细阐述的调用过程，首先可以明确的是：JVM首先是根据对象father声明的类型Father来解析常量池的(也就是用Father方法表中的索引项来代替常量池中的符号引用)。如果Father中没有匹配到”合适” 的方法，就无法进行常量池解析，这在编译阶段就通过不了。 那么什么叫”合适”的方法呢？当然，方法签名完全一样的方法自然是合适的。但是如果方法中的参数类型在声明的类型中并不能找到呢？比如上面的代码中调用father.f1(char)，Father类型并没有f1(char)的方法签名。实际上，JVM会找到一种“凑合”的办法，就是通过 参数的自动转型 来找 到“合适”的 方法。比如char可以通过自动转型成int，那么Father类中就可以匹配到这个方法了 (关于Java的自动转型问题可以参见《【解惑】Java类型间的转型》)。但是还有一个问题，如果通过自动转型发现可以“凑合”出两个方法的话怎么办？比如下面的代码： classFather{ publicvoidf1(Object o){ System.out.println("Object"); } publicvoidf1(double[] d){ System.out.println("double[]"); } }publicclassDemo{ publicstaticvoidmain(String[] args) { new Father().f1(null); //打印结果： double[] } }null可以引用于任何的引用类型，那么JVM如何确定“合适”的方法呢。一个很重要的标准就是：如果一个方法可以接受传递给另一个方法的任何参数，那么第一个方法就相对不合适。比如上面的代码: 任何传递给f1(double[])方法的参数都可以传递给f1(Object)方法，而反之却不行，那么f1(double[])方法就更合适。因此JVM就会调用这个更合适的方法。 总 结
|
|
|
