invokevirtual直接按固定偏移量查当前类vtable，因Java单继承保证重写方法索引不变；invokeinterface需遍历vtable查找匹配接口方法，因多实现导致位置不确定。
invokevirtual 怎么查虚方法表
它直接按固定偏移量查当前类的虚方法表（vtable）。比如 Object.clone() 在所有类 vtable 的第 0 个槽位，调用时虚拟机就直接取 this 对象所属类的 vtable[0]，不用遍历。
这种寻址快，因为 Java 单继承结构让重写方法在子类 vtable 中保持与父类相同索引。只要不删/改签名，哪怕新增方法也不会影响已有方法的位置。
- 只适用于类继承链上的非私有、非静态、非 final 实例方法
- final 方法虽用
invokevirtual指令调用，但因不可重写，实际走的是“伪虚调用”，JIT 常直接内联 - 如果父类方法被子类重写，子类 vtable 对应槽位会被替换成子类实现的地址，但索引不变
invokeinterface 为什么不能用固定偏移
接口方法没有单继承约束，一个类可实现多个接口，且同一接口方法在不同实现类中可能位于 vtable 不同位置。虚拟机无法预知 accept(Visitor) 在某个 Visitor 实现类的 vtable 里是第几个槽位。
所以 invokeinterface 必须先根据对象实际类型定位其 vtable，再遍历查找匹配接口方法签名的实现项——这个过程比 invokevirtual 多一次线性搜索，早期开销明显。
- 即使只实现一个接口，JVM 仍按规范走遍历逻辑，不作特殊优化
- 接口默认方法（Java 8+）和私有接口方法（Java 9+）不走
invokeinterface，而是用invokestatic或invokespecial - HotSpot 后期会做 inline cache 优化，缓存最近成功匹配的实现类+槽位，但首次调用仍需遍历
同一个方法调用，为啥有时生成 invokevirtual，有时是 invokeinterface
看编译期的**声明类型**，不是运行时的实际类型。比如：
Visitor v = new MyVisitor(); v.visit(expr); // 编译期类型是接口 Visitor → 生成 invokeinterface
而如果写成：
MyVisitor v = new MyVisitor(); v.visit(expr); // 编译期类型是具体类 → 生成 invokevirtual（前提是 visit 是 MyVisitor 自己定义的、非继承来的）
注意：即使 MyVisitor 是 Visitor 的唯一实现，只要变量声明为接口类型，字节码就是 invokeinterface。
- 泛型擦除后，List.add(E) 调用生成的是
invokeinterface，因为 List 是接口 - 抽象类的方法调用一律用
invokevirtual，哪怕该类只有抽象方法 - 不要指望靠“只有一个实现”就让 JVM 自动降级为 invokevirtual —— 字节码指令由 javac 决定，不是 JVM
性能差异在现代 JVM 中还明显吗
基本不明显。从 JDK 7 开始，HotSpot 对 invokeinterface 做了多层优化：第一次调用后记录命中类+槽位到 inline cache；多次调用同一实现类时，会退化为类似 invokevirtual 的快速路径；热点代码还会被 JIT 编译为直接跳转。
真正影响性能的，往往不是指令本身，而是接口调用带来的去虚拟化障碍——比如无法对 accept(Visitor) 做逃逸分析或标量替换，因为实现类不确定。
- 微基准测试中，两者差距通常在纳秒级，远小于一次内存分配或锁竞争
- 过度关注这个差异，容易忽略更关键的瓶颈，比如 Visitor 模式中频繁的对象创建或深度递归
- 如果你真在 profiler 里看到
invokeinterface占显著 CPU 时间，大概率是它背后的方法体太重，而不是指令慢
invokevirtual 和 invokeinterface 的寻址逻辑差异，暴露的是 Java 类型系统设计的根本权衡：单继承换来的确定性， vs 多实现带来的灵活性。这个差异在字节码层清晰可见，但在运行时早已被 JVM 抹平——除非你正在写 JIT 编译器。 
