Java多态调用时vtable索引由父类声明的方法签名决定，与子类代码顺序无关；父类可重写方法在子类vtable中保留原索引，新增方法追加表尾；invokevirtual通过常量池索引解析签名后匹配vtable槽位。
Java多态调用时，vtable索引到底怎么算的？
Java虚拟机（JVM）在调用虚方法时，并不每次都查类元数据；它依赖每个类的方法表（vtable）做O(1)跳转。这个表不是按源码顺序排的，而是按**继承链+接口实现+重写合并后**的规范顺序生成的。
关键判断：你写的@Override方法，在子类vtable里的索引，由父类声明的方法签名决定，跟子类里写在第几行完全无关。
- 父类中声明的每个可被重写的方法（非
private、非static、非final），在子类vtable中保留原始索引位置 - 子类新增的、未重写的方法，追加在表尾（但这类方法不会参与多态分派）
- 如果父类有多个同名不同参的重载方法，它们各自独立占位；重写只影响对应签名的槽位
为什么javap -v看不到vtable索引？
javap输出的是字节码和常量池，不是运行时结构。vtable是JVM加载类时动态构建的内部数据结构，不存于class文件中。
常见错误现象：javap里看到方法顺序和你预期一致，就以为运行时索引也一样——这是错的。比如父类定义了toString()和hashCode()，子类没重写，这两个方法在子类vtable中的索引仍与父类对齐，但javap不会标出这个对齐关系。
立即学习“Java免费学习笔记（深入）”；
- 真正能观察
vtable的方式只有JVM调试接口（如JVMTI）或HotSpot源码级调试 - OpenJDK中，
InstanceKlass::vtable_length()和InstanceKlass::start_of_vtable()是入口点 - 想验证某个重写是否生效，更实际的做法是用
-XX:+PrintCompilation配合MethodHandle调用对比，而非猜索引
invokevirtual指令怎么靠vtable索引定位目标方法？
字节码里的invokevirtual指令本身不存索引值，它只持有一个常量池索引，指向一个CONSTANT_Methodref_info。真正查vtable发生在解释执行或JIT编译后的机器码里：JVM根据接收者对象的实际类，取出其vtable，再用该Methodref解析出的方法签名去匹配表中已有的槽位。
- 匹配逻辑不是字符串比对，而是基于
klass层级的符号解析结果缓存——所以首次调用稍慢，后续极快 - 如果子类重写了方法，对应槽位会被替换成子类的
Method*指针；没重写就沿用父类指针 - 注意：接口方法走的是
itable（interface table），不是vtable，机制完全不同，别混用
哪些情况会让vtable索引“失效”或无法优化？
所谓“失效”，其实是JVM无法安全假设目标方法固定，从而退回到慢路径（如查虚函数表+类型检查）。这和索引本身是否存在无关，而取决于运行时的不确定性。
- 存在多个实现类且调用目标在运行时才确定（比如工厂返回
Object，再强转调用） - 方法被JIT内联后又被去优化（deoptimization），此时可能临时绕过
vtable直接跳转 - 使用
Unsafe.defineAnonymousClass或动态代理生成的类，其vtable构建时机和稳定性不如普通类 - 开启
-XX:-UseClassHierarchyAnalysis会禁用类层次分析，让JVM不敢信任vtable槽位的稳定性
真正容易被忽略的是：vtable只服务于单继承下的虚方法分派。一旦涉及接口默认方法、Lambda重写、或invokedynamic引导，背后早就是另一套机制了——别试图用vtable索引去理解它们。
