能，但需在私有构造器中校验静态实例是否已存在并抛出异常；枚举单例因JVM硬约束天然防反射，而setAccessible的安全限制不可依赖。
反射能绕过私有构造方法限制，直接创建新实例，从而破坏单例——这不是理论风险，而是真实可复现的行为。防御的关键不在于“阻止反射”，而在于让反射调用在逻辑层就失败。
反射调用 setAccessible(true) 后仍能创建多个实例的原因
Java 的 setAccessible(true) 会跳过 JVM 对 private 构造器的访问检查，但不会干涉构造器内部逻辑。只要构造器没做校验，反射就能成功执行两次甚至更多次。
- 饿汉式、静态内部类、双重检查锁等常见写法，其构造器默认是空的，无状态校验
-
Constructor.newInstance()不关心“是否已有实例”，只负责执行构造逻辑 - 即使类被
final修饰或构造器加了synchronized，也不影响反射创建新对象
在 private 构造器中加入实例存在性校验
这是最直接、最低侵入的防御方式：把“唯一性”从类加载/调用时机，前移到对象实际构建的那一刻。
Web Accessibility (WCAG 2 AA))
下载
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
- 校验必须读取已存在的静态实例引用（如
INSTANCE或LazyHolder.INSTANCE），不能依赖局部标志位（易被反射绕过） - 抛出
RuntimeException是合理选择，因为反射创建本就是非法行为，不应提供恢复路径 - 注意：校验代码需放在构造器最开头，避免因字段初始化顺序导致误判
示例：
private Singleton() {
if (INSTANCE != null) {
throw new RuntimeException("Singleton instance already exists");
}
}
为什么枚举单例天然防反射攻击
Java 规范保证枚举类型的实例在类加载时由 JVM 一次性创建且不可复制，Constructor.newInstance() 对枚举类直接抛出 java.lang.NoSuchMethodException。
- 反射无法获取枚举类的公共/私有构造器（
getDeclaredConstructors()返回空数组） - 即使强行调用
Enum.class.getDeclaredConstructor(String.class, int.class)，JVM 也会在newInstance()阶段拒绝 - 该机制不依赖代码逻辑，是 JVM 层硬约束，比手动校验更可靠
写法：
public enum Singleton {
INSTANCE;
public void doSomething() { ... }
}
setAccessible 的安全边界正在收紧，但不能依赖它
JDK 9+ 模块系统默认禁止跨模块调用 setAccessible(true)，JDK 17+ 更进一步限制对关键类（如 java.base 中类）的反射访问。但这只是运行时防护，不是设计契约。
- 你的单例类若在未命名模块或开放模块中，
setAccessible仍可生效 - SecurityManager 已被弃用（JDK 17+），不再作为主流防护手段
- 真正可靠的防御必须内建于单例自身逻辑，而非寄望于环境限制
最容易被忽略的一点：校验逻辑必须严格对比静态引用本身，而不是某个布尔标记——后者可能被反射修改，前者由 JVM 保障不可变语义。
