LambdaMetafactory是invokedynamic首次执行时的“装配车间”，它接收函数式接口类型、抽象方法签名和实际逻辑的方法句柄，动态生成并返回绑定MethodHandle的CallSite，不执行业务逻辑而专责构造可运行的函数式接口实例。
LambdaMetafactory 是 invokedynamic 指令首次执行时真正干活的“装配车间”，它不执行业务逻辑，而是根据上下文动态组装出能跑起来的函数式接口实例。
它不是调用目标，而是生成调用目标的工厂
当你写 r = () -> System.out.println("ok")，字节码里只有一条 invokedynamic #2, 0。这条指令本身不指向任何具体方法——它只告诉 JVM：“去 BootstrapMethods 表里找第 2 项，调它的引导方法”。而那一项，固定是 LambdaMetafactory.metafactory。
- 它接收三类核心输入：函数式接口类型（如
Runnable.class）、抽象方法签名（如run()V）、实际逻辑的方法句柄（指向你编译生成的lambda$main$0()V） - 它不返回一个值，而是返回一个
CallSite，里面绑定了一个MethodHandle，这个句柄才真正指向可执行的代码 - 整个过程发生在运行时，且仅首次触发；后续调用直接走缓存，跳过 metafactory
它决定闭包如何绑定，包括参数怎么塞进去
如果 Lambda 捕获了外部变量（比如 float a = 1.2f; Function<Float, Float> f = b -> a + b;），编译器会把逻辑编译成双参数静态方法 lambda$makeAdder$0(Float a, Float b)。但你在代码里调用 f.apply(4.56f) 仍只传一个参数。
- LambdaMetafactory 在生成 CallSite 时，会把捕获的
a封装进最终的实现对象（如$$Lambda$1）内部 - 当
apply()被调用，适配器自动把a作为首参、4.56f作为次参，转发给底层静态方法 - 这个“参数注入”对开发者完全透明，全由 metafactory 在构造阶段完成适配
它控制类的生成方式和生命周期
metafactory 决定是否复用已有类、是否生成私有桥接方法、是否需要闭包对象——这些选择直接影响运行时行为。
- 在 JDK 8–15，它通过
Unsafe.defineAnonymousClass创建无名类；JDK 15+ 改用Lookup.defineHiddenClass，支持更强的隔离与卸载控制 - 生成的类没有规范类名（如
MyClass$$Lambda$1/0x0000000800062040），不参与双亲委派，也不出现在ClassLoader.getLoadedClasses()中 - 但它真实占用元空间（Metaspace），结构完整（Klass、vtable、常量池副本等），卸载依赖 JVM 内部机制，容易引发内存缓慢增长
它暴露的错误信号就是调试入口
当 Lambda 报错，异常堆栈里的线索往往直指 metafactory 的输入不匹配：
-
ClassNotFoundException带$$Lambda$1/0x...类名 → 说明 metafactory 已成功生成类，但后续类加载失败（SecurityManager 拦截、类路径污染等） -
WrongMethodTypeException→ 函数式接口抽象方法签名与 metafactory 接收的MethodType不一致（泛型擦除后类型错、参数顺序反、返回值不符） - 这类问题无法靠源码排查，必须结合
javap -v看 BootstrapMethods 表中传入的三个 MethodType 是否对得上
