readresolve可修复反序列化破坏单例问题：它在反序列化末尾将新对象替换为已有静态实例，确保==为true；须实现serializable、方法为private object readresolve()且返回已初始化实例，但无法防御反射攻击。
Java 序列化会绕过构造器直接新建对象，导致反序列化后得到一个新实例，破坏单例的唯一性。解决方法是在单例类中添加 readResolve 方法，在反序列化完成的最后一步，把刚创建的对象替换成已有的静态实例，从而保证 == 判断为 true。
为什么反序列化会破坏单例
ObjectInputStream 在反序列化时不做任何构造逻辑检查：它不调用构造器、不执行静态块、不触发初始化代码，仅靠字节流填充字段值。哪怕你用了静态内部类+私有构造器双重防护，也完全无效——因为根本没走那条路。
典型后果包括：
- 两个对象
==比较返回false -
hashCode()不同，影响集合类行为 - 缓存、连接池等状态字段无法共享，出现行为分裂
- 在 RPC、消息队列或 Redis 缓存场景中极易暴露问题
readResolve 的正确写法和触发条件
这个方法不是可选补丁，而是 JVM 序列化规范定义的固定钩子，必须严格满足以下三点才会被自动调用：
- 所在类必须实现
Serializable接口 - 方法声明必须是
private Object readResolve() throws ObjectStreamException - 返回值必须是已初始化完成的静态单例实例（如
return INSTANCE;或return getInstance();）
修饰符不能是 public、protected 或包级默认——错一个就彻底失效。
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
推荐的安全实现方式
配合静态内部类初始化，确保实例在 readResolve 被调用前已就绪：
public class Singleton implements Serializable {
private static class Holder {
static final Singleton INSTANCE = new Singleton();
}
private Singleton() {
if (Holder.INSTANCE != null) {
throw new RuntimeException("Singleton already initialized");
}
}
public static Singleton getInstance() {
return Holder.INSTANCE;
}
private Object readResolve() {
return getInstance();
}
}
关键点：
-
INSTANCE是static final，由 JVM 类加载机制保障线程安全与提前初始化 - 构造器内加了非空校验，防御反射攻击（
readResolve对反射无效） -
readResolve复用getInstance()入口，避免直接引用可能引发的 NPE
它能防什么，不能防什么
readResolve 是专治反序列化的“最后一道闸”：
- ✅ 防止反序列化产生新实例：无论序列化多少次，反序列化结果始终指向原始内存地址
- ✅ 保持字段语义一致：比如
private List<string> cache = new ArrayList();</string>，只要返回的是原实例，这个cache就是那个已预热、已注册、带定制行为的集合 - ❌ 不防反射攻击：通过
setAccessible(true)调用私有构造器仍可新建对象，需靠构造器内校验兜底 - ❌ 不防多类加载器场景：不同
ClassLoader加载的同一个类，会产生各自独立的INSTANCE
如果单例不需要继承其他类、也不需要实现复杂接口，最稳妥的做法是改用枚举——JVM 规范强制保障其反序列化安全性，无需任何额外代码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
