静态内部类实现单例是线程安全且懒加载的主流方案，依赖JVM类加载机制保证初始化唯一性与原子性，无需synchronized和volatile，代码简洁可靠。
用静态内部类实现单例，是兼顾线程安全、懒加载和代码简洁性的主流做法。它不依赖同步锁，也不需要 volatile，靠的是 JVM 类加载机制的天然保障。
为什么静态内部类能线程安全又延迟加载
Java 规定：静态内部类在首次被主动使用时才触发初始化，而类初始化过程由 JVM 保证绝对线程安全，且仅执行一次。把单例实例声明在静态内部类里，就等于把“创建时机”卡在了第一次调用 getInstance() 的那一刻——既没提前占资源，又不会多创建。
标准写法与关键细节
核心结构固定，三处不可省略：
- 私有无参构造方法：防止外部 new 实例
- 静态内部类 SingletonHolder：必须 static，且只含一个 public static final 实例字段
- getInstance() 直接返回内部类字段：不加判断、不加锁、不 new
示例代码：
立即学习“Java免费学习笔记（深入）”；
public class ConfigService {private ConfigService() {}
private static class SingletonHolder {
private static final ConfigService INSTANCE = new ConfigService();
}
public static ConfigService getInstance() {
return SingletonHolder.INSTANCE;
}
}
它比双重检查锁（DCL）更推荐的原因
双重检查锁虽也支持懒加载，但需显式加 synchronized 块 + volatile 修饰，稍有疏忽（比如漏掉 volatile）就会因指令重排序导致问题；而静态内部类写法天然规避这些风险：
- 无需手动处理内存可见性或锁竞争
- 类加载阶段的初始化本身就是原子操作
- 字节码更干净，JVM 优化友好，运行时开销为零
适用场景与注意事项
适合绝大多数需要懒加载+线程安全的业务单例，比如配置管理器、轻量工具类、非核心但需全局唯一的组件。
注意两点：
- 不能用于需要传参初始化的场景（构造函数带参数），因为内部类字段只能调用无参构造
- 如果单例初始化过程抛异常，类加载失败会导致后续所有 getInstance() 调用抛 NoClassDefFoundError，建议在构造中做好容错
