invokespecial和invokestatic在解析阶段即可完成静态绑定，无运行时开销；invokevirtual需运行时查vtable动态分派；invokeinterface还需额外搜索itable，运行开销最大。
这三类指令在符号引用解析阶段的性能差异，核心不在“解析耗时”，而在于“是否需要解析”——invokespecial 和 invokestatic 在类加载解析阶段就能完成符号引用到直接引用的转换，属于静态绑定；而 invokevirtual 和 invokeinterface 必须延迟到运行期才能确定目标方法，无法在解析阶段完全解决，属于动态绑定。
invokespecial：解析阶段即可完成绑定
它调用的是构造器、私有方法、父类方法这三类非虚方法。JVM 在类加载的“解析”阶段，只要符号引用的目标明确且不可覆盖（比如 private 方法不可能被子类重写），就可直接将符号引用替换为内存中的直接引用。整个过程无运行时开销，也不依赖对象实际类型。
- 构造方法
<init></init>：每个类的构造器名固定、作用唯一，编译期已知 - private 方法：无法被继承或重写，调用目标绝对唯一
- super.xxx() 调用：明确限定为父类版本，不参与多态分派
invokevirtual：解析阶段仅做部分准备，真正分派在运行时
它用于调用普通实例方法（非 private、非 static、非 final 的非私有方法）。编译生成的字节码中只保留符号引用，JVM 在解析阶段不会**将其解析为具体方法地址**，而是留待运行时根据对象的实际类型（而非引用类型）查虚方法表（vtable）来定位目标方法。
- 例如：
Object obj = new ArrayList(); obj.toString();，虽然引用类型是 Object，但实际调用的是 ArrayList 的 toString() - 每次调用都要查 vtable，存在微小间接寻址成本（现代 JVM 有内联优化，但本质仍是动态分派）
invokeinterface：解析阶段几乎不解析，运行时开销更高
接口方法调用更复杂：一个接口可能被多个类实现，且实现类可在运行时动态加载。JVM 在解析阶段无法确定任何具体实现类的方法地址**，连 vtable 都无法提前绑定。必须等到运行时，根据 objectref 的实际类，搜索该类的接口方法表（itable），再匹配签名找到对应实现。
- 比 invokevirtual 多一层“接口→实现类”的映射查找
- 即使只有单个实现类，JVM 也不能跳过 itable 查找流程（规范要求）
- 实测表明，相同逻辑下 invokeinterface 比 invokevirtual 平均慢 10%–20%，尤其在未被 JIT 充分优化的场景
简单说：invokespecial 是“编译就知道调谁”，invokevirtual 是“运行看对象是谁再查表”，invokeinterface 是“运行看对象是谁，再翻它的接口实现索引”。解析阶段的“工作量”依次递减，但运行期的不确定性与开销依次递增。
