invokevirtual通过固定偏移直取vtable实现常数级寻址，因java单继承保证方法索引稳定；invokeinterface需遍历vtable匹配签名，因接口多实现导致位置不确定，首次调用开销更大。
关键不在“调用谁”，而在“怎么找”。invokevirtual靠固定偏移直取，invokeinterface得遍历匹配——这就是两者寻址开销差异的本质。
invokevirtual：单继承保障的常数级寻址
Java 的单继承结构让每个非 final 实例方法在类的虚方法表（vtable）中拥有稳定索引。比如 Object.clone() 总在 vtable 第 0 槽，String.toString() 总在它自己 vtable 的某个固定位置。JVM 调用时，直接根据编译期确定的方法签名算出槽位编号，再从对象实际类型的 vtable 中按索引取地址。
- 无需遍历，一次内存访问即可定位目标方法
- 即使子类重写了该方法，也只是把对应槽位内容替换成子类实现地址，索引不变
- 新增方法不会挤占已有方法的位置，兼容性好
invokeinterface：多实现导致的线性搜索
一个类可以实现多个接口，同一接口方法在不同实现类的 vtable 中可能落在任意位置。JVM 编译期无法预知 Visitor.visit() 在 MyVisitor 类的 vtable 里是第几个槽，因此运行时必须：
- 先定位对象实际类型的 vtable
- 再逐个比对槽位中的方法签名，直到找到匹配项
- 哪怕该接口只被一个类实现，规范仍要求走完整遍历逻辑
首次调用开销明显，HotSpot 后期虽会用 inline cache 缓存“类+槽位”组合，但缓存未命中时仍要重走搜索流程。
字节码生成规则决定指令选择
选哪个指令，不看运行时对象是什么，而看变量声明类型：
- 声明为接口类型（如 Visitor v = new MyVisitor()）→ 生成 invokeinterface
- 声明为具体类或抽象类（如 MyVisitor v = new MyVisitor()）→ 生成 invokevirtual
- List.add() 总是 invokeinterface，因为 List 是接口；AbstractList.add() 则是 invokevirtual
泛型擦除后，Collection 接口方法调用也一律走 invokeinterface，和实际类型无关。
性能影响与优化提示
日常开发中多数场景感知不到差异，但在高频调用路径（如遍历 AST、序列化循环）中，接口调用的额外查找成本可能累积。可考虑：
- 对极致性能敏感的内部组件，优先用抽象类而非接口定义扩展点
- 避免在 tight loop 中反复通过接口引用调用同一方法（尤其未预热的冷路径）
- 留意 JIT 是否已对热点 invokeinterface 做 inline cache 优化（可通过 -XX:+PrintCompilation 观察）
不复杂但容易忽略：指令差异背后是语言模型与 VM 实现的深度耦合。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
