Java中静态代码块引发的“死锁”本质是类加载循环依赖导致的初始化阻塞，表现为多线程卡在ClassLoader.loadClass或Class.forName，堆栈显示类初始化锁等待；识别需用jstack查含loadClass/forName及<clinit>调用的线程；定位关键在静态字段或代码块中跨类访问（如父类引用子类静态成员）；解决须打破<clinit>依赖闭环，采用延迟初始化、拆分中立类、避免前置引用等方案。
Java中静态代码块初始化子类静态变量引发死锁，本质是类加载过程中的循环依赖阻塞，不是传统线程竞争意义上的死锁，但表现类似——线程卡在java.lang.ClassLoader.loadClass或java.lang.Class.forName调用上，且JVM线程堆栈显示多个线程处于java.lang.ClassLoader.loadClass的BLOCKED或RUNNABLE（实际在等待类初始化锁）状态。
识别关键现象：看线程堆栈是否出现“类初始化锁等待”
用jstack <pid>抓取线程快照，重点查找以下特征：
- 多个线程堆栈中出现
at java.lang.ClassLoader.loadClass(...)或at java.lang.Class.forName(...)，且后续紧跟at java.lang.Class.getDeclaringClass(...)或直接停在java.lang.Class.initClass(...) - 某个线程正在执行某类的
<clinit>（即静态代码块），而另一个线程正尝试加载该类的子类或被其静态字段引用的类 - 两个（或多个）类的
<clinit>互相触发对方初始化，例如：A的静态块里访问B.class或B.SOME_STATIC_FIELD，而B的静态块又访问A.SOME_STATIC_FIELD
定位循环依赖链：从可疑静态字段/代码块入手
检查报错前刚加载的类及其静态成员，重点关注：
- 静态字段声明时直接调用其他类的静态方法或访问其静态字段（尤其是子类、工具类、配置类）
- 静态代码块中显式使用
Class.forName("xxx")、SomeSubclass.class或new SomeSubclass()（触发子类加载） - 父类静态块中初始化了子类的静态常量（如
public static final String VALUE = SubClass.STATIC_CONST;）
例如：Parent类静态块中写String x = Child.NAME;，而Child继承Parent且其NAME依赖Parent.DEFAULT_VALUE——此时Parent初始化未完成，Child又无法开始初始化，形成僵持。
立即学习“Java免费学习笔记（深入）”；
验证与复现：最小化测试 + 类加载日志
编写独立单元测试，仅加载疑似问题类，并启用JVM类加载调试：
- 启动参数加
-verbose:class，观察类加载顺序和卡点 - 用
java -XX:+TraceClassLoading -XX:+TraceClassInitialization进一步查看初始化触发时机 - 将可疑静态逻辑抽取为独立方法，在
main中分步调用，确认哪一行首次触发另一类加载
解决思路：打破静态初始化依赖闭环
核心原则是避免在<clinit>中触发尚未完成初始化的类的任何访问。可行方案包括：
-
延迟初始化：把静态字段改为懒汉式单例（如用
static Holder模式或Supplier<T>包装），确保首次访问时目标类已加载完毕 - 拆分依赖：将跨类的静态常量提取到第三方中立类（不继承、不被双方静态依赖），或改用运行时计算代替编译期绑定
-
避免子类静态字段前置引用：父类静态块中不要直接引用子类任何静态成员；子类静态字段若需父类值，改用
getDefaultValue()方法而非直接读取父类静态字段 -
检查ClassLoader委托机制：自定义ClassLoader时若重写了
loadClass且未正确处理双亲委派，也可能导致同一类被不同ClassLoader重复加载并相互等待
