静态代码块与静态变量按源码自上而下顺序执行且仅一次；若跨类静态引用形成循环依赖，未完成初始化的字段值为默认值（如null、0），导致空指针或exceptionininitializererror。
初始化块的执行顺序是排查静态变量循环依赖问题的关键线索。Java 类加载时，静态变量和静态初始化块按源码中出现的**自上而下顺序**执行，且只执行一次；若多个类在初始化过程中相互读取对方尚未完成初始化的静态字段，就会产生“部分初始化”状态——值为默认值（如 null、0、false），进而引发空指针、逻辑错乱或 ExceptionInInitializerError。
看静态初始化的实际执行流
不要只看声明位置，要还原 JVM 实际执行路径：
- 当类 A 被首次主动使用（如 new 实例、访问静态成员），JVM 开始初始化 A
- 按源码顺序逐行执行：先赋值静态变量（含其右侧表达式），再执行静态块
- 若某静态变量初始化时触发了类 B 的初始化（例如调用 B 的静态方法、访问 B 的静态字段），则立即跳转去初始化 B
- B 初始化过程中若又回读 A 的某个静态字段——此时 A 可能只执行了一半，该字段仍是默认值
用日志+断点定位中断点
在每个静态变量赋值语句和静态块开头加可识别的日志输出（避免 System.out.println 被优化掉，可用 java.util.logging.Logger 或简单 System.err.println）：
class A {
static final String TAG = "A";
static {
System.err.println(TAG + ": entering static block");
}
static final B b = new B(); // ← 此处会触发 B 初始化
static final String name = "A-done"; // ← 这行还没执行到
}
运行后观察输出顺序。若看到 A: entering static block → B: entering static block → B trying to read A.name → null，就锁定了循环链和失效点。
检查跨类静态引用的“隐式触发”
常见易忽略的触发点：
-
静态字段是 final 但右侧是方法调用：如
static final List<string> DATA = initList();</string>，而initList()内部调用了另一个类的静态方法 - 枚举类的构造器中引用其他类静态字段：枚举常量初始化即触发类初始化
- 接口中定义了 static 方法，且该方法访问了其他类的静态成员：接口初始化虽不常发生，但在被首次调用时也会触发
- 类加载器层级混用：不同 ClassLoader 加载的同名类，其静态域完全隔离，但开发者误以为共享，导致逻辑误判
验证与修复建议
确认问题后，优先采用以下方式解耦：
-
延迟初始化：把静态字段改为
private static volatile Type instance;，配合双重检查锁或 Holder 模式，在首次访问时才创建 -
拆分初始化阶段：将强依赖逻辑从静态块移出，放到明确的
init()方法中，由上层统一调度 - 引入中间协调类：让 A 和 B 都依赖一个无静态依赖的 Config 或 Registry 类，由它负责注入彼此引用
-
避免在静态上下文中做业务判断：如
static final boolean ENABLED = Boolean.parseBoolean(System.getProperty("x"));看似安全，但如果 getProperty 触发了其他类加载，则风险仍在
