静态变量循环依赖导致jvm类初始化死锁，表现为无异常、无日志、cpu异常；需通过system.err.println标记初始化流程，识别跨类调用链中的未完成字段访问，并以延迟初始化、提取公共配置或方法封装等方式解耦。
启动卡死若由静态变量循环依赖引发，本质是 JVM 类初始化阶段陷入“互相等待”——A 等 B 初始化完成才继续，B 又在初始化中读取了尚未赋值的 A 的静态字段，而该字段此时为 null 或 0，触发 ExceptionInInitializerError 或静默挂起。这类问题不抛异常、无日志、CPU 占用异常，必须从初始化顺序切入定位。
还原静态初始化的实际执行流
Java 规定：类首次主动使用时，JVM 按源码自上而下执行静态变量赋值（含右侧表达式）和静态块，且仅一次。关键在于——某行代码若触发另一类初始化，当前类的后续初始化会立即中断，跳转过去。
- 例如 A 类中
static final B b = new B();出现在static final String name = "A-done";之前，则 new B() 会立刻触发 B 的初始化；若 B 的构造器或静态块中访问 A.name，此时 name 还未赋值，值为 null - 不要只看声明顺序，要画出跨类调用链：A → B → C → A，任一环中读取上游未完成初始化的字段，即构成死锁点
- 用
System.err.println在每个静态变量赋值前、每个静态块开头加标记日志（避免被 JIT 优化），运行后观察输出断点，如出现 “A: start” → “B: start” → “B reading A.flag” → “null”，就锁定失效位置
识别隐式触发初始化的高危写法
很多循环依赖不是显式 new 或 .class 引用，而是藏在看似安全的语法里：
-
static final List<string> DATA = initList();</string>—— 若initList()内部调用了 C.class.getMethods() 或 D.getInstance()，就会触发 C/D 初始化 - 枚举类中，每个常量实例化即触发整个枚举类初始化；若其构造器里引用了 Service.XXX 静态字段，而 Service 又依赖该枚举，就形成闭环
- 接口中定义
static void log(String s) { Logger.info(OtherClass.TAG); }—— 第一次调用该 static 方法时，会初始化 OtherClass，但开发者常误以为接口无副作用 - 不同 ClassLoader 加载同名类（如插件场景），其静态域完全隔离；若代码逻辑假设它们共享某个静态计数器，实际读到的是默认值，导致条件判断永远不成立、线程空转
验证与解耦的关键操作
确认循环链后，优先采用低侵入、可验证的方式切断：
- 将相互引用的静态字段改为 延迟初始化：用
static Supplier<x> xRef = () -> X.INSTANCE;</x>替代直接赋值，首次 get() 时才触发初始化，打破初始化时序耦合 - 提取公共配置为独立类，确保它不依赖 A 或 B；让 A 和 B 都只依赖该配置类，而非彼此
- 对必须跨类访问的静态状态，改用 方法调用替代字段直取，例如把
A.COUNTER改为A.getCounter()，并在方法内加判空或同步初始化逻辑 - 在测试中模拟类加载顺序：用自定义 ClassLoader 分别加载 A 和 B，并控制 loadClass 调用顺序，复现并验证修复效果
不复杂但容易忽略：静态初始化死锁不会像 Spring Bean 循环依赖那样报明确异常，它更安静，也更难捕获。盯住执行顺序、打准日志位置、揪出隐式触发，问题自然浮出水面。
