MethodHandle是轻量级强类型方法引用，模拟字节码调用；invokedynamic是唯一动态绑定指令，二者协同支撑Lambda等特性。
MethodHandle 和 invokedynamic 不是“变量指令”，而是 Java 虚拟机中支撑动态方法调用的两个核心机制：前者是运行时可执行的方法引用对象，后者是字节码层面唯一支持动态绑定的调用指令。它们协同工作，共同实现 Lambda 表达式、函数式接口实例化等高级特性。
MethodHandle 是什么：轻量级、强类型的方法调用句柄
MethodHandle 本质是一个可安全调用目标方法的强类型引用，类似反射中的 Method，但更底层、更高效：
- 它模拟的是字节码层面的方法调用（如
invokestatic、invokevirtual），而非 Java 语言层语义，因此 JVM 可对其invoke()做深度优化，接近直接调用性能 - 创建依赖
MethodHandles.Lookup，该查找器封装了访问权限控制逻辑，其findStatic/findVirtual/findSpecial方法分别对应不同字节码指令的权限校验规则 - 每个 MethodHandle 都绑定一个
MethodType，精确描述参数类型与返回类型；类型不匹配会在调用前抛出WrongMethodTypeException，而非运行时类型错误 - 它不携带方法元数据（如注解、异常表、源码行号），比反射轻量得多——只管“怎么调”，不管“是什么”
invokedynamic 指令如何触发动态绑定流程
invokedynamic 是 JVM 字节码中唯一不直接关联目标方法的调用指令。它的执行分两阶段：首次执行走引导（bootstrap），后续执行走缓存路径：
- 指令本身只携带一个常量池索引，指向 BootstrapMethods 属性中定义的引导方法（BSM）
- 首次执行时，JVM 自动传入三个参数给 BSM：
Lookup（有权限访问私有静态 lambda 方法）、String（函数式接口抽象方法名，如"apply"）、MethodType（对外契约签名，由接口定义决定） - BSM（如
LambdaMetafactory.metafactory）根据这三要素解析出实际逻辑方法（如lambda$main$0），构造并返回一个CallSite实例 -
CallSite是个可变指针容器，内部持有一个MethodHandle；后续所有对该 invokedynamic 的调用，都直接委托给该句柄执行
Lambda 表达式背后的绑定细节：MethodType 与实际方法签名为何可以不同
这是理解 invokedynamic 灵活性的关键点。编译器生成的 lambda 实现方法（如 private static String lambda$makeAdder$0(int, String)）签名，常常和函数式接口抽象方法（如 Function<String, String>.apply(String)）不一致：
- 差异源于捕获变量：若 lambda 引用了外部局部变量（如
int x = 5;），编译器会把该变量作为额外参数塞进生成方法的参数列表 - 而传递给 BSM 的
MethodType始终反映用户看到的接口行为（即(String)String），不是真实方法签名 - BSM 内部通过
MethodHandle.asType()或适配器链，将真实方法句柄“重签名”为符合接口契约的形式，完成参数映射与类型转换 - 这种分离使得 JVM 能在不修改字节码的前提下，灵活支持闭包语义
CallSite 的角色：连接引导逻辑与运行时调用的桥梁
CallSite 不是接口也不是抽象类，而是一个具体类（java.lang.invoke.CallSite），它有三种子类，对应不同优化策略：
-
ConstantCallSite：目标方法固定不变，如无捕获变量的静态 lambda；一旦链接，永不变更 -
MutableCallSite：允许运行时通过setTarget()动态切换句柄，适合热替换或条件分支场景 -
VolatleCallSite：线程安全版本，适用于多线程频繁更新目标的场景 - Lambda 默认使用
ConstantCallSite，确保高性能且不可变；JVM 对其调用做了内联与去虚拟化优化
