该问题本质是静态初始化阶段隐式触发类依赖闭环引发的JVM类加载死锁。当类A的static块中lambda访问类B的static字段，而B又依赖A未初始化的static变量时，形成A→B→A初始化环，线程阻塞在Class对象监视器上。
这个问题本质上不是“异步闭包”导致的死锁，而是静态初始化阶段隐式触发类依赖闭环所引发的 JVM 类加载死锁。Java 中不存在真正意义上的“异步闭包”，所谓“异步闭包声明”（如 lambda、方法引用）若出现在 static 块或 static 字段初始化中，其捕获逻辑可能间接访问其他尚未完成初始化的类——这正是死锁根源。
识别：静态初始化中的隐式依赖链
当一个类 A 的 static 块里定义了 lambda，并在该 lambda 内部读取类 B 的 static 字段（哪怕只是引用），JVM 会尝试初始化 B；而如果 B 的初始化又反过来依赖 A 中某个还未赋值的 static 变量，就会形成 A → B → A 初始化等待环。线程栈中会出现类似：
at com.example.A.<clinit>(A.java:15)at com.example.B.<clinit>(B.java:9)at com.example.A.lambda$static$0(A.java:12)
且阻塞在 WAITING on java.lang.Class@xxx ——这是类初始化锁（java.lang.Class 对象本身作为 monitor）被持有时的典型特征，与普通对象锁不同。
规避：禁止在 static 上下文中触发跨类初始化
静态字段/块中严禁出现任何可能触发其他类初始化的操作，包括但不限于：
- 直接访问其他类的
static final字段（尤其该字段类型为非基本类型或含初始化逻辑） - lambda 或方法引用中使用外部类的 static 成员（如
() -> OtherClass.NAME） - 调用接口的
static方法（JVM 会触发接口初始化） - 使用
Class.forName()、getResourceAsStream()等反射/资源加载操作
重构：用 Holder 模式或懒加载替代静态初始化
把有潜在依赖风险的逻辑从 static 块中剥离，推迟到首次实际使用时执行：
- 对单例类，改用静态内部类 Holder 模式：
private static class Holder { static final Service INSTANCE = new Service(); }
首次调用Holder.INSTANCE才触发初始化，天然线程安全且延迟 - 对配置或工具类，提供显式
init()方法，由上层控制时机，失败可抛出异常而非静默吞掉 - 若必须用 lambda，确保它不捕获任何 static 成员，只依赖参数或局部变量；必要时将其声明移至实例方法中
诊断：用原始输出定位卡点
别依赖日志框架（log4j/slf4j 的 logger 本身可能正卡在初始化竞争中）。在关键 static 赋值前后插入：
System.err.println("A: start init");System.err.println("A: reading B.flag");System.err.println("A: end init");
观察输出序列是否中断在某一行，就能快速锁定哪一步触发了未就绪类的初始化请求。
