静态代码块中捕获异常易引发JVM类加载死锁，本质是异常后继续访问未就绪的依赖类导致初始化闭环；应避免IO、网络、跨类static调用等高危操作，改用Holder模式或懒加载确保安全。
静态代码块里捕获异常，表面看是“兜住了错误”，实际常埋下类加载死锁隐患——真正卡住的不是代码，而是JVM对类初始化状态的内部锁。关键不在“有没有异常”，而在“异常之后是否继续访问未就绪的依赖类”。
看清本质：死锁不是因为catch，而是因为隐式依赖闭环
静态块中try-catch吞掉异常本身不导致死锁。问题出在：A类初始化失败后仍继续执行，并读取B类的静态字段；而B类初始化又依赖A类某个尚未赋值的static变量，形成JVM级的类初始化等待链。
- 线程栈中出现类似at com.pkg.A.<clinit>(A.java:12) → at com.pkg.B.<clinit>(B.java:8) → 再回到A.<clinit>，就是典型闭环信号
- 注意WAITING on java.lang.Class（不是普通对象锁），这是类初始化锁阻塞的明确标志
- 枚举类、接口static方法、Class.getResourceAsStream()等操作都可能意外触发另一方初始化，加剧隐蔽性
快速定位：用最朴素的方式暴露执行断点
别依赖日志框架——log4j或slf4j自身的static logger可能正卡在初始化竞争中。改用System.err.println打点，确保不被JIT优化删掉：
- 每个static final字段赋值前加：System.err.println("A: cfg start");
- 每个static{}开头和结尾加：System.err.println("A: init start / end");
- 观察输出序列，如出现“A: init start”→“B: init start”→“A: reading B.flag”→卡住，说明B.flag尚未完成初始化
安全重构：把初始化责任从static块移出来
静态块只做“声明”，不做“执行”。把有风险的操作剥离出去，交给可控时机：
立即学习“Java免费学习笔记（深入）”；
- 用Holder模式延迟实例化：private static class Holder { static final Service INSTANCE = new Service(); }，首次调用Service.getInstance()时才触发初始化
- 改用getInstance()懒加载方法，内部加synchronized或使用AtomicReference控制单例创建
- 配置类可设计为“可重试+显式失败”，比如init()返回boolean或抛RuntimeException，让调用方决定降级或告警，而不是静默失败后继续用null
硬性守则：静态块准入清单
以下操作严禁出现在static {}中，否则等于主动引入不可恢复故障：
- 读取配置文件、环境变量或系统属性（可能IO异常）
- 发起网络请求、连接数据库、调用远程服务
- 解析JSON/XML、反序列化任意外部数据
- 调用其他类的static方法（尤其该方法内部含new、IO或依赖注入）
- 直接使用LogFactory.getLogger()等日志获取逻辑
