invokedynamic 是 JVM 唯一新增的字节码指令，用于运行时动态方法绑定而非支持动态类型；它通过引导方法（BSM）返回 CallSite 实现首次解析与后续缓存调用，支撑 Lambda、Groovy 等场景，但 Java 语言本身仍是静态类型。
Java 本身不是动态语言，invokedynamic 不是让 Java 变成动态类型语言的工具，而是 JVM 提供的一种机制，用来高效支撑那些运行时才确定调用目标的场景——比如 Groovy、JRuby、Scala 的方法分发，或者 Java 自己的 Lambda 表达式。
它解决的核心问题是：传统调用指令太“死”
在 invokedynamic 出现前，JVM 只有四条 invoke 指令（invokestatic、invokevirtual、invokespecial、invokeinterface），它们都依赖编译期就能确定的方法签名。哪怕只是想根据一个字符串名（如 "save"）去调一个对象的方法，也得靠反射——而反射慢、不可内联、有安全检查开销。
invokedynamic 把“调哪个方法”这件事从 JVM 内部逻辑里抽出来，交给开发者或编译器写的引导方法（Bootstrap Method）来决定。这个决定只做一次（首次执行时），之后直接走缓存的调用点（CallSite），性能接近 invokevirtual。
关键不在指令，而在引导方法怎么写
invokedynamic 指令本身不干具体事，它只负责触发引导方法。真正实现“动态”的，是引导方法返回的 CallSite 和其中封装的 MethodHandle：
立即学习“Java免费学习笔记（深入）”；
- 引导方法接收三个固定参数：MethodHandles.Lookup（用于查找方法）、方法名（String）、目标方法类型（MethodType）
- 它可以查反射、缓存 MethodHandle、甚至动态生成字节码（如 LambdaMetafactory 就会生成私有静态方法 + 匿名实现类）
- 返回 ConstantCallSite 表示目标固定；MutableCallSite 支持运行时热替换（比如灰度切换 handler）
真实高效的动态调用，其实是“半动态”
所谓“动态语言支持”，在 JVM 上落地时往往是有约束的高效模式：
- Lambda 表达式：javac 编译时把 () -> System.out.println("ok") 转成 invokedynamic，BSM 调用 LambdaMetafactory，生成一个私有静态方法和轻量级实现类，避免匿名内部类的类加载和 GC 开销
- Groovy 的 obj.name：不是 invokedynamic 直接读字段，而是 BSM 根据运行时类型调用 MetaClass.getProperty()，背后仍是标准方法调用
- RPC 或插件路由：根据字符串 action 名（如 "updateUser"）+ 固定参数类型，BSM 查 Map 缓存的 MethodHandle，跳过反射查找，复用 JIT 友好的句柄
它不做什么，同样重要
invokedynamic 不能替代语言层的设计：
- 它不支持动态字段访问（如 obj["userName"]）——字节码没有字段动态指令，getfield/putfield 都是硬编码的
- 它不绕过 Java 类型系统——所有 MethodType 参数类型仍需在运行时可匹配，泛型擦除后类型推断失败会导致 LinkageError
- 它不等于“任意字符串都能调”——如果 BSM 里写反射，性能瓶颈就回到反射本身，invokedynamic 只是包装了一层，并不加速反射
