首先来一道笔试题：
对多态理解不够深入的，多半都会答错；如果能记住口诀：“变量多态看左边，方法多态看右边，静态多态看左边”的话，肯定就知道答案，但是JVM是如何确定具体调用哪个方法的，有小伙伴思考过吗？
1、方法调用：
方法调用并不等于方法执行，方法调用阶段唯一的任务就是确定被调用方法的版本（就是具体调用哪个方法），暂时还不涉及到方法内部的具体运行过程。Class文件的编译过程中不包含传统编译中的连接步骤,一切方法调用在Class文件里面存储的都只是符号引用,而不是方法在实际运行时内存布局中的入口地址。这个特性给Java带来了更强大的动态拓展能力，也使得Java方法调用过程变得相对复杂起来，需要在类加载期间，甚至到运行时才能确定目标方法的直接引用。
2、解析：
所有方法调用中的目标方法在Class文件里面都是一个常量池中的符号引用，在类加载的解析阶段，会将其中的一部分符号引用转换为直接引用（相当于指针）。这种解析能成立的前提是：方法在程序真正运行之前就有一个可确定的调用版本，并且这个方法的调用版本在运行期是不可改变的。换句话说，调用目标在程序代码在编译时就必须确定下来。这类方法的调用称之为解析。
在Java语言中符合“编译期可知，运行期不可变”这个要求的方法，主要包括静态方法和私有方法两大类，前者与类型直接关联，后者在外部不可被访问，这两种方法各自的特点决定了它们都不可能通过继承或别的方式重写其他版本（static修饰的静态方法可以重载，能被子类继承，但不能被重写），因此它们都适合在类加载阶段进行解析。
与之对应的是，在JVM里面提供了5条方法调用字节码指令，分别如下：
invokestatic：调用静态方法
invokespecial：调用实例构造器<init>方法、私有方法和父类方法。
invokevirtual：调用所有的虚方法
invokeinterface：调用接口方法，会在运行时再确定一个实现此接口的对象。
invokedynamic：先在运行时动态解析出调用点限定符所引用的方法，然后再执行该方法，在此之前的4条调用指令，分派逻辑是固化在JVM内部的，而invokedynamic指令的分派逻辑是由用户所设定的引导方法决定的。
只要能被invokestatic和invokespecial指令调用的方法，都可以在解析阶段中唯一确定调用版本，符合这个条件的有：静态方法、私有方法、实例构造器、父类方法。它们在类加载的时候就会把符号引用解析为该方法的直接引用。这些方法也称为“非虚方法”。
代码示例：
public class StaticResolution {
/**
* 此方法只能属于StaticResolution类，没有任何手段可以重写或隐藏这个方法
*/
public static void sayHello() {
System.out.println("hello world");
}
public static void main(String[] args) {
StaticResolution.sayHello();
}
}使用javac编译，然后在编译好的class文件所在目录打开cmd输入命令：
javap -c StaticResolution.class可以查看该程序的字节码：
可以发现，的确是通过invokestatic命令来调用sayHello（）方法的。
Java中的非虚方法除了使用invokestatic、invokevirtual调用的方法之外还有一种，就是被final修饰的方法，虽然final方法是使用invokevirtual指令来调用的，但是由于它无法被覆盖，没有其他版本，所以也无须对方法接收者进行多态选择，又或者说多态选择的结果肯定是唯一的。在Java语言规范中明确说明了final方法是一种非虚方法。
解析调用一定是个静态的过程，在编译期间就完全确定，在类装载的解析阶段就会把涉及的符号引用全部转变为可确定的直接引用，不会延迟到运行期再去完成。而分派调用则可能是静态的也可能是动态的，根据分派依据的宗量数可分为单分派和多分派。这两类分派方式的两两组合就构成了静态单分派、静态多分派、动态单分派、动态多分派这4种分派组合情况。
3、分派
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 human");
}
public void sayHello(Man guy) {
System.out.println("hello man");
}
public void sayHello(Woman guy) {
System.out.println("hello woman");
}
public static void main(String[] args) {
Human man = new Man();
Human woman = new Woman();
StaticDispatch dispatch = new StaticDispatch();
dispatch.sayHello(man);
dispatch.sayHello(woman);
}
}输出结果是什么呢，很多人会想按照参数类型，肯定是输出：
hello man
hello woman然而事实却是输出：
hello human
hello human为什么会选择参数类型是Human的重载呢？解答这个问题之前，先按如下代码定义两个重要的概念。
Human man = new Man();我们把上面代码中的“Human” 成为变量的静态类型（Static Type），或者叫做外观类型（Apparent Type），后面的“Man” 则称为变量的实际类型（Actual Type），静态类型和实际类型在程序中都可以发生变化，区别是静态类型的变化仅仅在使用时发生，变量本身的静态类型不会被改变，并且最终的静态类型是在编译期可知的；而实际类型变化的结果在运行期才可确定，编译期在编译程序的时候并不知道一个对象的实际类型是什么，例如：
// 实际类型变化
Human man = new Man();
man=new Woman();
// 静态类型变化
dispatch.sayHello((Man) man);
dispatch.sayHello((Woman) man);main()中的两次调用sayHello()，在方法接收者已经确定是对象“dispatch”的前提下，使用哪个重载版本，就完全取决于传入参数的数量和数据类型。代码中刻意定义了两个静态类型相同但实际类型不同的变量，但编译器在重载时是通过参数的静态类型而不是实际类型作为判定依据的。并且静态类型是编译器可知的，因此在编译阶段，Javac编译器会根据参数的静态类型决定使用哪个重载版本，所以选择了sayHello（Human）作为调用目标，并把这个方法的符号引用写到main（）方法里的两条invokevirtual指令的参数中。
所有依赖静态类型来定位方法执行版本的分派动作成为静态分派。静态分派的典型应用是方法重载。静态分派发生在编译阶段。因此确定静态分派的动作实际上不是有虚拟机来执行。另外虽然编译器能确定出方法的重载版本，但在很多情况下这个重载版本并不是“唯一的”，往往只能确定一个“更加合适”的版本。主要原因是字面量不需要定义，所以字面量没有显式的静态类型，它的静态类型只能通过语言上的规则去理解和推断。下面演示一个经典代码：
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');
}
}输出结果当然是：
hello char因为‘a’是char类型，自然会寻找参数类型为char的方法，如果注释掉sayHello（char arg）方法，那输出将是：
hello int这时发生了一次自动类型转换，‘a’ 除了代表一个字符，还可以代表数字97（Unicode），因此参数类型为int的重载也是合适的。继续注释sayHello（int arg）方法，那输出将是：
hello long这时发生了两次自动类型转换，‘a’转型为整数97之后，进一步转型为长整型97L，匹配了参数类型为long的方法，如果还有参数类型为float，double等的重载方法，自动转型还会发生多次，按照char > int > long > float > double 的顺序转型进行匹配。但是不会匹配byte和short类型的重载。因为char到byte和short的转型是不安全的，继续注释掉sayHello（long arg）方法，输出是：
hello Character这时候发生了一次自动装箱，‘a’被包装为它的包装类型java.lang.Character，所以匹配到sayHello(Character arg)，继续注释sayHello(Character arg)，输出就会变为：
hello Serializable这个输出结果是因为java.lang.Character实现了Serializable接口，当自动装箱后发现还是找不到包装类，但是找到了包装类实现的接口，所以又发生了一次自动转型。char可以转型为int，但是Character绝对不会转型为Integer，它只能安全的转型为它实现的接口或父类。Character还实现了Comparable接口，如果同时出现两个参数分别为Serializable和Comparable的重载方法，那它们在此时的优先级是一样的，但编译器就无法确定自动转型为哪种类型了，会提示编译错误，比如
需要调用的时候显式的指定字面量的静态类型sayHello((Comparable<Character>)'a'); 才能编译通过
继续注释sayHello(Serializable arg)，输出为：
hello object这时是char装箱后转型为父类了，如果有多个父类，那将在继承关系中从下往上开始搜索，越接近上层优先级越低，即使方法调用传入的参数为null，这个规则仍然使用。
继续注释掉sayHello(Object arg)，输出为：
hello char...由此可见，可变参数方法的重载优先级是最低的。这时候参数‘a’被当做数组，还可以选择int类型、Character、Object类型等的可变参数重载来重新演示。
2）动态分派
动态分派与重写有着密切联系，演示代码：
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在调用sayHello0方法时执行了不同的行为，并且变量man在两次调用中执行了不同的方法。导致这个现象的原因很明显，这两个变量的实际类型不同，Java虚拟机
是如何根据实际类型来分派方法执行版本的呢?我们使用javap -c DynamicDispatch.class 命令输出这段代码的字节码：
Compiled from "DynamicDispatch.java"
public class jvm.DynamicDispatch {
public jvm.DynamicDispatch();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: return
public static void main(java.lang.String[]);
Code:
0: new #2 // class jvm/DynamicDispatch$Man
3: dup
4: invokespecial #3 // Method jvm/DynamicDispatch$Man."<init>":()V
7: astore_1
8: new #4 // class jvm/DynamicDispatch$Woman
11: dup
12: invokespecial #5 // Method jvm/DynamicDispatch$Woman."<init>":()V
15: astore_2
16: aload_1
17: invokevirtual #6 // Method jvm/DynamicDispatch$Human.sayHello:()V
20: aload_2
21: invokevirtual #6 // Method jvm/DynamicDispatch$Human.sayHello:()V
24: new #4 // class jvm/DynamicDispatch$Woman
27: dup
28: invokespecial #5 // Method jvm/DynamicDispatch$Woman."<init>":()V
31: astore_1
32: aload_1
33: invokevirtual #6 // Method jvm/DynamicDispatch$Human.sayHello:()V
36: return
}0-15行的字节码是准备动作，作用是建立man和woman的内存空间、调用Man和Woman类型的实例构造器，将这两个实例的引用存放在第1、2个局部变量表Slog之中，这个动作也对应了代码中的这两句：
Human man = new Man();
Human woman = new Woman();接下来的16-21是关键部分，16、20两句分别把刚刚创建的两个对象的引用压到栈顶，这两个对象是将要执行的sayHello()方法的所有者，成为接收者；17和21句是方法调用指令，这两条调用指令单从字节码角度看，无论是指令（都是invokevirtual）还是参数（都是常量池中第22项的常量，注释显示了这个常量是Human.sayHello()的符号引用）完全一样的，但是这两句指令最终执行的目标方法并不相同。原因就需要从invokevirtual指令的多态查找过程说起，invokevirtual指令的运行时解析过程大致分为以下几个步骤：
1）找到操作数栈顶的第一个元素所指向的对象的实际类型，记作C。
2)如果在类型C中找到与常量中的描述符和简单名称都相符的方法，则进行访问权限
校验，如果通过则返回这个方法的直接引用，查找过程结束;如果不通过，则返回java.lang.
IHlegalAccessError异常。
3)否则，按照继承关系从下往上依次对C的各个父类进行第2步的搜索和验证过程。
4)如果始终没有找到合适的方法，则抛出java.lang.AbstractMethodError异常。
由于invokevirtual指令执行的第一步就是在运行期确定接收者的实际类型，所以两次调
用中的invokevirtual指令把常量池中的类方法符号引用解柝到了不同的直接引用上，这个过
程就是Java语言中方法重写的本质。我们把这种在运行期根据实际类型确定方法执行版本的
分派过程称为动态分派。
- 再插入一个《Java编程思想》中的一个经典例子，加深理解：
public class Shape {
public void draw(){}
static class Circle extends Shape{
@Override
public void draw() {
System.out.println("Circle.draw()");
}
}
static class Square extends Shape {
@Override
public void draw() {
System.out.println("Square.draw()");
}
}
static class Triangle extends Shape {
@Override
public void draw() {
System.out.println("Triangle.draw()");
}
}
static class RandomShape{
private Random random = new Random(47);
public Shape next() {
switch (random.nextInt(3)) {
default:
case 0:
return new Circle();
case 1:
return new Square();
case 2:
return new Triangle();
}
}
}
private static RandomShape randomShape = new RandomShape();
public static void main(String[] args) {
Shape[] s = new Shape[9];
for (int i = 0; i < s.length; i++) {
s[i] = randomShape.next();
}
for (Shape shape : s) {
shape.draw();
}
}
}输出结果：
Triangle.draw()
Triangle.draw()
Square.draw()
Triangle.draw()
Square.draw()
Triangle.draw()
Square.draw()
Triangle.draw()
Circle.draw()上面的例子中，Shape类为所有的子类建立了一个公共方法，子类通过重写这个方法，来为每种特殊形状提供单独的行为。
RandomShape类，其实像一个“工厂”，每次调用next（）方法时，它可以为随机选择的Shape对象产生一个引用。注意：向上转型是发生在return语句中。每个return语句都取得一个指向某个Circle、Square、Triangle的引用，并将其以Shape类型从next（）方法中发送出去。所以无论我们在什么时候调用next()方法，是绝不可能知道具体类型到底是什么的，因为我们总是只能获得一个通用的Shape引用。
main()包含了一个Shape引用组成的数组，通过调用RandomShape.next()来填入数据。此时，我们只知道自己拥有一些Shape，除此之外不会知道更具体的情况（编译器也不知道）。然而，当我们遍历这个数组，并为每个数组元素调用draw()方法时，与类型有关的特定行为会神奇般的发生，从输出结果不难看出。
3）JVM动态分派的实现
动态分派是非常频繁的动作，而且动态分派的方法版本选择过程需要运行时在类的方法元数据中搜索合适的目标方法，因此在虚拟机的实际实现中基于性能的考虑，大部分实现都不会真正的进行如此频繁的搜索。最常见的“稳定优化”手段就是为类在方法区中建立一个虚方法表（Virtual Method Table,也称为vtable，与此对应的在invokeinterface执行时也会用到接口方法表——Interface Method Table，简称itable），使用虚方法表索引来代替元数据查找以提高性能。
虚方法表存放着各个方法的实际入口地址。如果某个方法在子类中没有被重写，那子类的虚方法表里面的地址入口和父类相同方法的地址入口是一致的，都指向父类的实际入口地址。如果子类重写了这个方法，子类方法表中的地址将会替换为指向子类实现版本的入口地址。
为了程序实现的方便，具有相同签名的方法，在父类、子类的虚方法表中都应当具有一样的索引序号，这样当类型转换时，仅需要变更查找的方法表，就可以从不同的虚方法表中按索引转换出所需的入口地址。
方法表一般在类加载的连接阶段进行初始化，准备了类的变量初始值后，虚拟机会把该类的方法表也初始化完毕。
下一篇文章，将分享javac编译器和JIT编译器。
以上知识点都总结来自于周志明的《深入理解Java虚拟机》和《Java编程思想第4版》。
