synchronized无法防反射破坏单例，因反射绕过所有同步逻辑直接调用构造器；有效防御必须在私有构造器内校验实例状态，或采用枚举——JVM层面禁止反射与序列化创建新实例。
synchronized 对象锁 不能防止单例被反射破坏。
这是个常见误解。需要明确一点：synchronized 作用于方法或代码块，只控制多线程并发访问的顺序，对反射调用私有构造器完全无效。
反射破坏单例的核心路径是：
- 获取
Constructor对象 - 调用
setAccessible(true)绕过访问控制 - 直接执行
newInstance()创建新实例
这个过程 不经过任何同步逻辑，也不触发 getInstance() 方法，更不涉及你加锁的那个对象或类——它直接在 JVM 层面调用构造器，跳过了所有业务逻辑和同步保护。
立即学习“Java免费学习笔记（深入）”；
所以，无论你用的是：
-
synchronized getInstance()（方法级锁） -
synchronized(Singleton.class)（类锁） - 还是
synchronized(instance)（实例锁）
都 对反射无约束力。
真正有效的防御位置：私有构造器内部
必须在构造器第一行做校验，例如：
private Singleton() {
if (INSTANCE != null) {
throw new RuntimeException("Singleton instance already exists");
}
// 后续初始化逻辑...
}注意：
-
INSTANCE需是静态 final 字段（如饿汉式），或静态内部类中的static final实例 - 若用双重检查锁（DCL），需配合一个
static volatile boolean initialized标志位，在构造器中判断并设为true - 仅靠
volatile、synchronized、final关键字本身，无法拦截反射创建
为什么枚举是终极解法？
public enum Singleton {
INSTANCE;
// 可添加方法、字段，但无法通过反射实例化
}- JVM 禁止反射调用
Enum的构造器，constructor.newInstance()必抛IllegalArgumentException - 序列化也由 JVM 特殊保障，反序列化始终返回原有常量
- 无需手写校验逻辑，天然防反射 + 防序列化
补充：如果坚持用普通类，还需防序列化
反射只是其中一环。若类实现 Serializable，反序列化也会绕过构造器，产生第二个实例。此时要加：
private Object readResolve() {
return INSTANCE; // 强制返回唯一实例
}但这依然 不解决反射问题，必须和构造器校验组合使用。
不复杂但容易忽略：防御不在“怎么拿实例”，而在“谁允许你造实例”。
