枚举类天生线程安全，因JVM在类初始化阶段由ClassLoader加锁完成静态实例构造，保证单次、原子、不可重入；其单例无需同步关键字、防反射攻击且序列化安全，但不支持动态参数与生命周期管理。
为什么枚举类天生线程安全
因为 JVM 保证 Enum 类型的静态实例在类初始化阶段就完成构造，且该过程由 ClassLoader 加锁控制，外部无法触发多次初始化。你写 MySingleton.INSTANCE，背后是 JVM 级别的单次、原子、不可重入的类加载流程。
常见错误现象：有人试图在枚举里加懒汉式逻辑（比如延迟初始化内部字段），结果发现 INSTANCE 拿到时，那个字段还是 null —— 这不是并发问题，是误以为枚举能“懒”；枚举实例本身不懒，它一加载就全建好。
- 枚举单例不需要
synchronized、volatile或双重检查锁 - 不能被反射攻击（
AccessibleObject.setAccessible(true)对Enum构造器无效） - 序列化安全：JVM 强制反序列化时返回原
INSTANCE，不会新建对象
怎么写一个真正可用的枚举单例
别套模板，直接按需求塞逻辑。重点在「构造阶段做完所有初始化」，而不是把业务逻辑拖到方法里。
使用场景：配置加载、连接池管理、全局状态协调器等需要强单例语义的组件。
立即学习“Java免费学习笔记（深入）”；
示例：
public enum ConfigLoader {
INSTANCE;
private final Map<String, String> config;
ConfigLoader() {
// 所有初始化必须放在这里，且只能执行一次
this.config = loadFromDisk(); // 可能抛异常，但只抛一次
}
public String get(String key) {
return config.get(key);
}
private Map<String, String> loadFromDisk() {
// 实际加载逻辑
return Map.of("timeout", "3000");
}
}
- 构造器必须是 package-private 或默认（不能写
public，JVM 不允许） - 如果
loadFromDisk()可能失败，异常会卡在类初始化阶段，后续任何访问INSTANCE都抛NoClassDefFoundError，不是Exception - 不要在
get()里做耗时或可失败操作——那已经不是单例模式该管的事了
和普通单例比，差在哪
不是“更好”，而是“更少出错”。普通单例（如双重检查锁）容易踩坑，枚举则把坑全封死了。
参数差异：普通单例要自己管 volatile 字段、同步块粒度、反射防御；枚举单例没这些参数可调——它压根没给你留缝。
性能影响：枚举单例初始化略慢（类加载阶段全量构造），但运行时零同步开销；普通单例首次获取稍慢（可能要进锁），之后快，但风险自担。
- 兼容性无问题：Java 5+ 全支持，Android 也 OK（API 19+）
- 不能继承、不能实现接口以外的抽象（但可以实现接口）
- IDE 调试时能看到
INSTANCE是个真实对象，不是代理或占位符
哪些情况别硬套枚举单例
当你的“单例”需要动态参数、依赖注入、或者生命周期需要显式销毁时，枚举就不是解法了。
常见错误现象：往枚举里塞 setXXX() 方法，然后在 Spring 中用 @Autowired 注入 —— Spring 不会覆盖 INSTANCE，只会报错或静默失败。
- 需要构造参数（比如
new DatabaseClient(url)）→ 枚举做不到 - 需要和框架生命周期绑定（如
@PostConstruct/@PreDestroy）→ 枚举没有回调钩子 - 单元测试要 mock 单例行为 → 枚举难替换，得改代码或用 PowerMock（不推荐）
复杂点在于：它太“死”了。安全是靠牺牲灵活性换来的，不是银弹。真要传参或解耦，老实用工厂 + 容器管理。
