Lambda序列化与反序列化疑问：fn1与fn2反序列化后为同类是JDK/编译器Bug吗？

这绝对不是JDK或编译器的Bug，而是你对Lambda表达式的序列化/反序列化机制存在一点认知盲区——我来给你拆解清楚背后的逻辑：

1. Lambda类的生成逻辑：运行时动态复用 #

Lambda表达式和传统的匿名内部类有着本质区别：

• 匿名内部类是编译期就生成独立的class文件；
• 而Lambda是运行时由LambdaMetafactory动态生成类，而且JVM会对逻辑完全一致的Lambda复用同一个类。

这里的“逻辑一致”指的是：

• 实现的函数式接口类型相同；
• 引用的目标方法（或Lambda体逻辑）完全一致；
• 捕获的变量类型/数量/不可变值一致。

2. 序列化的核心：SerializedLambda #

Lambda序列化的本质不是直接序列化生成的类，而是将Lambda的元数据序列化为SerializedLambda对象，其中包含：

• 实现的接口全类名；
• 目标方法的类名、方法名、方法描述符；
• 捕获的变量信息等关键元数据。

反序列化时，JVM会读取SerializedLambda中的元数据，然后尝试复用已存在的、匹配该元数据的Lambda类——如果之前已经生成过（比如原fn1的类），就直接复用这个类来创建新的Lambda实例，这就导致fn1和反序列化后的fn2属于同一个类。

3. 为什么要这么设计？ #

这是JDK的性能优化策略：
Lambda作为轻量级的函数式实现，大量场景下会出现逻辑重复的情况（比如多个地方用同一个逻辑的Lambda），复用同一个类可以减少类加载的开销，降低内存占用，同时保证Lambda的轻量级特性。

额外提示：如何让Lambda类不复用？ #

如果你确实需要让反序列化后的Lambda属于不同的类，有两种替代方案：

• 使用匿名内部类代替Lambda：匿名内部类是编译期生成的独立类，不同的匿名内部类会对应不同的class；
• 自定义Lambda的序列化逻辑：通过实现writeReplace和readResolve方法，手动控制序列化后的元数据，让JVM生成不同的类。

内容的提问来源于stack exchange，提问作者Can Gencer