枚举单例天然防反射和反序列化攻击，因JVM强制枚举构造器私有且不可继承，反射调用失败；反序列化时直接查表返回实例。DCL需volatile防止重排序导致字段未初始化。
为什么枚举单例能天然防反射和反序列化攻击
因为 Enum 的构造方法被 JVM 强制限定为私有且不可继承，newInstance() 和 setAccessible(true) 对枚举类的构造器完全无效；反序列化时，JVM 会跳过正常构造流程，直接调用 Enum.valueOf() 查表返回已有实例。
常见错误现象：用反射强行调用枚举构造器抛出 java.lang.NoSuchMethodException 或 java.lang.IllegalArgumentException: Cannot reflectively create enum objects —— 这不是 bug，是 JVM 的硬性保护。
- 适用场景：需要绝对保证单例唯一性，尤其在含反序列化入口（如 RPC、HTTP JSON body 绑定）或动态加载环境（如 OSGi、插件系统）中
- 不支持延迟初始化：枚举实例在类加载时即创建，若初始化开销大且使用率低，可能浪费资源
- 无法传参构造：枚举常量不能带运行时参数，所有配置需通过静态块、外部配置或构建后 setter 注入
双重检查锁定（DCL）里 volatile 为什么不能省
缺少 volatile 修饰 instance 字段，会导致指令重排序：JVM 可能将对象内存分配和构造函数执行拆开，线程 A 看到非 null 的 instance 指针，但其字段仍为默认值（如 null 或 0），引发 NullPointerException 或逻辑错乱。
典型错误写法：private static Singleton instance; —— 看似“省事”，实则在 JDK 1.5+ 之前几乎必现问题，之后因内存模型修正仍不保险。
立即学习“Java免费学习笔记（深入）”；
- 必须搭配
synchronized块和两次判空，三者缺一不可 -
volatile仅作用于引用本身，不保证构造函数内对象图的可见性（如内部HashMap的初始化仍需同步） - 在高竞争场景下，
synchronized块可能成为瓶颈；但对绝大多数业务单例，性能差异可忽略
枚举 vs DCL：什么时候该选哪个
不是“哪个更好”，而是“哪个更贴合当前约束”。枚举不是银弹，DCL 也未必过时。
- 选枚举：要防反射/反序列化、类加载时机可接受、无运行时构造参数、不依赖 Spring 等框架的生命周期管理
- 选 DCL：需延迟初始化、构造过程依赖
ApplicationContext或Properties、要兼容老版本 Android（ - 注意兼容性陷阱：Android 4.x 中
Enum.valueOf()在混淆后可能失败，需保留枚举类名；而 DCL 在 Dalvik 上因内存模型宽松，volatile仍是刚需
Spring 中的单例和手写单例根本不是一回事
Spring 的 @Scope("singleton") 是容器级单例，只保证同一个 ApplicationContext 内返回同一 Bean 实例；它不阻止你 new 出新对象，也不干预反射或反序列化——这和语言层的线程安全单例是不同维度的问题。
常见误用：在 Spring 管理的 Bean 里又手写 DCL 单例，结果既没获得 Spring 的依赖注入优势，又徒增并发风险。
- 如果 Bean 已由 Spring 托管，直接用
@Autowired注入即可，无需自己保证单例语义 - 若必须手写（如工具类、跨容器共享对象），就彻底脱离 Spring 生命周期，别混用
@PostConstruct和 DCL 初始化逻辑 - 枚举单例在 Spring 中可用，但无法被 AOP 代理（因为没有无参构造器），
@Transactional等注解会静默失效
