根本原因是Java反序列化绕过构造函数直接反射新建对象；readResolve通过在反序列化末尾替换实例来修复，签名必须为private Object readResolve()；枚举单例因JVM规范禁止重建而天然免疫。
单例模式在反序列化时被破坏，根本原因在于：Java 的默认反序列化机制不走构造函数，而是直接通过反射新建对象——哪怕你用 private 构造器 + 静态内部类等方式锁死了“创建路径”，ObjectInputStream 仍会绕过所有逻辑，调用 ObjectStreamClass.newInstance() 创建一个全新的实例。
为什么反序列化能绕过私有构造器？
反序列化不是“调用 getInstance”，而是 JVM 底层重建对象的过程。它会：
- 读取字节流中保存的类信息和字段值
- 跳过构造方法（包括私有构造），直接分配内存并填充字段
- 最终得到一个与原单例对象地址不同的新对象
readResolve 是怎么修复这个问题的？
它不是阻止反序列化，而是在反序列化完成之后“替换结果”。JVM 在反序列化流程末尾自动检查当前类是否定义了符合规范的 readResolve 方法：
- 方法签名必须是
private Object readResolve() - 返回值是你真正想保留的那个单例实例（比如
INSTANCE或getInstance()） - 只要存在且可访问，JVM 就用它的返回值覆盖刚创建出来的临时对象
枚举单例为什么天然免疫？
这不是靠代码逻辑，而是 Java 语言规范强制保障的：
- JVM 明确禁止对枚举常量进行反序列化重建
- 无论字节流里写什么，
Enum.valueOf()永远只返回已有的枚举实例 - 不需要写
readResolve，也没有反射入口（枚举类没有无参构造器）
实际使用中容易踩的坑
看似加个 readResolve 就万事大吉，但这些情况会让它失效：
- 类实现了
Externalizable接口：此时readResolve完全不触发，必须在readExternal中手动返回单例 - 用了非标准序列化库（如 Kryo、Jackson）：默认不识别
readResolve，需显式配置或注册支持 - 字段含
transient或不可序列化类型（如ThreadLocal、Socket）：反序列化后这些字段为null，readResolve不负责恢复它们 - Android 低版本或混淆工具（如 ProGuard）误删该方法：需检查 keep 规则是否保留了
readResolve
