静态初始化块捕获异常不直接导致死锁，真正死锁源于异常掩盖下的跨类初始化循环依赖：a在catch后访问未初始化的b字段，b又依赖a未就绪字段，形成jvm类初始化锁等待闭环；需用jstack查waiting on class、嵌套调用链，并以system.err.println标记执行流定位断点，最终通过holder模式或延迟初始化解耦。
静态初始化块中捕获运行时异常本身不会导致死锁，真正引发类加载死锁的是异常掩盖下的跨类初始化依赖循环——即A类static块在try-catch中“吞掉”了异常，却仍继续执行，并访问了尚未完成初始化的B类静态成员；而B类初始化又反过来依赖A类某个未就绪的字段，形成JVM内部的类初始化锁等待闭环。
看线程栈，确认是否真卡在类初始化锁上
用jstack
- 线程状态为WAITING on java.lang.Class（不是普通对象锁）
- 堆栈顶部含at java.lang.Class.forName0(Native Method)或at java.lang.ClassLoader.loadClass
- 调用链中嵌套出现多个
，例如：
at com.example.A.(A.java:12)
at com.example.B.(B.java:8)
at com.example.A.(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 + 显式初始化方法，禁用内联赋值
