invokedynamic 是 JVM 唯一新增的字节码指令，用于动态方法绑定而非支持动态类型；它通过引导方法（BSM）返回 CallSite 实现运行时方法解析，提升 Lambda、Groovy 等语言的性能与灵活性，但 Java 语言本身仍是静态类型。
invokedynamic 不是 Java 语言层面的“动态类型支持”，而是 JVM 层面对动态方法绑定能力的补全；Java 语言本身仍是静态类型，但通过它，JVM 能高效承载 Lambda、Groovy、JRuby 等需要运行时方法解析的场景。
invokedynamic 是 JVM 唯一新增的字节码指令，不是语法糖
从 JDK 7 到现在（2026 年），JVM 字节码指令集只新增了 invokedynamic 这一条。它不对应任何 Java 关键字或语法结构，而是一个纯粹的执行引擎机制升级。编译器（如 javac）在遇到 Lambda 表达式或某些动态调用模式时，会主动插入 invokedynamic 指令，而不是生成 invokestatic 或匿名类字节码。
常见误解是把它当成“Java 支持动态类型”的证据——其实不然：Java 源码仍需完整类型声明，编译期仍做严格类型检查。真正变的是字节码层的调用模型。
- 传统指令（
invokevirtual、invokeinterface）依赖编译期确定的符号引用（CONSTANT_Methodref_info） -
invokedynamic指令本身不携带目标方法符号，只存一个引导方法索引 + 静态参数 - 首次执行时才调用引导方法（Bootstrap Method），由它返回一个
CallSite，后续复用
引导方法（BSM）才是动态逻辑的实际控制点
引导方法是普通 Java 方法，但签名固定，必须接受 MethodHandles.Lookup、String（方法名）、MethodType 和可选的静态参数。它的返回值必须是 CallSite 子类（通常是 ConstantCallSite 或 MutableCallSite）。
立即学习“Java免费学习笔记（深入）”；
这个设计把“方法怎么找、怎么生成、要不要缓存”的决策权交给了应用层，而非 JVM 内部硬编码逻辑。例如：
- Java 8 的 Lambda 编译器生成的 BSM，会用
LambdaMetafactory.metafactory动态生成私有静态方法 + 实现类，再封装成MethodHandle - Groovy 的 BSM 可能根据
String方法名 + 运行时对象类型，反射查找或缓存MetaMethod - JRuby 的 BSM 甚至会基于 Ruby 方法表和 call site profile 做多态内联优化
也就是说，invokedynamic 本身不“动态”，它只是提供了一个标准入口；真正的动态性来自你写的（或编译器生成的）BSM。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
为什么不用反射？性能与安全边界在这里被重新定义
过去想实现类似效果，只能靠 Method.invoke()，但它有三重开销：访问检查、参数装箱/解包、无 JIT 内联机会。而 invokedynamic 的调用链路是：
invokedynamic →（首次）BSM → CallSite.target（MethodHandle）→ 直接跳转到目标方法字节码
JVM 对 MethodHandle 调用做了深度优化：热点路径下可内联、可去虚拟化、可逃逸分析。更重要的是，MethodHandles.Lookup 的权限在 BSM 执行时已由 JVM 校验过一次，后续调用不再重复检查。
- 反射调用每次都要走
AccessibleObject.setAccessible(true)流程，且受 SecurityManager 限制 -
MethodHandle是“能力对象”（capability object），权限随 lookup 实例绑定，更细粒度、更可控 - JIT 编译器对
MethodHandle调用的优化程度远高于反射，实测吞吐量可差 5–10 倍
invokedynamic 不解决“类型擦除”或“运行时类型变更”问题
容易混淆的一点是：JS 或 Python 中 obj.method() 能在运行时根据 obj 实际类型查方法，而 Java 即使用了 invokedynamic，也依然要求 obj 至少声明为某个接口或基类，否则编译失败。比如：
Object obj = getDynamicObject(); obj.toString(); // ✅ 编译通过（Object 有 toString） obj.customMethod(); // ❌ 编译错误：找不到符号
这说明 invokedynamic 并未改变 Java 的编译期类型系统。它只让“已知签名的方法调用”可以延迟绑定，而不是让“任意方法名 + 任意参数”的调用变成合法 Java 代码。
真正突破类型边界的，是像 var（局部变量类型推导）、sealed 类、或 Project Valhalla 的值类型——它们属于语言演进；而 invokedynamic 属于执行引擎演进，两者目标不同，不可混为一谈。
