invokedynamic指令通过引导方法动态生成CallSite并绑定MethodHandle，实现函数接口的运行期组装。它不携带目标方法信息，仅依赖引导方法、方法名和MethodType三项元数据，在首次执行时调用引导方法返回CallSite，后续调用经由callSite.getTarget().invokeExact执行，支持Constant/Mutable/Volatile三种可变性策略，Lambda实例无需生成.class文件，直接由JVM分配内存并持MethodHandle引用，调用性能接近直接调用。
虚拟机通过 invokedynamic 指令在运行期动态组装函数接口，核心在于把“方法绑定”这件事从 JVM 内部逻辑中剥离出来，交由开发者控制——不是靠编译时写死签名，而是靠运行时执行一个引导方法（Bootstrap Method），生成并绑定一个调用点（CallSite），再让这个调用点指向一个真正可执行的方法句柄（MethodHandle）。
invokedynamic 不是直接调用方法，而是调用一个“可变的入口”
普通指令如 invokevirtual 在字节码里就明确写了类、方法名和描述符，JVM 解析后直接跳转。而 invokedynamic 指令本身不携带目标方法信息，只带三项关键元数据：
- 一个引导方法（在常量池中以
MethodHandle形式引用） - 一个方法名（字符串，比如
"apply"或"get"） - 一个方法类型（
MethodType，即参数+返回值的签名，如(Object)String）
这些信息共同构成“调用点限定符”，JVM 首次执行该指令时，会用这三样东西去调用引导方法，让它返回一个 CallSite 实例。
引导方法负责组装函数接口的适配逻辑
引导方法是一个静态方法，签名固定为：
public static CallSite bootstrap(Lookup lookup, String name, MethodType type, ...)它由用户编写或工具（如 javac）自动生成，作用就是根据当前上下文“拼出”一个符合函数式接口语义的目标行为。例如 Lambda 表达式 x -> x.length() 对应的函数接口是 Function<string integer></string>，javac 会：
- 生成一个私有静态方法实现该逻辑（如
private static Integer lambda$1(String x) { return x.length(); }） - 在引导方法中用
Lookup.findStatic(...)获取该方法的MethodHandle - 用
LambdaMetafactory.metafactory(...)包装成适配Function接口的句柄链 - 最终返回一个绑定了该句柄的
ConstantCallSite
这个过程完成了“把一段代码逻辑”动态挂载到“某个函数接口实例”上，整个对象（如 Function）根本不需要提前定义类文件。
调用点（CallSite）是运行期可替换的执行枢纽
一旦引导方法返回 CallSite，JVM 就把这个调用点与该 invokedynamic 指令永久绑定。后续每次执行，都等价于调用 callSite.getTarget().invokeExact(...)。关键在于：CallSite 的 setTarget() 可被程序主动修改（对 MutableCallSite 或 VolatileCallSite），意味着函数行为可在运行中热替换。
-
ConstantCallSite：目标不可变，适合 Lambda 这类一次性绑定场景 -
MutableCallSite：支持setTarget，可用于脚本语言的重定义、AOP 动态织入 -
VolatileCallSite：线程安全版的可变调用点
也就是说，“函数接口实例”的本质，就是一个包装了 MethodHandle 的轻量对象；它的行为不来自类定义，而来自运行期注入的调用点。
函数接口的实例化完全绕过 new 和类加载
传统接口实现需要编译出 .class 文件，再通过 new 或反射构造实例。而 invokedynamic 驱动的函数接口实例（如 Lambda）：
- 不生成独立类（除非启用
-Djdk.internal.lambda.dumpProxyClasses） - 不走
ClassLoader.defineClass流程 - 实例内存布局由 JVM 直接分配，内部仅持有一个
MethodHandle引用 - 每次调用都经由
MethodHandle.invokeExact，跳过虚方法表查找，性能接近直接调用
这种机制让函数式编程脱离了“面向对象的模板束缚”，真正实现了“行为即对象、对象即调用点”的运行期组装范式。
