为什么枚举类能天然防止反射和反序列化破坏单例
因为 Enum 的构造方法被 JVM 强制限定为私有，且每次调用 values() 或通过序号获取实例时，都只是返回已初始化好的静态数组元素；JVM 层面禁止对枚举类进行 newInstance() 反射实例化，ObjectInputStream 在反序列化时也会直接返回缓存的枚举常量，跳过构造逻辑。
常见错误现象：java.lang.NoSuchMethodException: MyEnum.<init>()</init>（反射尝试失败）、反序列化后对象 == 原对象（不是新实例）。
- 不依赖
private static final+volatile+ 双重检查锁那些手工防护 - 不需要重写
readResolve()方法 - 枚举单例天生线程安全，类加载阶段即完成初始化
怎么写一个带参数和方法的枚举单例
枚举常量可以像普通类一样定义字段、构造器、方法，只要注意构造器必须是私有的（编译器强制），且所有常量必须在第一行显式列出。
使用场景：需要单例持有配置、提供统一行为入口，比如日志处理器、配置中心客户端。
立即学习“Java免费学习笔记（深入）”；
public enum ConfigClient {
INSTANCE("prod", 8080);
private final String env;
private final int port;
ConfigClient(String env, int port) {
this.env = env;
this.port = port;
}
public void connect() {
System.out.println("Connecting to " + env + ":" + port);
}
public String getEnv() { return env; }
}
- 枚举名建议用大驼峰，常量名用
INSTANCE（语义明确，避免歧义） - 不要在枚举中暴露
public static工厂方法——会削弱单例语义 - 如果需要延迟初始化某些资源，可在首次调用方法时做判断，但别在构造器里做耗时操作
枚举单例和静态内部类单例比，差在哪
枚举单例无法继承其他类（Java 枚举隐式继承 java.lang.Enum），也不能实现接口以外的扩展；而静态内部类单例支持实现接口、继承抽象类，更灵活。
性能影响几乎可忽略：枚举类加载稍慢（需初始化所有常量），但运行时访问 INSTANCE 是直接静态字段读取，比反射或同步块更快。
- 兼容性没问题，JDK 5+ 全支持
- 不能被 Spring 等框架直接
@Autowired注入（除非用@Bean显式注册） - 单元测试中难 mock（因为是 final 类），若业务强依赖 mock，得权衡是否选用
什么时候不该用枚举实现单例
当单例需要动态创建不同实例（比如根据环境返回不同实现），或者必须被代理（如 Spring AOP）、需要被序列化成 JSON 并还原为同一对象（Jackson 默认把枚举序列化为字符串，反序列化时不会复用原实例，可能破环单例语义）。
- JSON 场景下，
ObjectMapper默认行为会让ConfigClient.INSTANCE序列化成"INSTANCE"字符串，反序列化时返回的是同一个枚举常量——这点其实仍满足单例，但容易误以为“新建了对象” - 若用
@JsonCreator自定义反序列化逻辑，反而可能绕过 JVM 保护，导致意外行为 - Android 上低版本（API
真正复杂的地方不在写法，而在团队对“单例”的理解是否统一：有人把它当全局状态容器，往里面塞可变字段；有人当纯工具入口，只调方法。枚举锁死了实例数量，但锁不住滥用。
