lambda表达式本质是函数式接口实例，编译期生成invokedynamic指令和私有静态方法，运行期通过lambdametafactory引导动态生成实现类并绑定methodhandle。
invokedynamic 不是 Lambda 的“实现方式”，而是它能在 JVM 上不生成额外 .class 文件、不走匿名内部类路径的核心机制。你看到的 () -> System.out.println("ok")，背后根本没类文件，只有字节码里一条 invokedynamic 指令 + 一个引导方法调用。
invokedynamic 和 invokestatic 等指令的本质区别在哪
传统四条调用指令（invokestatic、invokevirtual、invokespecial、invokeinterface）都在字节码里写死了目标方法的符号引用——编译时就必须能 resolve 到某个具体类+方法签名。
invokedynamic 完全不同：它只占个位子，不指定目标，只关联一个引导方法（Bootstrap Method）。JVM 第一次执行它时，才去调这个引导方法，让它返回一个 CallSite；后续调用全走这个 CallSite，跳转到它绑定的 MethodHandle。
也就是说：
-
invokestatic是“编译期就定好去哪” -
invokedynamic是“第一次运行时才找人，找完后记住地址，以后直奔那儿”
Lambda 表达式编译后到底生成了什么
javac 不会为 Runnable r = () -> System.out.println("x"); 生成 MyClass.class，而是：
- 把 lambda 主体编译成一个私有静态方法，比如
private static void lambda$main$0() - 在调用位置插入一条
invokedynamic指令，指向常量池里的 BootstrapMethods 表项 - BootstrapMethods 表里明确写着：
LambdaMetafactory.metafactory，并附带三个关键参数：Runnable.class、run()V（接口抽象方法签名）、lambda$main$0()V（实际逻辑方法句柄）
你可以用 javap -v MyClass.class | grep -A 10 "invokedynamic" 看到这条指令，再搜 BootstrapMethods 就能看到 metafactory 被调用的全过程。
为什么调试时看到 $$Lambda$1/0x0000000800062040 这种名字
这是 JVM 动态生成的实现类名，不是 bug，也不是临时对象标记：
- 它对应一个匿名、
final、无构造器、不可反射实例化的类 - 该类实现了你写的函数式接口（如
Runnable），且run()方法体内只有一行：跳转到那个静态方法lambda$main$0 - 同一个 lambda 表达式多次执行，JVM 可能复用同一个实例（但不保证）；不同 lambda 即使代码一样，也绝不会共享类或实例
- 这个类不会出现在磁盘上，也不会被
ClassLoader.getSystemResources()扫到
MethodHandle 和 CallSite 在绑定中各自起什么作用
引导方法（如 LambdaMetafactory.metafactory）返回的是一个 CallSite 实例，它本质上是个可变指针容器：
-
CallSite持有一个MethodHandle，而这个MethodHandle指向的是你 lambda 编译出的静态方法（如lambda$main$0） -
MethodHandle不是普通反射对象，它是 JVM 原生支持的轻量级方法引用，能绕过访问控制检查，也能做类型适配（比如把(String) -> String的逻辑塞进Function<string string></string>接口） -
ConstantCallSite（Lambda 默认用的）一旦绑定，就不能改；还有MutableCallSite和VolatilCallSite，用于动态语言场景，Lambda 不用
真正执行 runnable.run() 时，JVM 不是查表找方法，而是直接通过 CallSite 里的 MethodHandle 跳过去——这比反射快得多，也比每次 new 内部类省内存。
最容易被忽略的一点是：Lambda 的“动态性”不在语法层面，而在字节码链接时机。它不依赖运行时类加载或反射，而是靠 JVM 原生的 invokedynamic + MethodHandle 机制完成延迟绑定——这也是为什么它既安全又高效。
