静态内部类单例线程安全源于jvm类加载机制对方法的强制同步，首次访问holder.instance触发初始化，jvm自动加锁确保仅执行一次且原子完成，无需volatile或synchronized。
静态内部类单例的线程安全，不靠代码加锁，而靠 JVM 在类加载阶段对 <clinit></clinit> 方法的强制同步机制——这是 JVM 规范保障的底层行为，不是 Java 层面的编程技巧。
类加载触发时机决定“首次创建”的边界
外部类（如 Logger）加载时，其静态内部类 Holder 并不会被加载或初始化。只有当 getInstance() 中首次读取 Holder.INSTANCE 时，JVM 才判定这是对 Holder 的“主动使用”，从而触发它的加载与初始化。
- 这个“首次”由 JVM 精确控制，不受 Java 代码中 if 判断或 synchronized 影响
- 多个线程同时执行到
return Holder.INSTANCE，只会有一个线程真正进入Holder的初始化流程 - 其余线程阻塞等待，初始化完成后直接读取已构造好的
INSTANCE
<clinit></clinit> 是 JVM 自动加锁的原子过程
每个类（包括静态内部类）在初始化时，JVM 会生成一个特殊的 <clinit></clinit> 方法，它包含所有静态字段赋值和静态块逻辑。JVM 保证：
- 同一类加载器下，一个类的
<clinit></clinit>最多执行一次 - 执行前自动加锁，多线程竞争时仅一个线程获得执行权
- 字段赋值、对象构造、内存可见性全部由 JVM 一并保障，不存在指令重排或部分初始化问题
为什么不需要 volatile 或 synchronized
INSTANCE 声明为 public static final，意味着：
- 它是编译期常量引用（指向堆中对象），JVM 在
<clinit></clinit>执行完毕后才将其写入方法区的静态存储区 - 该写入操作天然具有“happens-before”关系，对所有后续线程立即可见
- 没有中间态：要么没初始化（
Holder还未加载），要么完全初始化好（INSTANCE已安全发布）
和手动同步的本质区别
对比双重检查锁（DCL）：
- DCL 需要
volatile防止对象逸出，依赖程序员正确理解内存模型 - 静态内部类把同步责任交给 JVM，开发者只需遵守规范写法：私有构造、static 内部类、final 实例字段、极简
getInstance() - 哪怕并发量极大，只要类加载器一致，就不会出现多个实例或初始化异常重复抛出
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
