单例模式的核心目标是保证一个类在全局范围内只有一个实例，并且提供全局访问点。但在Java的反射机制下，通过setAccessible方法可以修改私有成员的访问权限，这就给单例模式的唯一性带来了挑战。
反射破坏单例的原理
Java的反射机制允许程序在运行时获取类的内部信息，并且可以操作类的属性和方法。setAccessible是AccessibleObject类的方法，它的作用是取消Java语言访问权限检查，当把该方法的参数设为true时，即使是private修饰的构造方法、属性、方法，也可以被外部直接访问。
我们先来看一个普通的饿汉式单例实现：
// 饿汉式单例
public class HungrySingleton {
// 私有静态实例，类加载时初始化
private static final HungrySingleton INSTANCE = new HungrySingleton();
// 私有构造方法，防止外部new
private HungrySingleton() {}
// 全局访问点
public static HungrySingleton getInstance() {
return INSTANCE;
}
}
正常情况下，我们只能通过getInstance方法获取实例，多次调用得到的是同一个对象。但使用反射可以绕过私有构造方法的限制：
import java.lang.reflect.Constructor;
public class ReflectionBreakTest {
public static void main(String[] args) throws Exception {
// 正常获取单例实例
HungrySingleton normalInstance = HungrySingleton.getInstance();
System.out.println("正常实例哈希值：" + normalInstance.hashCode());
// 获取HungrySingleton的Class对象
Class<HungrySingleton> clazz = HungrySingleton.class;
// 获取私有构造方法
Constructor<HungrySingleton> constructor = clazz.getDeclaredConstructor();
// 设置构造方法可访问，取消权限检查
constructor.setAccessible(true);
// 通过反射创建新实例
HungrySingleton reflectInstance = constructor.newInstance();
System.out.println("反射创建实例哈希值：" + reflectInstance.hashCode());
// 判断两个实例是否相同
System.out.println("两个实例是否相同：" + (normalInstance == reflectInstance));
}
}
运行上述代码后，会发现两个实例的哈希值不同，且比较结果为false，说明单例已经被成功破坏，此时系统中存在两个HungrySingleton的实例。
防御反射破坏单例的方案
方案一：构造方法中添加实例校验
我们可以在单例的私有构造方法中添加判断，如果实例已经存在，再尝试创建就直接抛出异常，阻止新实例的生成。
public class SafeHungrySingleton {
private static final SafeHungrySingleton INSTANCE = new SafeHungrySingleton();
private SafeHungrySingleton() {
// 构造方法中校验实例是否已存在
if (INSTANCE != null) {
throw new RuntimeException("单例模式不允许创建多个实例");
}
}
public static SafeHungrySingleton getInstance() {
return INSTANCE;
}
}
此时再运行之前的反射测试代码，调用constructor.newInstance()时就会触发RuntimeException，阻止新实例的创建。但这种方案有一个缺陷，如果反射调用构造方法发生在getInstance之前，也就是INSTANCE还没初始化的时候，校验就会失效，因为此时INSTANCE还是null。
方案二：使用枚举实现单例
枚举是Java 1.5之后引入的类型，枚举的构造方法是私有的，并且枚举实例的创建由JVM保证，反射也无法破坏枚举的单例特性。因为反射在创建枚举实例时，会专门检查该类是否是枚举类型，如果是则不允许通过反射创建实例。
// 枚举单例
public enum EnumSingleton {
INSTANCE;
// 枚举中的自定义方法
public void doSomething() {
System.out.println("枚举单例执行方法");
}
}
测试枚举单例的反射破坏：
import java.lang.reflect.Constructor;
public class EnumSingletonTest {
public static void main(String[] args) throws Exception {
EnumSingleton instance1 = EnumSingleton.INSTANCE;
EnumSingleton instance2 = EnumSingleton.INSTANCE;
System.out.println("两个正常实例是否相同：" + (instance1 == instance2));
// 尝试通过反射破坏枚举单例
Class<EnumSingleton> clazz = EnumSingleton.class;
Constructor<EnumSingleton> constructor = clazz.getDeclaredConstructor(String.class, int.class);
constructor.setAccessible(true);
try {
EnumSingleton instance3 = constructor.newInstance("INSTANCE", 0);
System.out.println("反射创建实例成功");
} catch (Exception e) {
System.out.println("反射创建实例失败，异常信息：" + e.getMessage());
}
}
}
运行后会发现反射创建实例时抛出异常，提示不能通过反射创建枚举对象，这是JVM层面的限制，因此枚举单例是目前最安全的单例实现方式之一。
方案三：使用静态内部类实现单例并添加校验
静态内部类实现的单例利用了类加载的特性，静态内部类只有在被调用时才会加载，同时可以添加构造方法校验，避免反射破坏。
public class InnerClassSingleton {
private static class SingletonHolder {
private static final InnerClassSingleton INSTANCE = new InnerClassSingleton();
}
private InnerClassSingleton() {
// 校验实例是否存在，防止反射破坏
if (SingletonHolder.INSTANCE != null) {
throw new RuntimeException("单例模式不允许创建多个实例");
}
}
public static InnerClassSingleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
这种方式的单例创建是在静态内部类加载时完成的，JVM会保证类加载的线程安全，同时构造方法中的校验也能阻止大部分反射破坏的情况，不过同样存在反射调用早于getInstance调用的极端场景下的风险。
不同防御方案对比
| 方案 | 优点 | 缺点 |
|---|---|---|
| 构造方法校验 | 实现简单，兼容性好 | 无法防御反射调用早于getInstance的场景 |
| 枚举实现 | JVM层面保证单例，反射无法破坏，实现简洁 | 不支持延迟加载，枚举的一些特性可能不符合部分开发者的使用习惯 |
| 静态内部类加校验 | 支持延迟加载，线程安全 | 极端场景下仍可能被反射破坏 |
在实际开发中，如果没有特殊需求，优先推荐使用枚举实现单例，能最大程度避免反射带来的单例破坏问题。如果必须支持延迟加载，可以选择静态内部类方案并添加构造方法校验，提升安全性。
ReflectionsetAccessible单例模式防御性安全机制修改时间：2026-07-22 11:21:39