回答

问题的历史： Java 在 JDK 1.1 中通过 ObjectOutputStream 和 ObjectInputStream API 引入了本地二进制序列化，建立了一个将对象图扁平化为字节流以进行持久化或网络传输的协议。规范要求在重建过程中，ObjectInputStream 使用 sun.misc.Unsafe 或直接反射为目标对象分配内存，完全绕过构造函数。这个设计选择与单例模式依赖私有构造函数以限制实例化的原则根本相抵触。

问题： 当一个类实现 Serializable 时，反序列化框架通过调用 allocateInstance 创建一个新实例，而不执行任何构造函数逻辑。对于一个通过私有构造函数和静态工厂来强制单一存在的单例，这种干扰在堆中制造了第二个不同的对象，打破了身份平等的保证。因此，旨在全局共享的静态状态变得分散在多个实例之间，导致依赖单一控制点的应用程序行为不一致。

解决方案： readResolve 方法作为定义在 Serializable 合同中的反序列化后钩子，允许该类在返回给调用者之前用规范实例替换反序列化对象。通过声明一个具有确切签名的 protected Object readResolve() throws ObjectStreamException 方法，开发人员可以拦截新创建的重复对象，并返回静态的 INSTANCE 字段。此替换过程在流解析过程中无缝进行，实际上丢弃了多余的对象，交由垃圾回收，同时保持了单例的完整性。

public class Configuration implements Serializable {
    private static final Configuration INSTANCE = new Configuration();
    private String dbUrl;

    private Configuration() {
        this.dbUrl = System.getenv("DB_URL");
    }

    public static Configuration getInstance() {
        return INSTANCE;
    }

    protected Object readResolve() {
        return INSTANCE;
    }
}

生活中的情况

考虑一个分布式微服务架构，其中 DatabaseConfig 单例管理连接池参数和凭据。该服务将此配置序列化为分布式缓存，例如 Redis，以加速部署后的冷启动。在水平扩展事件中，新的服务实例检索并反序列化这个二进制组块，无意中触发了默认反序列化协议。

如果没有防御措施，ObjectInputStream 实例化一个与 JVM 中静态 INSTANCE 不同的 DatabaseConfig 对象。这个重复创建了一个分裂脑的场景，新的实例缺乏静态构造期间执行的初始化钩子，可能指向过时的数据库端点或未初始化的凭据提供者。随后，应用程序因连接池的重复生成而遭受资源泄漏，消耗数据库连接限制，并在集群中造成级联故障。

一种方法是将单例转换为 Enum 类型，利用 JVM 的保证，即枚举在规范中是单例且在设计上抵抗序列化。优点：序列化机制通过名称查找自动处理枚举常量，完全防止实例创建。缺点：枚举不能扩展抽象类，限制了架构灵活性，而且它们缺乏延迟初始化语义，可能在类初始化期间过早加载重配置。

另外，在现有类中实现 readResolve 方法允许其在反序列化完成后返回规范 INSTANCE。优点：这保留了继承层次并支持复杂的初始化逻辑，同时明确防止重复创建。缺点：开发人员常常忽视此方法，如果单例实例本身是延迟初始化且静态初始化期间尚未保证线程安全，则需要谨慎同步。

第三种选择是切换到 Externalizable，通过 writeExternal 和 readExternal 手动控制序列化流，仅写入配置标识符而不是完整状态。优点：这通过拒绝序列化对象内部来防止实例创建攻击，而是在 readExternal 期间从安全存储中获取配置。缺点：这引入了大量样板代码，并需要维护跨应用程序版本的流格式的向后兼容性，增加了维护负担。

工程团队选择解决方案 2，实施 readResolve 返回静态 INSTANCE，因为 DatabaseConfig 需要扩展一个抽象的 BaseConfiguration 类以共享审计日志功能，导致枚举不适用。他们将此与急切初始化相结合，以避免在反序列化期间的同步问题，确保单例在任何反序列化发生之前就存在。这种方法在最小代码干预与对抗重复实例漏洞的强大保护之间取得了平衡。

实施后，负载测试确认反序列化缓存配置返回相同的对象引用，消除了重复的连接池。服务在没有数据库连接耗尽的情况下横向扩展，内存分析确认在垃圾回收周期后没有额外的 DatabaseConfig 实例存在于堆中。这一解决方案保持了架构的可扩展性，同时增强了单例合同对序列化攻击的抵抗力。

候选人常常忽视的内容

readObject 和 readResolve 之间的交互如何影响反序列化单例中的瞬态字段状态？

readObject 从流中重建完整状态，包括在 JVM 认为对象完成之前对瞬态字段的执行自定义初始化逻辑。然后执行 readResolve，如果它返回一个不同的规范实例，JVM 将丢弃完全重建的临时对象，包括在 readObject 期间计算的任何瞬态值。如果需要这些短暂数据，开发人员必须在 readResolve 中手动复制瞬态状态到规范实例中，但对于真正的单例，瞬态字段通常应该从规范状态重新推导，而不是来自序列化流。

为什么实现 Externalizable 会规避 readResolve 提供的保护？

Externalizable 接口通过 writeExternal 和 readExternal 完全将序列化控制转移到类中，绕过了标准 ObjectInputStream 的 defaultReadObject 机制，该机制检查 readResolve。当 readExternal 填充一个新构造的实例时，流将其视为最终对象，并直接返回，而不调用 readResolve，除非开发人员在 readExternal 中显式调用它。这种架构差异意味着使用 Externalizable 的开发人员必须在 readExternal 中手动实现实例控制逻辑，通常通过抛出 InvalidObjectException 或显式合并状态到单例中，而不是依赖于自动替换钩子。

什么阻止 readResolve 在 Java Record 类型中正确工作？

记录通过其规范构造函数和组件访问器方法进行序列化和反序列化，而不是传统类使用的基于反射的字段填充，这意味着反序列化过程从未创建一个空的外壳对象，readResolve 可以替换。JVM 通过使用反序列化的组件值调用规范构造函数来重建记录，导致 readResolve 不适用，因为实例在创建时是完全构造和不可变的。为了与记录实现类似单例的行为，开发人员必须使用标记为 @Serial 的静态工厂方法来实现自定义序列化代理，或者在严格的实例控制必要时放弃记录，转向标准类。

在 Java 的本地序列化协议中，哪种机制允许攻击者实例化多个声称是单例的实例，而哪个防御钩子方法在反序列化时保证实例控制？

回答

生活中的情况

候选人常常忽视的内容