单例模式在反射和序列化下易失效：反射通过setAccessible(true)绕过私有构造器创建新实例，序列化反序列化跳过构造器直接生成对象；需用枚举实现或组合构造器状态检查与readResolve()双重防护。
Java单例模式在反射和序列化双重路径下确实容易失效，不是“写出来就安全”，而是需要针对性设防。核心问题在于：反射能绕过私有构造器，序列化能跳过构造过程直接生成对象——两者都让“唯一实例”失去约束力。
反射如何破坏单例
哪怕构造方法是 private，只要类加载完成，反射就能获取其构造器并设为可访问：
- 调用 getDeclaredConstructor() 获取私有构造器
- 执行 setAccessible(true) 突破访问控制
- 用 newInstance() 直接创建新实例，不走 getInstance() 流程
此时两个对象内存地址不同，== 判断为 false，单例契约彻底失效。
序列化如何破坏单例
Java 默认序列化机制在反序列化时不调用任何构造器，而是直接在堆上分配内存并填充字段值：
立即学习“Java免费学习笔记（深入）”；
- 即使构造器里加了“已存在则抛异常”的防护，反序列化也完全绕过它
- 若单例类实现了 Serializable，且未做额外处理，反序列化就会产生第二个实例
- 尤其在分布式场景（如 Redis 存储、网络传输）中，这个漏洞极易被触发
双重防护的实用方案
单一手段无法同时抵御反射和序列化攻击，必须组合使用：
- 用枚举实现单例：JVM 层面禁止反射实例化枚举常量，且枚举序列化由 JVM 特殊保障，天然防反射+防序列化破坏
-
非枚举方案需手动补漏：
- 构造器中加实例状态检查（如 static boolean flag），首次之后抛 RuntimeException
- 实现 readResolve() 方法，确保反序列化始终返回原实例：return INSTANCE;
为什么静态内部类+readResolve 还不够安全
静态内部类能保证线程安全与延迟加载，但它不防反射——内部类的构造器仍可被反射调用；而 readResolve() 只管序列化路径，对反射无能为力。两者叠加仍是“双缺口”方案，不如枚举一步到位。
