静态代码块在类初始化阶段执行，早于任何对象创建。它随类首次主动使用而运行且仅一次，用于一次性资源加载；若放构造器中会导致重复执行，故必须置于静态代码块内。
静态代码块天然就在对象创建前完成执行——它不依赖实例，只依赖类的初始化时机。只要类被 JVM 主动使用（比如调用静态方法、访问非 final 静态字段、new 第一个实例等），静态代码块就会在该类初始化阶段立即运行，且只执行一次。这个阶段远早于任何构造器或实例代码块。
执行时机严格早于对象创建
JVM 类加载流程中，“初始化”阶段排在“准备”之后、“实例化”之前。此时：
- 静态变量已分配内存并设默认值（如 null、0）
- 静态代码块按源码顺序逐行执行，完成真实赋值和副作用操作
- 所有实例相关逻辑（构造代码块、构造器）都尚未启动
也就是说，第一个 new 实例的动作，本身就会触发类初始化，静态代码块必然已在 new 执行前跑完。
资源加载必须放在静态代码块内，而非构造器中
如果把资源加载逻辑写在构造器或实例代码块里，每次 new 都会重复执行，既低效又可能出错。而放在静态代码块中：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- 资源只加载一次，结果可复用（如 static final Properties config）
- 加载失败会立即暴露（抛 ExceptionInInitializerError），避免静默错误
- 后续所有实例共享同一份已就绪资源，无需再判断是否初始化
例如：从 classpath 加载配置文件，应这样写：
static {try (InputStream is = MyClass.class.getResourceAsStream("/config.properties")) {
if (is == null) throw new RuntimeException("config.properties not found");
config.load(is);
} catch (IOException e) {
throw new ExceptionInInitializerError(e);
}
}
避免常见干扰因素
确保资源真正“提前就绪”，需避开以下误区：
- 不要在静态块中调用其他尚未初始化类的静态方法（易因加载顺序导致 null）
- 不要用 ClassLoader.loadClass() 加载本类依赖项——它不触发初始化；要用 Class.forName() 才能联动触发
- 不要把耗时操作（如远程 HTTP 请求、数据库连接）塞进静态块，否则会阻塞整个类的可用性
- public static final 编译期常量（如 int PORT = 8080）不会触发类初始化，不能靠它“唤醒”静态块
验证是否真正在对象创建前执行
最直接的方式是加日志或断点：
- 在静态代码块里打印日志，再在构造器第一行也打印
- 运行 new MyClass()，观察输出顺序一定是“静态块日志 → 构造器日志”
- 哪怕只写 System.out.println(MyClass.class);，只要此前未初始化，静态块也会立刻执行
这说明：静态代码块不是“等你 new 才开始准备”，而是“你一碰这个类，它就已完成准备”。
