静态变量循环依赖导致 null 报错，写代码的朋友多少都踩过这个坑。表面上看是个 NullPointerException，但背后的逻辑其实很清楚：类的初始化顺序被打乱了。Ja va 类加载器在初始化 static 字段时，严格遵循声明顺序和依赖关系——先声明、先初始化。可一旦出现 A 依赖 B，B 又依赖 A 这种"死锁"式的相互引用，就很容易出现某个字段还没初始化完毕就被访问的情况，结果自然是 null。
看报错堆栈定位具体字段
拿到 NullPointerException 的堆栈后，别急着慌。重点盯着抛出异常的那一行——通常是某个静态字段的方法调用或者属性访问，比如 MyClass.SERVICE.doSomething() 这种写法。搞清楚是哪个类、哪个静态字段报的空。然后顺着堆栈往上追，看看这个字段是在什么静态上下文中被访问的：是 static 块里？static final 初始化表达式？还是某个静态方法调用？这一步找准了，后面就好办了。
检查类的静态初始化块和静态字段声明顺序
打开涉及到的几个类，老老实实逐行检查 static 字段声明和 static {} 块。重点看几件事：
- 字段 A 的初始化是否依赖字段 B（比如
static Service A = B.create();），而 B 的初始化又反过来依赖 A（比如static Service B = new Service(A);） - 有没有通过静态方法间接制造依赖陷阱？比如
static X x = initX();，而initX()内部悄悄引用了另一个还没初始化的静态字段 - 特别提醒：常量（
static final的基本类型或字符串）会被编译器提前内联，但对象引用不会。别以为加了final就万事大吉，它只是引用不能变，初始化时机依然是问题的关键。
用 -XX:+TraceClassLoading 和日志辅助验证
启动 JVM 时加上 -XX:+TraceClassLoading 参数，可以直接观察类加载和初始化的实际顺序。不过更直观的做法，是在每个 static 块开头打个日志：
static {
System.out.println("Initializing ClassA...");
INSTANCE = new ClassA();
System.out.println("ClassA initialized.");
}
运行后看输出的先后顺序是否符合预期。一旦发现某个类的 static 块还没跑完，另一个类就试图读取它的静态字段，那就坐实了循环依赖的问题。这个排查手段虽然朴素，但往往最有效。
重构方案：延迟初始化或拆分依赖
问题的根源在于静态初始化阶段的强依赖关系，那么修复思路也就清晰了——避免在 static 初始化阶段互相"绑架"：
- 将直接 new 对象或方法调用改为延迟加载模式，比如
private static volatile Service instance;配合同步的 getInstance() 方法 - 把互相依赖的逻辑从静态初始化抽到实例方法中，交给 Spring 这类容器来管理生命周期，让 static 只做它该做的事
- 提取公共配置或上下文到一个第三方类，让 A 和 B 都依赖它，而不是彼此依赖——这招叫"引入中间人"
- 用 ServiceLoader 或 SPI 机制做运行时发现，实现解耦。这样绕过了编译期的静态引用，初始化顺序就不是问题了。
