ClassCircularityError 由类加载时静态初始化阶段的循环依赖引发，非循环继承所致；当类A初始化中访问类B静态成员，而B又反向触发A初始化未完成时，JVM检测到<clinit>闭环即抛出该错误。
ClassCircularityError 并不是由“循环继承”引发的，而是由**类加载过程中的循环依赖（特别是静态初始化阶段的相互触发）**导致的。Java 中不允许继承关系形成环（编译期就会报错），所以不存在“循环继承”；但类 A 在初始化时主动访问类 B 的静态成员，而类 B 初始化又反过来触发类 A 的静态初始化（尚未完成），此时 JVM 检测到初始化链闭环，抛出 ClassCircularityError（注意：这是 LinkageError 子类，非 Exception，无法被常规 catch(Exception) 捕获）。
理解触发条件：静态初始化 + 跨类主动访问
该错误本质是 JVM 在执行类的 <clinit> 方法（即 static 块和静态字段初始化）时，发现正在初始化的类又被当前初始化链再次请求——说明存在隐式、间接的静态依赖闭环。
- 仅声明
static ClassB b;不会触发 B 初始化，不构成风险 - 若在 A 的 static 块中写
System.out.println(B.NAME);，且 B 的 static 块又调用A.getValue()，就可能形成闭环 - 枚举类、静态内部类、
Class.forName(..., true, loader)显式初始化等场景也容易意外触发
快速定位：从堆栈和类加载日志入手
错误堆栈通常只显示顶层类名（如 java.lang.ClassCircularityError: com.example.A），需结合 JVM 参数暴露深层线索：
- 添加
-XX:+TraceClassLoading和-XX:+TraceClassInitialization，观察类加载与初始化顺序，找到最先被重复请求的类 - 配合
-verbose:class确认是否有多版本类被加载（如不同 classloader 加载同名类，也可能干扰初始化状态判断） - 检查报错类的
static块、static final字段初始化表达式、静态内部类首次引用点
修复核心：打破静态初始化链闭环
目标是让任一环节的静态访问不强制触发另一方的初始化。常用手段：
立即学习“Java免费学习笔记（深入）”；
- 将“触发对方初始化”的代码移出
static上下文，改为懒加载（如用方法返回，而非 static 字段直接赋值） - 用反射替代直接静态引用：
Class.forName("com.example.B", false, loader)（false表示不初始化） - 把强依赖下沉到实例方法中，避免类加载期耦合；或引入第三方协调类，解耦双方静态逻辑
- 检查是否误用
Enum：枚举常量初始化若引用其他类静态成员，极易形成隐式闭环
预防建议：设计与构建阶段控制
静态初始化逻辑应尽量简单、无副作用、无跨类强依赖：
- 禁用 Checkstyle/PMD 规则：禁止 static 块中调用其他类的 public static 方法或字段（除非明确是常量类）
- 使用构建工具（如 Maven Enforcer）检查模块间循环依赖（虽不等价于运行时初始化环，但高度相关）
- 单元测试覆盖类加载路径：用
ClassLoader.loadClass()+Class.forName()组合模拟启动顺序，验证初始化稳定性
