Java类加载器本身不直接处理类循环依赖死锁，因类加载是单线程委托机制；但静态初始化阶段（<clinit>）中A→B→A双向触发会形成持有并等待+循环等待，导致ExceptionInInitializerError或永久阻塞，需通过避免静态块跨类调用、采用Holder模式及确保ClassLoader委托链无环来防范。
Java 类加载器本身不直接处理类之间的循环依赖引发的死锁，因为类加载过程（ClassLoader.loadClass()）是单线程、委托优先、按需加载的机制，它天然规避了“类A在加载时等待类B加载完成，而类B又反过来等待类A”的典型循环等待场景。但现实中，开发者主动触发的静态初始化阶段（<clinit>）可能引入人为循环依赖，进而导致类加载死锁或 NoClassDefFoundError / ExceptionInInitializerError 等异常。
关键要区分两类“循环依赖”：
- 类加载期循环依赖（极少见，JVM 层面有保护）
- 静态初始化阶段的相互阻塞（常见风险点，需重点防范）
下面从原理和实践两方面说明如何防止：
理解 JVM 类加载的线程安全机制
JVM 对每个类的 `
立即学习“Java免费学习笔记（深入）”；
但注意：这个锁**不会跨类传播**。也就是说，ClassA 的 `
真正危险的是静态初始化链中的双向触发
例如：
class A {
static { System.out.println("A init"); B.doSomething(); }
}
class B {
static { System.out.println("B init"); A.value = 42; } // ← 此处试图写 A 的静态字段
static void doSomething() {}
}若线程先加载 A，则 A 的 `
这种情形下，JVM 会抛出 ExceptionInInitializerError 或导致线程永久阻塞（取决于 JDK 版本和并发上下文）。
实用防御策略
- 避免在静态块中调用其他类的静态方法或访问其静态字段，尤其不能形成 A→B→A 调用链；把逻辑移到实例方法或延迟初始化（如 Holder 模式）中。
-
使用“懒汉式 Holder 类”替代直接静态初始化：将依赖推迟到首次使用时，且由 JVM 保证线程安全与初始化顺序。
class A { private static class Holder { static final B INSTANCE = new B(); } static B getB() { return Holder.INSTANCE; } } - 检查类加载路径是否含自定义 ClassLoader 的循环委托：比如 ClassLoaderA 委托给 ClassLoaderB，ClassLoaderB 又回调 ClassLoaderA 的 `findClass()`，这虽不常见，但在 OSGi、模块化容器或热部署框架中可能发生。应确保委托链是单向无环的。
-
启用 JVM 参数辅助诊断：添加
-XX:+TraceClassLoading和-XX:+PrintGCDetails（配合日志分析），或使用jstack -l <pid>查看线程是否卡在 `` 锁上。
Spring 等框架中的类加载 vs DI 循环依赖不是一回事
需要明确：Spring 的“循环依赖”是指 Bean 实例化过程中的依赖注入闭环（如 A 构造器注入 B，B 又构造器注入 A），它发生在运行时对象层，与 JVM 类加载无关。Spring 通过三级缓存、提前暴露半成品对象等方式解决 —— 这属于框架能力，不影响底层类加载安全。
而类加载死锁只发生在 ClassLoader.loadClass() → `
