枚举是Java中最简单的线程安全单例，因JVM在类加载时初始化且仅一次，天然避免指令重排、内存可见性问题，无需synchronized/volatile，自带readResolve防止反序列化破坏，反射也无法创建新实例。
为什么枚举是Java里最简单的线程安全单例
因为 JVM 保证枚举类型的实例在类加载阶段就完成初始化，且只初始化一次，天然规避了双重检查锁（DCL）里的指令重排、内存可见性等问题。你不用写 synchronized，也不用管 volatile，更不会遇到反序列化破坏单例的坑——枚举自带 readResolve() 机制。
常见错误现象：手写 DCL 单例时漏加 volatile，导致多线程下可能返回未完全构造的对象；或者忘了把构造函数设为 private，被反射绕过；又或者没处理 readObject，被反序列化造出第二个实例。
- 使用场景：配置管理器、日志上下文、全局资源访问点等需要强唯一性和线程安全的轻量级服务
- 参数差异：枚举单例没有构造参数可传（除非用带参构造+静态字段），不适合依赖外部注入的复杂初始化
- 性能影响：比懒汉式略快（无同步开销），比饿汉式内存占用稍低（类加载即初始化，但不可延迟）
怎么写一个标准的枚举单例
直接定义一个只含一个实例的枚举，暴露方法即可。不需要额外修饰符，JVM 自动封禁反射创建和反序列化绕过。
public enum Singleton {
INSTANCE;
public void doSomething() {
// 业务逻辑
}
}
调用方式就是 Singleton.INSTANCE.doSomething()。注意：INSTANCE 是枚举常量名，不是变量，不能改名或动态生成。
立即学习“Java免费学习笔记（深入）”；
- 别加
public Singleton()构造器——枚举类构造器默认私有，显式声明反而容易误写成 public - 别在枚举里放静态代码块做初始化——类加载顺序不可控，可能早于枚举实例初始化
- 如果真需要初始化逻辑，写在
INSTANCE的构造参数里，或用惰性 holder 模式配合枚举（但通常没必要）
枚举单例被反射或反序列化破坏了吗
没有。这是它比手写单例强的核心点。JVM 对枚举的反序列化做了特殊处理：无论你如何重写 readObject，最终都会返回已存在的枚举实例；反射调用 Constructor.newInstance() 会直接抛 java.lang.EnumException: Cannot reflectively create enum objects。
你可以自己验证：尝试用 AccessibleObject.setAccessible(true) 去调用枚举构造器，一定会失败。而普通类单例做不到这点。
- 错误尝试：用
ObjectInputStream反序列化一个伪造的枚举字节流 → 仍返回Singleton.INSTANCE - 兼容性影响：Java 5+ 全支持，无版本顾虑
- 注意点：枚举类型本身不可被继承，所以无法被子类覆盖行为——这不是缺陷，是设计约束
什么时候不该用枚举实现单例
当单例需要实现接口但该接口方法签名与枚举冲突，或者必须支持运行时动态选择不同实现（比如根据配置切换策略），这时候枚举的“固定实例数”特性就成了硬伤。
还有种情况：你需要延迟初始化（比如初始化代价极高，且应用启动后大概率不使用）。枚举在类加载时就初始化，没法延迟——这时得退回懒汉式 + volatile + DCL，或用 Holder 模式。
- 典型反例：数据库连接池管理器，初始化要连真实 DB，且可能被关闭重启 → 枚举不合适
- 参数差异：枚举无法接受 Spring 等框架的依赖注入（@Autowired 不生效），只能靠静态工具类辅助
- 容易忽略的点：单元测试中 mock 枚举单例非常麻烦，多数 mock 工具（如 Mockito）默认不支持 mock 枚举
