静态代码块无法延迟加载，它属于饿汉式，在类首次主动使用时立即执行；真正的延迟加载需借助静态内部类，仅当首次调用getinstance()访问holder.instance时才初始化，从而实现按需创建。
Java静态代码块本身不支持延迟加载——它天生是“饿汉式”的，类一初始化就执行。所谓“延迟”，必须借助其他机制（如静态内部类）来绕过静态代码块的刚性时机。理解这一点，才能避开常见设计误区。
静态代码块的真实执行时机
它只在JVM对类执行初始化阶段时运行，且仅一次。这个阶段不是“类被加载时”，而是“类首次被主动使用”时触发，比如：
- 调用该类的静态方法
- 创建该类的第一个实例（
new） - 读取或赋值一个非final静态字段（注意：
public static final int PORT = 8080;这种编译期常量不会触发初始化） - 通过
Class.forName("X")反射加载（ClassLoader.loadClass()不会触发）
一旦触发，静态代码块与静态变量赋值语句按源码顺序交替执行，父类优先于子类。它早于任何构造器、也早于main方法中的第一行代码。
为什么静态代码块不能“延迟”？
因为它的执行由JVM类初始化机制硬性绑定：只要类进入初始化阶段，所有静态块必然立即执行，无法感知业务是否真正需要该逻辑。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 哪怕你只写
System.out.println(Singleton.class);，只要该类此前未初始化，静态块就会立刻跑 - 资源（如数据库连接、大对象）会在应用启动早期就被创建，即使后续从未调用相关功能
- 若块中抛出异常（如
IOException），整个类将永久失效，后续访问直接抛NoClassDefFoundError
想延迟？用静态内部类替代
真正的延迟加载靠的是类初始化的触发条件隔离：外部类可加载，但其静态内部类不被引用就不会初始化。
-
Singleton类可以被反射获取、甚至多次加载，但Holder类直到getInstance()里第一次访问Holder.INSTANCE才初始化 -
Holder被编译为独立字节码文件（如Singleton$Holder.class），无this引用，不阻碍GC - JVM保证
static final字段初始化天然线程安全，无需synchronized或volatile
这是目前最轻量、高效、符合JVM规范的懒加载单例实现方式。
实战选择建议
别纠结“让静态块变懒”，而要根据场景选对机制：
- 配置预加载、日志器初始化、驱动注册等确定性动作 → 用静态代码块（确保启动即就绪）
- 重量级单例（含IO、计算、依赖注入）→ 用静态内部类模式（真正按需创建）
- 需要捕获初始化异常或做复杂校验 → 静态内部类 + try-catch包裹构造逻辑（静态块里抛异常会杀死整个类）
- 框架管理环境（如Spring）→ 优先用
@PostConstruct或@Bean(initMethod)，避免硬编码静态初始化
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
