反射能破坏大多数单例实现，因其通过setaccessible(true)绕过访问控制调用私有构造器；枚举因jvm严格限制构造器调用而天然免疫。
反射确实能破坏大多数单例实现——只要它依赖私有构造方法 + 静态实例字段的常规保护机制。核心原因在于：setAccessible(true) 绕过了 Java 的访问控制检查，使私有构造器可被任意调用，而单例类自身若未做额外防御，就会被反复实例化。
哪些单例实现容易被反射攻破
除枚举外，主流实现方式（饿汉式、懒汉式、双重检查锁、静态内部类）在默认写法下均不免疫反射攻击：
- 饿汉式：类加载即创建实例，但反射仍可绕过构造器限制，新建对象（需在构造器中加判断才可防御）
- 懒汉式 / DCL：首次调用 getInstance 才初始化，但反射可在 getInstance 调用前就创建多个实例
- 静态内部类：看似安全（利用类加载机制延迟初始化），但反射仍能直接调用外部类私有构造器，与内部类是否加载无关
反射破坏的本质路径
攻击过程固定四步，直击构造环节：
- 通过
Class.getDeclaredConstructor()获取私有构造器对象 - 调用
constructor.setAccessible(true)取消访问限制 - 执行
constructor.newInstance()触发构造逻辑 - 重复调用即得多个独立实例，
==比较返回false
有效防御的关键动作
防御必须落在构造器内部，因为反射创建对象的唯一入口就是调用构造方法：
- 在私有构造器开头加入状态校验，例如用静态布尔标记或直接比对已有实例
- 饿汉式可判断
INSTANCE != null；静态内部类可判断Inner.instance != null - 一旦发现已有实例存在，立即抛出
RuntimeException中断实例化 - 注意：仅靠
volatile或synchronized无法阻止反射，它们只管并发，不管反射调用
为什么枚举是天然免疫的
Java 枚举的构造过程由 JVM 严格控制，Enum 类的构造器被设计为不可被反射调用。即使你尝试获取并设为可访问，constructor.newInstance() 也会抛出 IllegalArgumentException。这是 JVM 层面的硬性保障，无需额外编码防御。
