静态内部类单例通过JVM类加载机制实现延迟加载与线程安全：仅首次调用getInstance()访问SingletonHolder.INSTANCE时触发内部类初始化，由JVM保证初始化原子性、一次性及内存可见性，无需同步或volatile。
静态内部类在单例模式中实现延迟加载，核心在于利用 Java 类加载机制的特性：外部类加载时，静态内部类不会被立即加载；只有首次主动使用该内部类时，JVM 才会初始化它，并执行其静态成员（包括静态字段和静态代码块）。这个时机恰好对应“第一次调用 getInstance() 方法”，从而实现天然的延迟加载、线程安全且无需同步。
静态内部类如何触发延迟初始化
静态内部类本身是 static 的，不持有外部类实例引用，也不依赖外部类对象。它的加载时机完全独立于外部类的实例化，只取决于是否被“主动使用”。而调用其静态字段（如 INSTANCE）就属于主动使用，会触发该类的初始化。
- 外部类（如
Singleton）加载时，SingletonHolder静态内部类尚未加载，更不会初始化 - 首次调用
Singleton.getInstance()时，方法体内访问SingletonHolder.INSTANCE - JVM 发现
SingletonHolder尚未初始化，于是加载、链接并初始化该类 -
SingletonHolder.INSTANCE = new Singleton()执行，单例对象在此刻创建
标准写法与关键细节
典型实现如下，注意命名习惯和访问控制：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
public class Singleton {
private Singleton() {} // 私有构造防止外部实例化
private static class SingletonHolder {
private static final Singleton INSTANCE = new Singleton();
}
public static Singleton getInstance() {
return SingletonHolder.INSTANCE;
}
}
-
SingletonHolder必须是 static 且 private，避免被外部误用 -
INSTANCE声明为 final 和 static，确保唯一性和不可变性 - 外部类构造器私有，防止反射攻击（需配合其他防护，如枚举更彻底）
- 无需
synchronized或双重检查锁，JVM 类初始化本身是线程安全的
为什么比双重检查锁（DCL）更简洁可靠
双重检查锁需要 volatile 修饰实例字段、复杂的判空逻辑，且易因指令重排序或 JDK 版本差异出错；而静态内部类方案把同步逻辑交给 JVM，由类加载器保证——这是 JVM 规范强制要求的线程安全行为。
立即学习“Java免费学习笔记（深入）”；
- 无同步开销：后续调用直接返回已存在的引用，零额外成本
- 无内存可见性问题：类初始化完成后，
INSTANCE对所有线程可见 - 天然防反射：即使通过反射调用私有构造器，也无法绕过
SingletonHolder的初始化时机约束
注意事项与常见误区
该模式虽优雅，但需注意边界情况：
- 如果外部类中有其他静态字段或静态代码块，在类加载时就会执行，可能间接触发内部类初始化（极少发生，但需留意类初始化依赖链）
- 不能用于需要传参初始化的单例（如依赖配置），因为
INSTANCE是编译期确定的静态初始化 - 若单例需实现
Serializable，必须定义readResolve()防止反序列化破坏单例
