Java运行时多态本质是通过invokevirtual指令查虚方法表（vtable）实现的，vtable在类加载时构建，存储可重写方法的实际入口地址，仅非私有、非静态、非final实例方法参与动态绑定。
Java 的运行时多态，本质是通过虚方法调用（virtual method invocation） + 动态绑定（dynamic binding） 实现的，其底层核心支撑是每个类在 JVM 加载时生成的虚方法表（vtable，Virtual Method Table）。它不是靠“检查类型”或“反射”实现的，而是在字节码层面就设计为：调用非私有、非静态、非 final 的实例方法时，默认走 invokevirtual 指令，由 JVM 在运行时根据对象实际类型查 vtable 找到真正要执行的方法入口。
虚方法表（vtable）是什么
vtable 是 JVM 为每个类（除接口外）维护的一张函数指针表，按声明顺序存放该类所有可被重写（overridable）的实例方法的实际入口地址。它在类加载的链接阶段（Linking → Verification / Preparation / Resolution）中构建完成。
- 父类方法若被子类重写，子类 vtable 中对应槽位会被替换成子类方法的地址
- 新增的方法追加在表尾；继承但未重写的方法，直接复用父类 vtable 中的地址（JVM 可能做优化，逻辑上等价）
- static / private / final 方法不进 vtable —— 它们在编译期就确定了调用目标（静态绑定），走 invokespecial 或 invokestatic
- 接口方法不使用类 vtable，而是用 itable（Interface Method Table），机制类似但结构更复杂（因存在多实现）
invokevirtual 指令如何触发多态
当你写 obj.method()，且 method() 是非静态、非私有、非 final 的实例方法时，javac 编译出的字节码是 invokevirtual 指令。它的执行流程如下：
- JVM 先取出 obj 引用所指向的对象实例，读取其对象头中的 klass pointer（指向该对象所属类的 Class 对象）
- 通过 klass pointer 找到该类的 vtable
- 根据编译时解析出的方法符号引用（如 "ClassName.method:()V"），计算该方法在 vtable 中的索引偏移量
- 查 vtable 表中该索引位置的函数指针，跳转执行
注意：整个过程不看变量声明类型（如 Animal a = new Dog();），只看 new Dog() 创建的真实对象类型 —— 这就是“运行时决定”的来源。
立即学习“Java免费学习笔记（深入）”；
什么情况下不走 vtable？多态失效场景
以下情况看似写了继承/重写，但 JVM 不会查 vtable，也就没有运行时多态：
- 调用 static 方法：编译期绑定，看引用变量的声明类型。Animal a = new Dog(); a.staticMethod() → 调 Animal 的
- 调用 private 方法：隐式 final，只能被本类访问，子类里同名方法是全新方法，不是重写
- 调用 final 实例方法：JVM 明确禁止重写，直接内联或静态绑定
- 字段访问（field access）：字段无多态！Animal a = new Dog(); System.out.println(a.name); 输出的是 Animal 类定义的 name
- 构造器中调用可重写方法：虽走 invokevirtual，但此时子类字段可能还未初始化，易出 bug —— 技术上仍有多态，但语义危险
一个简单验证例子
写两个类：
class A { void m() { System.out.println("A.m"); } }
class B extends A { void m() { System.out.println("B.m"); } }
执行：
A x = new B(); x.m(); // 输出 "B.m"
反编译 .class 文件可见：第二行是 invokevirtual A.m()V；JVM 运行时发现 x 实际是 B 实例，查 B 的 vtable，找到 m() 槽位存的是 B.m 的地址，于是执行 B.m。
基本上就这些。vtable 是 JVM 的内部优化结构，开发者无需手动操作，但理解它，才能真正明白“为什么重写就自动多态”“为什么字段不参与多态”“为什么 private 不行”——不是语法糖，是字节码和运行时协作的结果。
