Lambda 和匿名内部类生成的字节码完全不同

一句话结论（30s）

Lambda 不是匿名内部类的语法糖，因为匿名内部类在编译期由 javac 钉死成 .class 文件，而 Lambda 通过 invokedynamic 在运行期由 LambdaMetafactory 动态生成类。关键设计是延迟绑定——把”如何实现函数式接口”的决策推迟到运行期，让无捕获 Lambda 成为单例、class 只生成一次；代价是多一次首次调用的 Bootstrap 开销。

核心原理（2min）

编译期 javac 只生成一条 invokedynamic 指令（附 LambdaMetafactory.metafactory 的 Bootstrap 方法），首次执行时 JVM 调用 Bootstrap 用 ASM 在内存中生成实现接口的类并绑定到 ConstantCallSite，后续调用直接走 CallSite 不再查 Bootstrap。匿名内部类则是编译期生成 .class 并 invokespecial 直接实例化——一个是运行期动态生成（不落盘、无捕获可单例、策略可升级），一个是编译期静态钉死。

底层深入（5-10min）

同一个接口，完全不同的生成方式

// 方式 1：匿名内部类
Runnable r1 = new Runnable() {
    @Override
    public void run() {
        System.out.println("hello");
    }
};

// 方式 2：Lambda
Runnable r2 = () -> System.out.println("hello");

看起来功能一样，但在字节码层面，匿名内部类生成了一个 .class 文件，Lambda 一个都没有。

💭 思考：为什么同一个接口，匿名内部类要生成 .class 而 Lambda 不用？因为匿名内部类是编译期就「钉死」的新类，javac 直接把它编译成 Main$1.class；Lambda 只发出一条 invokedynamic 指令，把「生成什么类」推迟到运行期，由 LambdaMetafactory 在内存里动态生成。

匿名内部类的字节码

javac 编译后会生成 Main$1.class——每个匿名内部类都对应一个独立的 class 文件。内部调用是：

new #7  // class Main$1
dup
invokespecial #8  // Method Main$1."<init>":()V

invokespecial 直接调用 Main$1 的构造器，这个类在编译时已经确定，运行时只是加载并使用。

💭 思考：匿名内部类的代价是什么？每个匿名类一个 class 文件，N 个匿名类就是 N 个 .class，要逐个类加载；每次 new 一个新实例，即使逻辑完全相同也不复用。这些在 Lambda 时代都变成了可优化的点。

Lambda 的字节码：invokedynamic

javap -c -v 反编译 Lambda 版本：

invokedynamic #7, 0  // InvokeDynamic #0:run:()Ljava/lang/Runnable;
  Bootstrap: #8 REF_invokeStatic LambdaMetafactory.metafactory:
    (MethodHandles$Lookup, String, MethodType, MethodType, MethodHandle, MethodType)CallSite

解释：invokedynamic 指令在第一次执行时调用 Bootstrap 方法（LambdaMetafactory.metafactory()），Bootstrap 方法动态生成一个实现 Runnable 的类，然后返回一个 CallSite 指向它。后续调用直接走 CallSite，不再调用 Bootstrap 方法。

💭 思考：invokedynamic 为什么只在第一次执行时调 Bootstrap？因为生成类是昂贵的（ASM 造字节码），只做一次后绑定到 ConstantCallSite，后续调用直接走 CallSite。这是「延迟绑定 + 结果缓存」的经典套路。

LambdaMetafactory 做了什么

第一次执行 invokedynamic 时，JVM 调 LambdaMetafactory.metafactory()：

1. 用 ASM 在内存中生成一个类（名字类似 Main$$Lambda$1）
2. 这个类 implements Runnable
3. run() 方法体直接调用 System.out.println("hello")
4. 通过 ConstantCallSite 绑定，永久缓存

生成的 Lambda 类大概长这样：

// 自动生成，不出现在任何 .class 文件中
final class Main$$Lambda$1 implements Runnable {
    @Override
    public void run() {
        // 直接包含 Lambda 体的代码
        System.out.println("hello");
    }
}

关键差异到此已经很清楚了：

• 匿名内部类：javac 生成 .class 文件 → 类加载器加载 → 实例化
• Lambda：javac 生成 invokedynamic 指令 → 运行时 LambdaMetafactory 在内存中动态生成类 → 实例化

💭 思考：无捕获 Lambda 为什么能做成单例？因为它不依赖任何外部变量，类的行为固定，生成一个 INSTANCE 静态实例就能服务所有调用点——零对象分配。有捕获的 Lambda 则每次调用都 new，因为捕获的值可能不同。

无捕获 vs 有捕获

无捕获 Lambda

Runnable r = () -> System.out.println("hello");

无捕获的 Lambda 被实例化只一次，缓存为单例：

// LambdaMetafactory 生成的类
final class Main$$Lambda$1 implements Runnable {
    static final Main$$Lambda$1 INSTANCE = new Main$$Lambda$1(); // 单例
    @Override public void run() { ... }
}

