静态内部类单例利用JVM类加载机制实现线程安全与延迟加载，首次调用getInstance时触发SingletonHolder初始化，由JVM自动加锁确保仅一个线程执行<clinit>()，实现无同步、高性能的单例。
关键在于利用类加载的准备阶段完成静态字段的内存分配与默认值设定，配合初始化阶段的原子性保障，跳过运行时判空、锁竞争等开销。真正轻量的单例不靠“懒”，而靠“准”——在 JVM 保证安全的前提下，把实例固化在类结构里。
准备阶段只分配空间、不执行逻辑
类加载的准备阶段，JVM 仅为 static 字段分配内存并设为默认值（如引用类型为 null、int 为 0）。此时 INSTANCE 还未构造，也不执行任何代码。这意味着：如果你依赖准备阶段做“预留”，就不能指望它已有对象；但正因它不执行逻辑，也就没有竞态、无同步开销，是天然轻量的起点。
- 声明 private static final Singleton INSTANCE 时，JVM 在准备阶段就为其分配了固定内存槽位
- final 修饰确保该字段地址不可变，后续读取直接命中，无 volatile 读屏障开销
- 若搭配简单构造（无 I/O、无外部依赖），整个初始化可在类加载的初始化阶段（
）内一次性完成，由 JVM 自动加锁保障原子性
用静态常量代替静态块，省掉一次方法调用入口
静态块（static {}）虽能封装复杂逻辑，但本质仍是
- 写法：private static final Singleton INSTANCE = new Singleton(); —— 编译后直接嵌入
，无额外字节码跳转 - 对比 static {} 块：多一条 goto 或 aload 指令，对高频调用的 getInstance() 虽微小，但破坏了“零成本抽象”的边界
- 适用于：无参数构造、无异常抛出、不依赖系统属性或配置文件的场景（如工具类、状态容器）
避免一切运行时判断与同步原语
轻量的核心是“不做多余的事”。饿汉式看似提前创建，实则是把不确定性（是否需要、何时需要）转移到确定性（类加载即完成）上，换来的是 getInstance() 方法体可精简为单条 return 指令。
- getInstance() 可写成：return INSTANCE; —— JIT 极易内联，无分支预测失败风险
- 不使用 if (instance == null) 判空，消除条件跳转；不加 synchronized 或 volatile，绕过内存屏障与锁膨胀路径
- final + 饥饿初始化 + 私有构造，三者叠加即构成 JVM 层面的线程安全契约，无需人工干预
慎用延迟加载，除非初始化代价真实可观
所谓“懒”，本质是用运行时分支+锁/双重检查换内存延迟。但现代 JVM 类加载极快，且多数单例对象本身极小（如仅持几个 int 或 String）。若初始化耗时主要来自反射、配置解析或网络请求，那应重构这些依赖，而非用懒汉式掩盖设计缺陷。
- 测量真实开销：用 JMH 对比饿汉式 vs 双重检查锁的 getInstance() 吞吐量，常会发现前者高出 2–5 倍
- 若真需延迟，优先考虑静态内部类（利用其初始化惰性），而非 synchronized 方法——它更轻、更符合 JVM 语义
- 枚举单例虽绝对安全，但增加了 Class 对象体积与序列化开销，对“极其轻量”目标并非最优
