invokevirtual 是 Java 多态的运行时执行指令，根据对象实际类型查虚方法表（vtable）动态分派；编译期仅做符号解析，不决定具体实现。
invokevirtual 是 Java 多态的实际执行指令
Java 编译器不会为 override 方法生成特殊字节码，而是统一使用 invokevirtual 指令。它在运行时根据对象实际类型（而非引用类型）查虚方法表（vtable），再跳转到具体实现。这就是“动态绑定”的 JVM 层实现。
常见误解是“编译期决定调用哪个方法”，其实编译期只做符号解析：确认方法签名是否合法、是否存在可访问的声明，但不锁定具体实现类。真正分派发生在 invokevirtual 执行时。
-
invokevirtual要求目标方法是非私有、非静态、非 final 的实例方法（否则可能被内联或走其他指令） - 如果子类覆盖了父类方法，JVM 会在子类的 vtable 中覆写该方法槽位，指向子类版本的字节码入口
- 接口方法调用用的是
invokeinterface，原理类似但查的是 itable，开销略高
为什么 final 方法不走 invokevirtual？
标记为 final 的实例方法无法被覆盖，JVM 可以在 JIT 编译阶段直接内联或使用 invokespecial 调用——后者不查 vtable，只按编译期类型静态定位方法地址。
这带来两个实际影响：
立即学习“Java免费学习笔记（深入）”；
- 性能上更优：省去虚方法查表和多态分派开销
- 行为上更确定：哪怕通过反射修改类结构，
final方法也不会被动态替换（JVM 层面禁止） - 注意：
private方法也用invokespecial，但它是编译期静态绑定，连运行时多态语义都不具备
invokespecial 和 invokevirtual 的关键区别
二者都用于调用实例方法，但语义完全不同：invokespecial 强制走“当前类声明的方法”，无视子类覆盖；而 invokevirtual 必须走运行时实际类型的实现。
典型使用场景包括：
- 构造器调用（
<init></init>方法永远用invokespecial） - 显式调用父类被覆盖的方法（如
super.toString()） -
private方法调用
如果你在字节码里看到 invokespecial 却期望多态行为，大概率是误用了 super 或方法被错误设为 final / private。
看懂字节码里的多态调用链
用 javap -v 查看编译后字节码，重点关注方法调用指令和常量池中的符号引用。多态的关键不在源码写法，而在指令选择和类加载后的 vtable 布局。
一个简单验证方式：
class A { void m() { System.out.println("A"); } }
class B extends A { void m() { System.out.println("B"); } }
public class Test {
public static void main(String[] args) {
A a = new B();
a.m(); // 这行编译为 invokevirtual #3，#3 指向 A.m() 的符号引用
}
}
虽然符号引用指向 A.m()，但运行时 a 实际是 B 实例，JVM 查 B 的 vtable 发现该槽已被替换成 B.m() 的入口地址。
容易被忽略的是：vtable 在类加载的准备/初始化阶段构建，且一旦建立，除非触发类卸载（极少见），否则不会随运行时对象变化而重排。所以多态不是“每次调用都重新查找”，而是查一次表 + 直接跳转。
