Lambda表达式编译后生成形如外部类名$$Lambda$数字.class的字节码文件，使用invokedynamic指令动态绑定，而非匿名内部类的外部类名$数字.class形式。
Java 编译器对 Lambda 表达式的处理不是简单地“翻译成内部类”，而是通过 invokedynamic 指令 + 引导方法（Bootstrap Method）动态生成实现类。但最终，JVM 仍会生成一个真实存在的、带特定命名规则的字节码类——它虽由 JVM 运行时或编译器辅助生成，却可被反编译观察到。
Lambda 表达式对应类的命名格式
编译后，每个 Lambda 表达式会生成一个形如：
外部类名$$Lambda$数字.class的独立字节码文件。注意是两个美元符 $$，而非单个 $（区别于普通内部类）。
- 例如：在
Main.java中写了一个 Lambda，编译后可能出现Main$$Lambda$1.class - 若同一类中存在多个 Lambda，编号通常从 1 开始递增：
$$Lambda$1、$$Lambda$2……但不保证严格连续（受编译器优化、内联、重复 Lambda 合并等影响） - 该类名是 JVM 规范允许的合法二进制名，
$在 Java 字节码中是合法标识符分隔符
为什么不是普通匿名内部类？
传统匿名内部类（如 new Runnable(){...}）编译后生成的是：
例如 Main$1.class。而 Lambda 不走这条路，原因包括：
- 匿名内部类会捕获
this或局部变量并生成字段，带来额外内存与构造开销 - Lambda 默认不持有外围实例引用（除非显式访问
this或实例成员），更轻量 - JVM 利用
invokedynamic延迟绑定，支持运行时缓存、复用相同语义的 Lambda 实例 - 避免为每个 Lambda 都生成独立 .class 文件（实际仍会生成，但机制更可控）
如何验证命名规则？
通过标准 JDK 工具链可直接观察：
- 写一个含 Lambda 的类（如
Main），编译：javac Main.java - 查看生成的 class 文件：
ls *.class→ 可见Main.class和Main$$Lambda$1.class（可能还有 $2、$3） - 用
javap -c Main查看字节码，在调用处会看到invokedynamic #X，再查常量池可定位引导方法指向LambdaMetafactory.metafactory - 反编译 Lambda 类：
javap -c -p "Main$$Lambda$1.class"，可见其继承java.lang.Object并实现目标函数式接口，但无源码级构造逻辑
补充：Lambda 方法体的静态辅助方法
除了生成的 $$Lambda$N 类，编译器还会在原外部类中生成私有静态方法，封装 Lambda 的实际逻辑，命名如：
例如：lambda$main$0、lambda$process$1。这些方法被 invokedynamic 的引导方法引用，作为 Lambda 执行体的真正入口。
- 它们是
static、private、带完整参数签名，不依赖对象状态 - 若 Lambda 访问了外部类实例成员，则该方法会接收一个隐式参数（即外围实例引用），编译器自动注入
- 可通过
javap -p Main.class | grep lambda快速定位
