invokedynamic 通过延迟绑定将 lambda 编译为动态生成的私有静态方法和匿名 final 类，由 lambdametafactory 在运行时生成，避免了匿名内部类的性能与体积开销。
invokeDynamic 是怎么把 Lambda 变成对象的
Java 编译器不会在编译期就把 Lambda 实例化成具体类，而是生成一条 invokedynamic 指令，把“到底用哪个实现”这件事推迟到运行时决定。这个指令背后绑着一个叫 CallSite 的东西，第一次执行时会触发 BootstrapMethod（通常是 LambdaMetafactory.metafactory），动态生成一个私有静态方法 + 一个实现了函数式接口的类——整个过程对开发者完全透明。
常见错误现象：ClassNotFoundException 报错里出现一串带 $$Lambda 开头的类名，说明 invokedynamic 已经触发了类生成，但后续加载失败（比如类路径污染、SecurityManager 拦截）；或者 MethodHandle.invoke 抛 WrongMethodTypeException，大概率是签名没对齐。
-
BootstrapMethod参数必须和函数式接口抽象方法签名严格匹配，参数顺序、泛型擦除后类型、返回值都不能错 - 生成的 Lambda 类是匿名的、final 的、不带构造器的，不能被反射实例化，也不能被序列化（除非函数式接口自己声明
Serializable） - 同一个 Lambda 表达式在多次调用中可能复用同一个实例（JVM 优化），但不保证；不同 Lambda 表达式即使逻辑相同，也绝不会共享实例
为什么不用 inner class 而要用 invokedynamic
早期 Java 8 预研阶段真试过用匿名内部类实现 Lambda，结果发现开销太大：每次 new 都要分配对象、触发类加载、增大元空间压力，而且无法做方法内联优化。而 invokedynamic 让 JVM 可以在运行时选择最合适的策略——比如把无捕获变量的 Lambda 编译为单例静态方法句柄，有捕获的才生成闭包对象。
性能影响很实际：无状态 Lambda（如 () -> 42）基本等价于静态方法调用，热点代码能被 JIT 完全内联；而传统匿名类哪怕空实现，每次调用都有对象分配 + 虚方法分派成本。
- 内部类方式会导致每个 Lambda 表达式都生成独立 .class 文件，打包体积膨胀，启动变慢
-
invokedynamic允许 JVM 后续升级优化策略（比如 JDK 10+ 对某些场景做了更激进的缓存），而字节码一旦固定就改不了 - 调试时看到
$$Lambda$1/0x0000000800062040这种名字别慌——它不是 bug，是 JVM 动态命名机制，不影响功能
如何观察 invokedynamic 指令的真实行为
直接看字节码最靠谱。用 javap -v 打开编译后的 class，搜 invokedynamic，你会看到它指向一个 BootstrapMethods 表项，里面明确写着 metafactory 和几个关键参数：函数式接口类型、lambda 方法签名、实现方法句柄。
容易踩的坑：用 ASM 或 Javassist 修改含 Lambda 的类时，如果没正确处理 BootstrapMethods 属性，会导致 ClassFormatError: Invalid BootstrapMethods attribute；还有人试图用 Unsafe.defineAnonymousClass 模拟 Lambda 生成，结果因缺少 CallSite 绑定而失败。
- 示例命令：
javap -v MyClass.class | grep -A 5 "invokedynamic" - 注意
MethodHandle的kind字段：10 是INVOKESTATIC（对应无捕获），6 是INVOKEVIRTUAL（有 this 捕获），要和实际语义一致 - JDK 自带的
java.lang.invoke.LambdaMetafactory是 public 的，但不建议直接调用——它面向 JVM 实现，参数顺序和语义极易出错
Lambda 序列化失败时 invokeDynamic 在哪背锅
只要函数式接口没显式继承 Serializable，哪怕 Lambda 本身没捕获任何变量，invokedynamic 生成的类也不会实现该接口，反序列化必然抛 InvalidClassException。这不是 bug，是设计使然：JVM 不会自动给动态类加接口，必须由开发者明确表达意图。
更隐蔽的问题是：捕获了局部变量的 Lambda，如果那个变量类型不可序列化（比如某个非 Serializable 的自定义对象），即使接口声明了 Serializable，序列化时仍会在运行时报 NotSerializableException，堆栈里看不到 invokedynamic，但它确实是源头——因为闭包字段就是从这里塞进去的。
- 修复方式只有两个：
Serializable必须写在函数式接口上（如Runnable & Serializable），且所有捕获变量类型也得可序列化 - 不要依赖 IDE 自动生成的
serialVersionUID，Lambda 类没有源码，它的 UID 是运行时算的，跨 JVM 版本可能不一致 - 测试序列化不能只测“能跑通”，得在独立 ClassLoader 里反序列化，否则可能误判（同 ClassLoader 下类可能被缓存）
真正麻烦的是那种嵌套多层、捕获了外部类 this 的 Lambda——你得一层层检查所有隐式引用的对象是否可序列化，这时候 invokedynamic 不是问题，只是把问题藏得更深了一点。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
