static字段+私有构造非万能单例，因类初始化即创建实例，不适用于依赖外部资源或需延迟加载的场景；dcl必须用volatile防半初始化；枚举单例线程安全但无懒加载；spring singleton是容器级而非jvm级。
为什么 static 字段 + 私有构造不是万能的单例
直接在类里声明 public static final MySingleton INSTANCE = new MySingleton(); 看似简洁，但会触发类初始化时就创建实例——哪怕程序压根没用到它。这对依赖外部资源（比如数据库连接、配置加载）的单例很危险：启动失败、初始化耗时、或引发 NoClassDefFoundError。
- 适用场景：无状态、无依赖、构造极轻量的工具类（如
MathUtils） - 不适用场景：需要延迟加载、依赖 Spring 容器、或需处理多线程首次访问竞争
- JVM 层面：类加载阶段就会执行
static初始化块，不可控
双重检查锁（DCL）必须加 volatile 吗
必须。不加 volatile 的 instance 字段，会导致其他线程看到一个“半初始化”的对象——构造函数还没执行完，引用就已经被写入主内存，引发 NullPointerException 或字段为默认值（如 0、null）。
-
volatile保证可见性 + 禁止指令重排序，是 DCL 正确性的底线 - Java 5+ 才真正支持
volatile的这一语义；旧版本即使加了也无效 - 示例关键片段：
private static volatile MySingleton instance;
枚举单例真的安全且够用吗
是目前最简洁、天然防反射/反序列化攻击、线程安全的实现方式，但代价是丧失了懒加载能力——枚举类在首次被主动使用（如访问 MySingleton.INSTANCE）时即完成初始化，且无法传参构造。
- 适合：状态固定、无构造参数、不依赖外部上下文的单例（如策略枚举、状态码定义）
- 不适合：需要 Spring 注入依赖、需读取运行时配置、或构造过程含 I/O 的场景
- 反序列化安全：JVM 保证枚举实例全局唯一，
readObject直接返回已有实例
Spring 中的 @Scope("singleton") 和手写单例冲突吗
不冲突，但概念不同。Spring 的 singleton 是容器级单例（IoC 容器中一个 Bean 对应一个实例），不是 JVM 进程级单例；你仍可手写饿汉式单例，但它不会被 Spring 管理，也无法享受 AOP、依赖注入等特性。
立即学习“Java免费学习笔记（深入）”；
- 推荐做法：交给 Spring 管理，用
@Component+@Scope("singleton")（默认就是 singleton） - 手写单例若需 Spring Bean 依赖，只能通过
ApplicationContext.getBean()主动获取，破坏松耦合 - 注意：两个不同类加载器下，Spring 单例也会出现多个实例（如 Web 应用中父子 ClassLoader 场景）
真正麻烦的从来不是写法本身，而是搞不清「谁在控制生命周期」——是 JVM 类加载器、Spring 容器，还是你自己写的静态字段。选错一层，后面所有线程安全、序列化、测试 Mock 的问题都会跟着来。
