invokedynamic 的本质是将方法绑定从编译期移至首次执行时由引导方法动态决定并缓存，从而突破传统四条 invoke 指令必须静态确定目标的限制；其高性能源于调用点（callsite）复用与方法句柄（methodhandle）的 jit 可内联特性。
Java 7 引入 invokedynamic 不是为了“支持动态语言”这个抽象目标，而是为了解决传统四条调用指令（invokestatic、invokevirtual 等）在运行时无法变更目标方法的硬伤。它真正起效的方式，是把“方法该调谁”这件事从编译期绑定，移交到 JVM 第一次执行时由引导方法（Bootstrap Method）现场决定，并缓存结果——这才是高性能的根源。
invokedynamic 和 invokestatic 的本质区别在哪
关键不是“能不能动”，而是“什么时候定”。invokestatic 在字节码里就写死了类名、方法名、签名，JVM 加载类时就得 resolve 成具体地址；invokedynamic 字节码里只存一个索引，指向常量池里的 BootstrapMethods 表项，真正的方法目标直到第一次执行才生成。
这意味着：
- 同一个
invokedynamic指令，不同运行时刻可以链接到完全不同的MethodHandle（比如根据对象实际类型切换实现） - 后续调用直接走已绑定的
CallSite，跳转开销和invokevirtual基本持平，没有反射那样的权限检查或参数 boxing 开销 - 引导方法本身（如
LambdaMetafactory.metafactory）可被 JIT 编译，整个链路能内联优化
为什么 Lambda 表达式必须用 invokedynamic 而不是匿名内部类
匿名内部类方案（Java 8 之前）的问题不是功能缺失，而是性能与内存不可控：
- 每次 new 一个匿名类实例，都触发类加载、字节码验证、元空间分配，哪怕逻辑完全相同
- 每个实例都是独立对象，无法跨线程复用，GC 压力大
-
invokedynamic方案下，JVM 可复用同一个动态生成的类（如$$Lambda$1/0x0000000800062040），甚至复用实例（取决于CallSite类型） - 私有静态方法体（如
lambda$main$0）天然适合 JIT 内联，而匿名类的run()是虚方法，需查虚表
如何验证 invokedynamic 是否真被触发
别信 IDE 调试视图里看到的 $$Lambda$ 名字——那只是运行时类名，不等于 invokedynamic 生效了。要确认，得看字节码：
- 用
javap -v MyClass.class，搜索invokedynamic，确认存在且指向非空 BootstrapMethods 表项 - 再搜
BootstrapMethods:，看是否调用LambdaMetafactory.metafactory或自定义引导方法 - 注意：局部变量声明如
Runnable r = () -> {};一定会触发；但若仅用于Stream::map等高阶函数，某些 JDK 版本可能做逃逸分析后省略生成（JDK 17+ 更激进）
自己写引导方法时最容易踩的坑
自定义 invokedynamic（比如实现 DSL 或动态代理）时，核心陷阱不在逻辑，而在 JVM 对引导方法签名和返回值的强约束：
- 引导方法必须是
static，且参数固定为：Lookup lookup, String name, MethodType type，后面可追加任意常量池引用（如接口类、方法句柄等） - 返回值必须是
CallSite子类实例，不能是MethodHandle直接返回——否则 JVM 启动时报BootstrapMethodError -
ConstantCallSite一旦绑定不可变；若需热更新，必须用MutableCallSite并手动调用setTarget()，但会触发去优化（deoptimization） - 引导方法里抛异常（如
NoSuchMethodException）会导致整个invokedynamic指令永久失败，后续调用直接抛BootstrapMethodError，无法重试
真正难的从来不是“怎么写引导方法”，而是理解 JVM 如何把一条字节码指令、一个 CallSite 实例、一个 MethodHandle 的生命周期串成一条零拷贝的调用链——中间任何一环脱钩，性能优势就全没了。
