静态代码块在类加载时执行且仅一次，父类先于子类执行；主动引用触发初始化，被动引用不触发；异常导致类加载失败且不可重试；需避免i/o、循环依赖及跨classloader问题。
静态代码块在类加载时执行，且只执行一次
Java 中父类的 static 代码块会在该类首次被主动使用（比如 new 实例、访问静态成员、反射加载等）时触发类加载，此时 JVM 会按继承链从上到下初始化：先加载并执行父类的静态代码块，再执行子类的。这个过程和对象创建无关，哪怕你只写 Parent.class，父类静态块也会执行。
常见错误现象：Exception in thread "main" java.lang.NoClassDefFoundError 或静态变量为 null，往往是因为静态块里依赖了尚未初始化的类或资源（比如未初始化的静态 final 配置），而 JVM 在类加载阶段就抛异常，导致整个类加载失败，后续所有引用都报错。
- 只有当类被「主动引用」才会触发初始化；被动引用（如子类引用父类静态字段、数组定义）不会触发父类初始化
- 同一个类在同一个 ClassLoader 下只会初始化一次，即使多次 new 实例，静态块也只跑一遍
- 接口也有静态代码块，但接口的初始化不触发其父接口的初始化（除非直接访问父接口的静态成员）
父类和子类静态代码块的执行顺序严格按继承层级
不是按文件顺序，也不是按代码书写位置，而是由 JVM 的类加载器在解析类依赖时决定的：先确保父类已初始化，才允许子类进入初始化阶段。所以 Parent 的 static 块一定在 Child 的 static 块之前执行，哪怕子类代码写在前面。
使用场景：常用于单例初始化、全局配置预加载、Native 库加载（System.loadLibrary 必须在静态块中调用）。
立即学习“Java免费学习笔记（深入）”；
- 如果父类静态块抛出未捕获异常，子类将永远无法完成初始化，任何对子类的主动引用都会抛
ExceptionInInitializerError - 静态块内不要调用可能触发子类初始化的方法（比如静态方法里返回 new Child()），否则可能引发死锁或循环初始化
- 不同 ClassLoader 加载的同名类，各自有独立的静态块执行周期
静态代码块 vs 静态字段初始化顺序要小心
静态字段声明和静态代码块混合时，JVM 按源码自上而下顺序执行——先声明的字段先初始化，再执行紧随其后的静态块，依此类推。这点容易被忽略，尤其当字段是 static final 且依赖尚未执行的静态块时，值会是默认值（如 0、null）。
class Parent {
static int a = 10;
static { System.out.println("a=" + a); } // 输出 a=10
static int b = a * 2; // b=20
static { System.out.println("b=" + b); } // 输出 b=20
}性能影响很小，但若静态块里做了耗时操作（如读文件、连数据库），会拖慢首次类加载速度，且无法重试——失败即永久不可用。
-
static final基本类型或字符串字面量，在编译期就被内联，不走运行时初始化流程 - 非字面量的
static final（如new Object()）仍需在静态块或声明处初始化，顺序依然重要 - 避免在静态块中做阻塞 I/O，否则可能卡住整个类加载线程，影响并发启动
调试类加载顺序最直接的办法是加 -XX:+TraceClassLoading
启动 JVM 时加上这个参数，就能看到每个类被加载和初始化的真实时机。比靠猜或打日志更可靠，尤其在有多个模块、OSGi 或 Spring Boot 类加载器嵌套的场景下。
容易踩的坑：IDE 运行时默认不开启该参数，而且输出刷屏快，建议配合 grep 过滤关键类名；另外，某些框架（如 Lombok）生成的类可能不显示在 trace 中，因为它们是编译期注入的字节码。
- 生产环境慎用，日志量极大，可能压垮磁盘或影响性能
- 结合
jstack看当前类加载线程栈，能确认是否卡在某个静态块里 - 如果发现父类没加载却先初始化了子类，基本可以断定用了自定义 ClassLoader 且没遵循双亲委派
类加载的初始化阶段看似简单，但一旦涉及跨模块、热部署或容器环境，静态块的实际执行时机就很容易偏离预期。最麻烦的是它失败时不给二次机会，连 try-catch 都包不住——异常发生在初始化入口，只能靠外围监控或提前验证。
