invokedynamic指令在字节码中表现为索引占位符，如“invokedynamic #2, 0”，指向常量池BootstrapMethods表项；该表明确调用LambdaMetafactory.metafactory，并传入接口类型、抽象方法签名及编译器生成的lambda$main$0方法句柄。
invokedynamic 指令在字节码里长什么样
它不是一条能直接“看到逻辑”的指令，而是一个占位符：字节码中只存一个索引，指向常量池里的 BootstrapMethods 表项。你用 javap -v 查看类文件时，关键线索是这两处：
-
invokedynamic指令本身，后面跟着类似#2, 0的编号 —— 这个#2就是引导方法在 BootstrapMethods 表里的下标 -
BootstrapMethods:区块，里面明确写着invokestatic java/lang/invoke/LambdaMetafactory.metafactory:...，以及三个核心参数：Runnable.class、run()V、lambda$main$0()V
注意：没有 BootstrapMethods 表，或表里没调用 LambdaMetafactory.metafactory，那这个 invokedynamic 就不是 Lambda 生成的（可能是 Groovy 或 JRuby 的）。
调用点（CallSite）怎么被创建和复用
首次执行 invokedynamic 时，JVM 才真正干活：调用 LambdaMetafactory.metafactory，传入接口类型、抽象方法签名、实际逻辑方法句柄等参数，它返回一个 ConstantCallSite 实例。这个实例内部绑定了一个 MethodHandle，指向编译器生成的静态方法（如 lambda$main$0）。
- 后续每次执行同一条
invokedynamic指令，JVM 直接读取已缓存的CallSite，跳转到其getTarget()返回的MethodHandle - 同一个 Lambda 表达式多次执行，JVM 可能复用同一个
CallSite和底层实现类实例（但不保证）；不同 Lambda 即使代码相同，也绝不会共享CallSite - 这个过程完全绕过类加载器的
defineClass流程，所以你看不到磁盘上有$$Lambda$1.class文件
为什么调试时看到 $$Lambda$1/0x0000000800062040 这种名字
这是 JVM 动态生成的实现类的运行时类名，不是临时对象标记，也不是 bug。它对应一个真实、不可见、不可反射实例化的类：
- 该类实现了你写的函数式接口（比如
Runnable），且run()方法体只有一行：lambda$main$0(); - 类名中的数字部分（如
0x0000000800062040）是内存地址哈希，每次 JVM 启动都可能不同 - 它不会出现在
ClassLoader.getSystemResources("xxx.class")结果里，也无法通过Class.forName加载 - 如果你在断点里打印
lambda.getClass().getName()，看到的就是这个格式；用javap -cp . -s也反编译不出它
容易被忽略的关键点：Lambda 不是语法糖，而是字节码层的机制切换
很多人以为 invokedynamic 是 Java 编译器做的“优化”，其实不是：它把方法绑定这件事从编译期硬编码，彻底移交给了运行时。真正的动态性不在 Java 语言，而在 BootstrapMethod 的实现逻辑里 —— LambdaMetafactory.metafactory 只是其中一种，Groovy 的 BSM 可能做方法名查找+缓存，JRuby 的甚至会根据调用频次做多态内联。你看到的 () -> System.out.println("x")，背后根本没有类文件，只有一条指令 + 一次引导方法调用 + 一个可被 JVM 内联的 CallSite。一旦你开始用 ASM 修改字节码或写自定义 BSM，这个边界就立刻变得具体而锋利。
