Lambda表达式依赖JVM的invokedynamic指令实现动态绑定，首次执行时由LambdaMetafactory引导生成CallSite并绑定MethodHandle，主体编译为私有静态方法，运行时动态生成不可预测的$$Lambda$N类，避免类膨胀且支持JIT优化。
Lambda 表达式不是语法糖的简单替换，它的运行依赖 JVM 层面的一套全新调用机制——invokedynamic。理解它，关键不是看 Java 源码怎么写，而是看字节码里那条指令如何被 JVM “激活”。
invokedynamic 不是调用，而是“委托第一次决策”
传统 invokestatic 或 invokevirtual 在编译时就锁死了目标方法：类名、方法名、签名全固定。而 invokedynamic 字节码里只写着“去常量池第 X 项找引导方法”，不指明具体调谁。
- 首次执行该指令时，JVM 主动调用关联的引导方法（Bootstrap Method），例如
LambdaMetafactory.metafactory - 引导方法根据上下文（接口类型、抽象方法签名、Lambda 实际逻辑的方法句柄等）动态生成适配类，并返回一个
CallSite - 后续所有相同 invokedynamic 指令都跳过引导，直接通过 CallSite 调用已绑定的
MethodHandle
Lambda 对应的逻辑藏在私有静态方法里
javac 编译 Lambda 时不会生成 .class 文件，但会把表达式主体编译成一个私有方法：
- 无捕获变量 → 生成
private static void lambda$xxx$0(...) - 捕获了 this 或实例字段 → 生成实例方法，参数隐含当前对象引用
- 捕获局部变量（如 int x）→ 方法参数增加对应类型，由 JVM 封装进闭包对象传递
用 javap -p MyClass.class 可验证该方法是否存在；若找不到，可能是 JIT 后期内联优化所致，但 invokedynamic 指令仍保留在字节码中。
引导方法返回的 CallSite 是性能关键
CallSite 相当于一个可变跳转地址，JVM 对它做了深度优化：
- 首次绑定后，后续调用走直接跳转，开销接近 invokevirtual
- 稳定调用点可能被 JIT 内联为普通方法调用
- 相同结构的 Lambda（如多个 () -> System.out.println("ok")）可能共享同一个动态类实例
- 类字节码由 JVM 运行时用 ASM 动态生成，不落地磁盘，也不进类路径
常见异常指向引导阶段的具体失败点
报错不是 Lambda 写错了，而是 invokedynamic 初始化环节出了问题：
-
ClassNotFoundException: $$Lambda$1/0x0000000800062040→ 引导方法已成功生成类，但类加载被 SecurityManager 拦截或类路径污染导致失败 -
WrongMethodTypeException→ 函数式接口抽象方法签名与引导方法传入的MethodType不匹配，常见于泛型擦除后参数类型失配、返回值不一致
