是的，单例实现Serializable后反序列化会破坏单例性；必须添加private Object readResolve()方法返回唯一实例，或改用枚举类型确保天然单例。
单例被反序列化后就不是单例了？这是真的
是的，只要单例类实现了 Serializable，反序列化就会绕过构造方法、静态初始化逻辑，直接从字节流“拼出”一个新对象——哪怕你用了静态内部类或双重检查锁，也拦不住。结果就是：instance1 == instance2 返回 false，日志错乱、配置分裂、连接池复用失效都可能跟着来。
为什么 readResolve() 是必须加的补丁
readResolve() 是 JVM 在反序列化完成、返回对象前的最后拦截点：它不修改字节流，也不重写反序列化逻辑，只是把刚造出来的“假单例”换成你指定的“真单例”。关键在于它只在反序列化路径生效，不影响正常 getInstance() 调用，也不增加运行时开销。
- 方法签名必须严格为：
private Object readResolve() throws ObjectStreamException - 返回值必须是你要保护的那个唯一实例（比如
return INSTANCE;） - 如果单例里有非
transient的对象引用字段，攻击者可能在readResolve()执行前“偷走”引用，导致绕过防护——所以所有对象类型字段建议声明为transient
静态内部类单例 + readResolve() 的最小安全模板
这是目前最轻量又抗反射、抗反序列化的组合。注意两点：构造器防反射、readResolve() 防反序列化，缺一不可。
public class Singleton implements Serializable {
private Singleton() {
if (Holder.INSTANCE != null) {
throw new RuntimeException("Singleton instance already exists");
}
}
<pre class="brush:php;toolbar:false;">private static class Holder {
static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return Holder.INSTANCE;
}
private Object readResolve() {
return getInstance();
}}
- 不用 synchronized，无性能损耗
- 没实现
Serializable就不会触发反序列化风险；一旦加了，就必须配readResolve() - 别手滑删掉
private修饰符——JVM 只认私有readResolve()
比 readResolve() 更省心的替代方案：用枚举
如果你的单例不需要继承或实现复杂接口，直接用枚举。Java 规范保证枚举的序列化/反序列化天然单例，连 readResolve() 都不用写，反射、反序列化、类加载器隔离全免疫。
public void doWork() { /* ... */ }- 枚举的
INSTANCE在 JVM 中全局唯一，且反序列化时自动调用内置readResolve() - 缺点是无法继承其他类（只能实现接口），也不支持延迟初始化以外的复杂构造逻辑
- 很多团队已将“所有轻量级单例优先用 enum”写进代码规范
真正容易被忽略的是：哪怕你写了 readResolve()，只要类里存在非 transient 的可序列化字段，攻击者仍可能构造恶意字节流，在 readResolve() 执行前完成引用劫持——这不是理论风险，已有公开 PoC。所以，要么全字段 transient，要么换枚举，别留中间地带。
