classcircularityerror 发生在类加载阶段，是 jvm 因类间静态初始化循环依赖而主动中止加载的 error；它不同于 spring 循环依赖，编译通过但运行时触发即崩溃，无法捕获，需切断 static 初始化闭环。
ClassCircularityError 出现在类加载阶段
这个错误不是运行时抛出的 Exception，而是 Error，意味着 JVM 在尝试加载某个类时发现它直接或间接依赖自己，导致类加载器无法完成解析——此时程序已无法正常继续，JVM 会直接中止该类的加载流程。
它和 Spring 的循环依赖（比如 A 依赖 B、B 又依赖 A）不是一回事：Spring 那是对象创建阶段的问题，有代理、三级缓存等机制兜底；而 ClassCircularityError 发生在字节码还没真正“活”起来之前，连 static 块都可能没执行。
- 常见现象：
java.lang.ClassCircularityError: A，堆栈里通常只有ClassLoader.loadClass或Class.forName相关调用 - 典型场景：两个类互相用对方的静态字段/方法作初始化值，或在
static块里直接 new 对方实例 - 注意：编译器不报错，javac 能过；但一运行到触发加载的位置就崩
怎么复现一个典型的 ClassCircularityError
最直白的方式是让两个类在 static 初始化阶段互相拉对方一把。JVM 加载 A 时，发现其 static 块里要访问 B 的静态字段，就得先加载 B；而 B 的 static 块又回头访问 A 的静态字段——环闭合了。
示例：
立即学习“Java免费学习笔记（深入）”；
class A {
static final String NAME = B.NAME + "_A";
static { System.out.println("A loaded"); }
}
class B {
static final String NAME = A.NAME + "_B";
static { System.out.println("B loaded"); }
}
只要在任意地方写一句 Class.forName("A") 或直接引用 A.NAME，就会触发 ClassCircularityError。
- 别指望
try-catch住它：它是Error，不是Exception，常规捕获无效 - IDE 运行时可能只显示 “Process finished with exit code 1”，需看完整日志才能看到具体错误名
- 模块化（JPMS）下如果
requires关系形成闭环，也会在模块解析阶段报类似错误，但提示不同
排查和修复的关键点
核心思路是：切断静态初始化链中的闭环。不能靠“延后加载”或“懒汉式”，因为 JVM 类加载本身是强顺序的，一旦触发就必须走完初始化。
- 把相互依赖的静态值改成非静态方法返回，或延迟到首次调用时计算（比如用
Supplier包一层） - 检查是否误把本该是实例依赖的逻辑写进了
static上下文（例如static Logger logger = LoggerFactory.getLogger(B.class)是安全的，但static Object x = new B()就危险） - 用
jdeps -s或 IDE 的“Find Usages”反向查哪些类在static块里引用了目标类，比盲猜快得多 - Gradle/Maven 多模块项目里，如果 A 模块依赖 B 模块，而 B 模块的测试代码或
src/main/resources里又硬编码引用了 A 的类，也可能在特定 classpath 下触发（尤其用了testCompile错误传递）
和 NoClassDefFoundError、ClassNotFoundException 的区别
这三个都发生在类加载期，但原因完全不同，不能混着查：
-
NoClassDefFoundError：类曾成功加载过，但运行时因链接失败（比如缺少依赖类、static块抛异常）被卸载了，再次引用时报错 -
ClassNotFoundException：纯路径问题，JVM 根本没在 classpath 里找到对应 .class 文件 -
ClassCircularityError：类定义本身存在逻辑闭环，JVM 主动拒绝加载，不涉及路径或缺失，只和字节码结构与初始化顺序有关
最容易忽略的是：它往往藏在第三方库的静态工具类里，比如你只是调用了一个看似无害的 StringUtils.isEmpty()，结果它内部某个分支偷偷加载了你项目里某个有循环初始化的类——这时候得靠 -XX:+TraceClassLoading 看加载顺序，而不是盯着自己的代码找。
