invokedynamic不模拟动态分派，而是提供运行时绑定调用点的能力；它通过BootstrapMethod返回CallSite，由用户控制链接逻辑，绕过虚方法表查找，用于Lambda表达式和动态语言实现。
invokedynamic 本身不模拟动态分派，它提供的是运行时绑定调用点的能力；Java 的动态分派（如 invokevirtual）是基于类继承结构的虚方法表查找，而 invokedynamic 是完全脱离类型系统的、由用户控制的链接机制。
invokedynamic 的核心作用：延迟绑定调用目标
它不是为“模拟动态分派”设计的，而是为支持动态语言（如 JRuby、Groovy）在 JVM 上高效实现方法调用、属性访问等行为。JVM 在首次执行 invokedynamic 指令时，会调用用户提供的 BootstrapMethod，该方法返回一个 CallSite；后续调用直接走这个 CallSite 的 target（即实际 MethodHandle）。这个过程绕过了编译期签名检查和虚方法表查找。
- 每次
invokedynamic指令对应一个独立的CallSite实例，可被反复重写（setTarget），实现行为热替换 - 它不依赖接收者类型（即没有 “this” 类型约束），也不参与 Java 的重载解析或重写决议
- 典型使用场景是 Lambda 表达式（通过
LambdaMetafactory.metafactory生成函数式接口实例），而非模拟多态调用
为什么不能直接用来“模拟动态分派”
Java 动态分派的关键在于：调用目标由运行时 this 的实际类型 + 方法签名共同决定，且需满足继承关系与访问控制。而 invokedynamic 的 BootstrapMethod 接收的参数是固定的（Lookup, name, type, …），不自动传入调用者对象，更不会根据 this 类型查表。
- 若强行模拟，你得自己在
BootstrapMethod中解析调用点上下文（比如从栈帧取this），再手动做类型判断和方法查找——这既低效，又破坏 JVM 原生分派语义 - 无法享受 JIT 对
invokevirtual的优化（如内联缓存、单态假设），反而因CallSite可变导致去优化 - 编译器不会为你生成
invokedynamic来替代invokevirtual，除非你手写字节码或用 ASM/Byte Buddy 改写
真要“动态选择行为”，优先走标准路径
对绝大多数需求，用 Java 原生机制更安全、高效：
- 需要运行时按类型分发？用
instanceof+ 显式分支，或 Visitor 模式 - 需要策略切换？用依赖注入（如 Spring
@Qualifier）或工厂 + Map> - 需要类似 Groovy 的 methodMissing？那确实得用
invokedynamic+MethodHandle构建通用转发逻辑，但这是动态语言运行时的责任，不是 Java 静态类型的补丁 - 若必须介入字节码层面，注意
invokedynamic的MethodType必须严格匹配调用点描述符，否则抛InvokeDynamicBootstrapError
真正容易被忽略的是：JVM 对 invokedynamic 的链接结果（CallSite.target）有强缓存行为，一旦设为 ConstantCallSite 就不可变；而 MutableCallSite 或 VolatilityCallSite 的更新会触发去优化——这不是“灵活”，而是代价明确的权衡。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