每次调用 r = () -> System.out.println("hello") 返回同一个 INSTANCE——零对象分配，零 GC 压力。

有捕获 Lambda

String name = "world";
Runnable r = () -> System.out.println("hello " + name);

有捕获的 Lambda 捕获了一个非 effectively final 的变量（实际上是隐式的构造器参数）。每次调用都会生成新实例（因为捕获的值可能不同），但 class 只生成一次。

为什么 invokedynamic 比匿名内部类好

invokedynamic 的巧妙之处在于延迟绑定：JVM 规范不规定 Bootstrap 方法的行为，JDK 升级时可以换一种更高效的实现策略，而已经编译好的字节码不需要重新编译。

💭 思考：延迟绑定最大的好处是什么？是「策略可升级」——JVM 规范只规定了 Bootstrap 方法这个钩子，没规定实现细节。JDK 升级时可以换更高效的生成策略，而已经编译好的 invokedynamic 字节码一行不用改。这是面向未来的设计。

invokedynamic 的三个关键组件

invokedynamic #7, 0

BootstrapMethods 表:
  #8: REF_invokeStatic LambdaMetafactory.metafactory:
      (MethodHandles$Lookup,  // 调用者的访问上下文
       String,                 // 函数式接口方法名（"run"）
       MethodType,             // 函数式接口方法类型 (()V)
       MethodType,             // Lambda 体方法类型 (()V)
       MethodHandle,           // 指向 Lambda 体的实际实现
       MethodType)             // Lambda 体方法类型（再次确认）

1. CallSite：Bootstrap 方法的返回值，一个”调用的锚点”——每次 invokedynamic 执行时直接走 CallSite.getTarget()，不再查 Bootstrap
2. MethodHandle：指向 Lambda 体实际字节码的”函数指针”，可能是静态方法（无捕获）、实例方法（this::method）、或者是构造器方法引用
3. ConstantCallSite：永不变更的调用点——一旦绑定，永久有效（Lambda 场景用这个；其他场景可能用 MutableCallSite 或 VolatileCallSite）

一个实验验证

编译以下代码：

public class Test {
    public static void main(String[] args) {
        Runnable r1 = new Runnable() {
            public void run() { System.out.println("hi"); }
        };
        Runnable r2 = () -> System.out.println("hi");
        Runnable r3 = () -> System.out.println("hi");
    }
}

javap -c -p -v Test.class，你会看到：

• 匿名内部类 r1：invokespecial Test$1.<init>:()V（指向编译期生成的类）
• Lambda r2：invokedynamic（第一次调用时 Bootstrap）
• Lambda r3：同样是 invokedynamic，但和 r2 走的是同一个 Bootstrap（JMH 实测 r2 == r3 返回 true，因为无捕获 Lambda 是单例）

总结

Lambda 不是匿名内部类的语法糖。它是 JVM 7 引入的 invokedynamic 指令的真正杀手级应用——把”如何实现函数式接口”的决策从编译期推迟到了运行期，让 JDK 可以在不改 class 文件的情况下优化 Lambda 的实现。而匿名内部类是编译期就钉死的”静态”代码生成。

章末提问

追问 1：Lambda 是匿名内部类的语法糖吗？本质区别是什么？

结论先行：不是。匿名内部类在编译期由 javac 生成 .class 文件，Lambda 通过 invokedynamic 在运行期由 LambdaMetafactory 动态生成类。

因为：匿名内部类是静态的代码生成——编译期定死类名 Main$1、invokespecial 直接实例化；Lambda 是延迟绑定——编译期只留一条 invokedynamic 指令，首次执行才调 Bootstrap 用 ASM 在内存生成类并绑到 ConstantCallSite。一个是「编译期钉死」，一个是「运行期动态生成」。

追问 2：无捕获 Lambda 为什么是单例？有捕获 Lambda 为什么不是？

结论先行：无捕获 Lambda 不依赖外部变量、行为固定，LambdaMetafactory 生成一个静态 INSTANCE 复用；有捕获 Lambda 捕获的值可能不同，每次调用生成新实例。

因为：无捕获时 Lambda 体是常量行为，单例复用零对象分配；有捕获时捕获变量实际成了构造器参数，每个调用点的捕获值不同，必须 new 新实例。但无论哪种，class 都只生成一次。

追问 3：invokedynamic 相比「编译期生成类」好在哪？

结论先行：好在延迟绑定和策略可升级——不落盘、无捕获可单例、class 只生成一次、Bootstrap 实现未来可被 JVM 替换。

因为：invokedynamic 让「如何实现函数式接口」的决策推迟到运行期，JVM 规范只规定 Bootstrap 钩子不规定实现，JDK 升级可换更高效策略而老字节码无需重编译；匿名内部类则每个都占一个 class 文件、每次都 new 实例，没有这些优化空间。