lambda表达式更节省元空间——编译不生成.class文件，运行时复用已有方法元数据；匿名内部类每次new都生成独立.class并加载入元空间，易引发metaspace oom。
Lambda 表达式比匿名内部类更节省永久代（PermGen）内存，核心原因在于它不生成独立的 .class 字节码文件，也不触发类加载器对新类的加载与注册。在 JDK 8 及以后，永久代已被元空间（Metaspace）取代，但“节省元空间”这一说法本质延续了过去对永久代的关注逻辑——真正节省的是 JVM 的类型元数据内存。
Lambda 不写入元空间，匿名内部类必须写入
匿名内部类在编译时会生成形如 Outer$1.class 的独立字节码文件。JVM 加载该类时，需将类的结构信息（常量池、字段、方法签名、注解等）完整解析并存入元空间。即使逻辑完全相同，每次 new Runnable() { ... } 都可能（尤其在动态生成场景下）导致重复加载或新增类元数据条目，持续占用元空间。
Lambda 表达式默认通过 invokedynamic 指令实现：
- 编译期不生成
.class文件； - 运行期由 JVM 动态链接到已有方法（通常是静态桥接方法），复用已加载类的元数据；
- 元空间中仅维护少量
CallSite和方法句柄引用，不新增类定义。
方法引用进一步压缩元数据开销
比如 System.out::println 或 this::handle，直接绑定到已存在方法的符号引用，连桥接方法都可省略。JIT 编译器还能将其内联为原方法调用，彻底绕过对象分发与元数据查找。
实际影响不止于“不占空间”
元空间容量有限（默认受 -XX:MaxMetaspaceSize 限制）。高频使用匿名内部类（如在循环中反复创建监听器、Stream 中大量 new Function()）会导致：
- 类加载器频繁注册新类，元空间快速膨胀；
- 触发元空间 GC，甚至
java.lang.OutOfMemoryError: Metaspace； - 类加载本身带来延迟，影响启动与响应时间。
而标准 Lambda（非捕获型）几乎零元空间增量，且首次调用后 CallSite 缓存复用，后续调用无解析负担。
注意边界：什么情况 Lambda 也会“变重”？
以下情形会让 Lambda 退化为类似匿名类的行为，间接增加元空间压力：
- 目标接口是 Java 7 之前定义、未标注
@FunctionalInterface的旧接口； - 捕获非常规变量（如非 effectively final 的局部变量），迫使 JVM 生成定制适配器类；
- 在
Unsafe.defineAnonymousClass等底层机制参与的框架中被强制生成匿名类。
只要保持变量 effectively final、面向标准函数式接口（如 Runnable, Consumer, Function），Lambda 就能稳定避开元空间污染。
