Java不存在编译期死锁，所谓“编译期死锁”实为运行时类初始化死锁，根源在于static块中隐式触发跨类初始化形成循环依赖，需通过jstack定位WAITING on java.lang.Class线程栈、梳理静态依赖图并采用Holder模式等延迟初始化手段解决。
静态初始化块中隐式触发深层栈调用，不会导致“编译期死锁”——Java 编译期（javac）不执行代码、不加载类、不运行 static 块，因此**根本不存在编译期的死锁**。你遇到的其实是**运行时类初始化死锁**，常被误称为“编译期死锁”，本质是 JVM 在首次主动使用类时，执行 `
看线程栈，确认是不是类初始化卡住
用 jstack -l <pid> 抓取线程快照，重点找：
- 线程状态为 WAITING on java.lang.Class（不是普通 Object monitor）
- 堆栈顶部含 at java.lang.Class.forName0(Native Method) 或 at java.lang.ClassLoader.loadClass
- 中间连续出现多个 at com.xxx.A.<clinit>(A.java:xx) → at com.xxx.B.<clinit>(B.java:yy) → 再回到 A
找隐式触发点：哪些写法会悄悄拉起另一个类？
这些看似安全的操作，实际会在 static 块中隐式触发其他类初始化：
- 访问非编译期常量的静态字段：比如 public static final String HOST = System.getProperty("host"); —— 触发 System 类（通常安全），但若该字段在 B 中，而 A 的 static 块读它，就启动 B 初始化
- 调用静态方法：哪怕只是 Logger.info("init")，若 Logger 首次使用，可能触发其内部 Handler、Formatter 等类的初始化
- 枚举实例化：enum E { X; { useService(); } } —— 构造器里调 Service.XXX，而 Service 又引用 E.values()，立刻闭环
- 接口 static 方法调用：接口里定义 static void log() { Other.TAG }，首次调用时会初始化 Other 类
切断深层调用链的实操方式
目标不是“不让它调”，而是“不让它在初始化阶段调”：
- 把 static final X x = new X(); 改成 Holder 模式：private static class Holder { static final X INSTANCE = new X(); }，首次调用 Holder.INSTANCE 才触发初始化
- 将跨类逻辑从 static{} 中移出，改到首次使用的方法里，或用 @PostConstruct（Spring）/ ServiceLoader（模块化）接管
- 对高危调用加日志标记：在每个 static 块开头加 System.err.println("A.
start") ，运行后看输出中断在哪一环 - 禁止在 static 块中做任何可能触发新类初始化的操作——包括反射、资源加载、日志、JSON 解析、甚至 Objects.requireNonNull()
验证是否真解耦了
改完后别只靠启动成功判断，要主动验证：
- 用 -XX:+TraceClassInitialization 启动 JVM，观察类初始化顺序是否不再交叉嵌套
- 并发压测：用多线程同时触发 A 和 B 类（如 Class.forName("A") 和 Class.forName("B") 并发执行），确认不再卡住
- 检查 jstack 输出中，不再出现两个线程互相停在对方 `
` 的 WAITING 状态
