静态代码块中创建子类对象会触发父类初始化循环：父类初始化未完成时强制初始化子类，而子类又需父类先完成初始化，导致exceptionininitializererror或死锁。
静态代码块中创建子类对象，确实可能触发父类尚未完成初始化的问题，本质是类加载与初始化顺序被意外打破。核心排查方向是厘清 类加载（Loading）→ 链接（Linking）→ 初始化（Initialization） 三阶段中“初始化”的触发时机和依赖关系。
确认静态代码块执行时父类是否已进入初始化阶段
Java 规定：当首次主动使用某个类时，才触发其初始化；而子类初始化前，必须确保父类已完成初始化（JVM规范 §5.5）。但如果静态代码块在父类自身初始化过程中就 new 了子类，就会形成“父类初始化未完成 → 触发子类初始化 → 子类需先初始化父类 → 父类正在初始化中”的循环等待或异常状态。
- 检查该静态代码块所在类是否就是父类本身（常见于单例、工具类误写）
- 用 -XX:+TraceClassInitialization 启动 JVM，观察类初始化的实际顺序和卡点
- 查看日志或调试器中是否抛出
java.lang.ExceptionInInitializerError，其 cause 往往是java.lang.IllegalStateException或死锁线索
检查父类静态字段/静态块是否存在隐式依赖
父类的静态初始化可能依赖尚未赋值的静态字段，而这些字段又在子类初始化时被间接访问（例如通过反射、接口默认方法、或静态工厂），导致父类初始化逻辑被“打断”。尤其注意：
- 父类静态字段是否引用了子类的常量（编译期常量除外）、静态方法或静态内部类
- 父类静态块中是否调用了可能触发子类加载的方法（如
Class.forName("Sub")、Sub.class引用） - 是否有类似
static final String NAME = Sub.NAME_PREFIX + "_X";的跨类静态引用（若Sub.NAME_PREFIX不是编译期常量，会强制初始化 Sub 类）
验证类加载器与双亲委派是否被绕过
自定义类加载器若未严格遵循双亲委派，可能导致父类和子类由不同类加载器加载，此时 JVM 会视为两个无关类，不再强制“父类先初始化”约束，从而引发诡异行为。
- 打印
ParentClass.class.getClassLoader()和SubClass.class.getClassLoader()，确认是否为同一实例 - 检查是否使用了
Thread.currentThread().setContextClassLoader(...)并在静态块中触发了非预期加载 - 避免在静态初始化阶段动态切换或构造新类加载器
用最小可复现案例隔离问题
新建两个类，仅保留最简结构，逐步还原现场逻辑：
- 父类只含一个静态块 + 一个静态字段
- 子类只继承父类，无额外静态内容
- 在父类静态块末尾 new 子类实例
- 运行并观察是否立即失败 —— 若失败，说明是 JVM 层面禁止的循环初始化；若成功，说明原问题出在中间某处（如第三方库、Spring 上下文提前介入等）
不复杂但容易忽略：静态初始化是单线程、不可重入、且一旦失败整个类就变为“错误状态”，后续任何对该类的引用都会直接抛出 NoClassDefFoundError。所以定位要快，优先看初始化日志和堆栈根源。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
