Java中方法调用指令由编译期类型和修饰符决定：invokestatic用于静态绑定（static/private/构造器），invokevirtual用于虚方法调用（支持多态），invokespecial强制调用当前类版本（构造器/private/super），invokeinterface用于接口方法，invokedynamic支持动态语言和Lambda的运行时绑定。
Java 中 invokestatic 和 invokevirtual 到底选哪个
看字节码时发现：同样是调用一个方法，有的生成 invokestatic，有的是 invokevirtual——这不是编译器随便选的，而是由绑定时机决定的。静态绑定在编译期就确定目标方法（比如 static、private、构造器），运行时直接跳转；而多态方法必须靠 invokevirtual，JVM 在运行时查虚方法表（vtable）才能定位真正要执行的版本。
-
invokestatic不查 vtable，快，但不支持重写；invokevirtual每次都要查，有开销，但支持子类覆盖 - 哪怕你写了
obj.method()且method()是public非final，只要声明类型是父类，JVM 就得留出多态余地，必须用invokevirtual - 注意
final实例方法会被 JVM 优化成静态绑定（JIT 可能内联），但字节码里仍是invokevirtual——这是运行时优化，不是编译期决定的
为什么 invokespecial 不能用于普通重写方法
看到 invokespecial 就该想到：它绕过虚方法分派，强制调用“当前类声明的那个版本”。所以它只用于三种情况：构造器、private 方法、super.xxx() 显式调用父类方法。如果你试图用反射或字节码工具强行对一个可重写方法发 invokespecial，JVM 会直接抛 IllegalAccessError 或 IncompatibleClassChangeError。
- 子类中写
super.toString()→ 编译成invokespecial，安全 - 子类中写
this.toString()→ 编译成invokevirtual，走多态 - 用
MethodHandle+MethodType.INVOKE_SPECIAL调用非构造/非私有/非 super 方法 → 运行时报错，不是权限问题，是语义违规
接口方法调用为什么用 invokeinterface 而不是 invokevirtual
接口没有 vtable，只有 itable（接口方法表）。JVM 必须在运行时根据对象实际类去查 itable 才能找到接口方法的具体实现。虽然 JDK 8+ 接口可以有 default 方法，但只要它是通过接口变量调用的（比如 CharSequence cs = "abc"; cs.length();），就一定走 invokeinterface，哪怕底层实现类里 length() 是 final 的。
-
invokeinterface开销比invokevirtual更大，因为 itable 查找更复杂（要考虑多个接口继承关系） - 如果把接口引用转成实现类引用再调用（
((String)"abc").length()），编译器可能生成invokevirtual——但这依赖于编译期类型推断，不是总能发生 - 逃逸分析后 JIT 可能优化掉部分接口调用开销，但字节码层面无法绕过
invokeinterface指令
invokedynamic 真正解决的是什么问题
它不是为“让 Java 支持闭包”这种高大目标设计的，而是为了解决动态语言在 JVM 上长期卡在方法查找性能上的死结。比如 JRuby 的 obj.foo，在 Ruby 里可能是字段读取、方法调用、missing_method 响应，甚至元编程拦截——这些行为在编译期完全不可知。JVM 不能靠查 vtable 或 itable 解决，必须允许运行时注册真正的调用逻辑（即 CallSite）。
- Lambda 表达式底层就是
invokedynamic：首次执行时触发LambdaMetafactory.metaFactory，生成并缓存函数式接口实现类 - 不要以为用了
invokedynamic就一定慢——JIT 对稳定CallSite会持续优化，最终可能和直接调用一样快 - 手写
invokedynamic极易出错：BootstrapMethodError常见于MethodHandle类型不匹配，或CallSite返回的 target 不符合接口签名
