如何通过Java字节码指令分析虚方法表实现多态动态派发的全貌

Ja va多态的动态派发本质依赖JVM在类加载时构建的虚方法表（vtable），由invokevirtual指令结合对象实际类型与方法签名在vtable中查找具体实现。

Ja va多态的动态派发，说到底就是虚方法表（vtable）在幕后撑腰。你翻遍.class文件也找不到vtable的影子——它是JVM在类加载阶段悄悄搭起来的内部结构，不显山不露水。真正决定最终调用哪个方法的，是字节码里的invokevirtual指令和运行时对象的实际类型、方法签名以及vtable索引之间的默契配合。

invokevirtual 是动态派发的入口指令

invokevirtual 是Ja va中调用实例方法（非private、非static、非final）的标准指令。它不会硬编码目标方法地址，而是根据栈顶对象的实际类型，去对应类的虚方法表里找到匹配的入口。编译期间只记下方法的符号引用，比如 Lja va/lang/Object;.toString:()Lja va/lang/String; 这种形式；等到运行时，JVM才会真正解析这个引用，定位到接收者对象所属类的vtable，然后按方法签名（名称+描述符）在vtable里做查找——可能是哈希查找，也可能是线性扫描，总之找到具体实现的内存地址。

vtable 在JVM内部构造，不在字节码中显式存在

你没法在.class文件里看到vtable数组——它是JVM在类加载的“连接”阶段（尤其是准备和解析阶段）为每个类生成的内部数据结构。每个类（final类除外）都有自己的vtable，里面包含：从父类继承过来且没有重写的方法（直接指向父类vtable对应位置）、本类新定义或重写的方法（指向本类方法区中的具体字节码起始地址）。最关键的一点是：相同签名的方法在子类vtable中占据与父类vtable一样的索引位置，这样多态调用时才能保持一致性。

通过ja vap观察字节码可间接验证vtable行为

用ja vap -v查看编译后的字节码，重点关注invokevirtual指令的操作数，它指向常量池中的一个Methodref。这个符号引用看似指向父类声明的方法，但实际运行时JVM会基于对象真实类型查vtable：

• 例如Animal a = new Dog(); a.speak();，字节码中仍是invokevirtual Animal.speak
• 运行时发现a实际是Dog实例，于是查Dog类的vtable，找到Dog.speak的入口
• 若Dog没重写speak，则vtable中该槽位仍指向Animal.speak

final、static、private 方法绕过vtable

这些方法在编译期就能确定唯一目标，因此使用更轻量的指令，不参与动态派发：invokestatic调用静态方法，直接绑定到类符号引用；invokespecial调用私有方法、构造器或父类方法（如super.xxx()），地址在编译期解析完成；invokeinterface用于接口方法调用，使用的是独立的itable（接口方法表），原理类似vtable但支持多实现。另外，final实例方法虽然也可以用invokevirtual调用，但JIT编译器可能会内联优化，跳过vtable的查表过程。

理解vtable的关键，不是非得在字节码里“看见”它，而是搞清楚invokevirtual如何触发JVM的运行时查表逻辑——这正是Ja va多态能“以父类引用来调用子类实现”的底层支撑。