静态初始化块捕获异常不直接导致死锁，真正死锁源于异常掩盖下的跨类初始化循环依赖：A在catch后访问未初始化的B字段，B又依赖A未就绪字段，形成JVM类初始化锁等待闭环；需用jstack查WAITING on Class、嵌套<clinit>调用链，并以System.err.println标记执行流定位断点，最终通过Holder模式或延迟初始化解耦。

静态初始化块中捕获运行时异常本身不会导致死锁，真正引发类加载死锁的是异常掩盖下的跨类初始化依赖循环——即A类static块在try-catch中“吞掉”了异常，却仍继续执行，并访问了尚未完成初始化的B类静态成员；而B类初始化又反过来依赖A类某个未就绪的字段，形成JVM内部的类初始化锁等待闭环。

看线程栈，确认是否真卡在类初始化锁上

用jstack <pid>抓取线程快照，重点识别以下特征：

• 线程状态为WAITING on java.lang.Class（不是普通对象锁）
• 堆栈顶部含at java.lang.Class.forName0(Native Method)或at java.lang.ClassLoader.loadClass
• 调用链中嵌套出现多个<clinit>，例如：
  at com.example.A.<clinit>(A.java:12)
  at com.example.B.<clinit>(B.java:8)
  at com.example.A.<clinit>(A.java:15) ← 回到A，已构成环

查静态块里的“假成功”逻辑

捕获异常后若未设兜底值或校验状态，就直接使用可能为null的静态字段，极易触发隐式依赖：

• static块中catch (IOException e) { log.warn("config load failed"); } → 后续却直接用config.getTimeout()，而config为null
• try里调用OtherService.init()失败被catch，但没重置标志位，后续代码仍按“已初始化”分支走
• 静态字段声明顺序混乱：先static final Map m = parseConfig();，后static final Config cfg = new Config();，而parseConfig()内部又引用了cfg

用System.err.println标记真实执行断点

在每个静态变量赋值前、每个static{}开头和结尾加System.err.println("A: init step X start")，避免被JIT优化删掉：

• 运行后观察输出序列，如出现"A: start" → "B: start" → "A: reading B.flag" → 程序卡住，说明B.flag在A读取时尚未赋值
• 特别注意枚举类、接口static方法、Class.getResourceAsStream()等隐式触发初始化的操作
• 不要依赖log4j/slf4j——它们自身的static logger可能正处在初始化竞争中

改代码：让失败显性化，切断循环链

不靠catch“兜住”，而靠结构设计规避风险：

• 把互相依赖的初始化逻辑从static{}中移出，改用Holder模式：
  private static class Holder { static final Service INSTANCE = new Service(); }
  外部通过Holder.INSTANCE访问，JVM保证其初始化仅在首次调用时发生且线程安全
• 对必须启动即加载的配置，改用@PostConstruct（Spring）或ServiceLoader，脱离类加载期约束
• 静态字段全部改为private static volatile + 显式初始化方法，禁用内联赋值