类加载死锁是JVM方法区层面的隐式锁闭环，由多线程并发触发A↔B循环静态依赖导致加锁阻塞；其锁以类全限定名为monitor、不可重入、无超时，jstack可见waiting to lock与locked地址成对循环，高频见于protobuf等嵌套静态类场景。
运行时由不当类加载机制引发的方法区全局类加载死锁，不是传统意义上的线程间互斥锁死锁，而是 JVM 在方法区（Metaspace）中对类初始化阶段施加的隐式同步所导致的阻塞闭环。它发生在多个线程并发触发彼此依赖的类初始化时，因 JVM 对每个类的 <clinit></clinit> 执行强制加锁，且锁粒度是“以类全限定名为 monitor”，一旦形成 A→B→A 的静态初始化依赖链，就会卡在类加载器的内部同步块里，所有相关线程永久 WAITING，整个应用挂起。
核心成因：类初始化锁 + 循环静态依赖
Java 规范要求：一个类首次被主动使用（如调用静态方法、访问静态字段等）时，若尚未初始化，JVM 必须先获取该类对应的 Class 对象锁，再执行其 <clinit></clinit> 方法。关键点在于：
-
锁不可重入但跨类不感知：线程1持有 ClassA 锁执行
<clinit></clinit>，期间调用 ClassB 的静态方法 → 触发 ClassB 初始化 → 尝试获取 ClassB 锁； -
反向依赖即成闭环：若此时线程2正持有 ClassB 锁，并在其
<clinit></clinit>中调用了 ClassA 的静态方法 → 又去争抢 ClassA 锁； - 无超时、无中断、不释放已持锁：JVM 类初始化锁是 native 层 monitor，不响应 interrupt，也不支持 tryLock，一旦进入等待就彻底阻塞。
为什么叫“方法区全局”？
因为该锁作用于方法区中唯一的 Class 对象实例，而非堆内普通对象。所有线程共用同一份元数据，锁地址（如 0x00000000c001a8b8）在 jstack 中可被多个线程同时显示为 waiting to lock 或 locked，且指向同一个类名——这说明问题不在业务代码锁，而在 JVM 元空间层面的类生命周期管理机制本身。
典型故障表征
出现以下现象，基本可判定为该类死锁：
- jstack -l 输出中，多个线程堆栈均停留在
java.lang.ClassLoader.loadClass、java.lang.Class.forName或sun.misc.Unsafe.defineClass调用链上； - 线程状态为
BLOCKED或WAITING (on object monitor)，且锁地址两两成对循环（如线程A等0x123，线程B等0x456，而线程B又持有0x123，线程A又持有0x456）； - 高频出现在含大量嵌套静态类的库中（如 protobuf、gRPC、Lombok 注解处理器生成类），因其
<clinit></clinit>触发链深、顺序敏感； - 重启后偶发，压力测试下复现率陡增，且无法通过增加线程数缓解——本质是初始化时机竞争，非资源不足。
硬核修复路径
这不是加个 synchronized 就能解决的问题，需从加载契约、初始化解耦、监控前置三方面入手：
-
杜绝静态块跨类强依赖：将
new B()或B.xxx()移出<clinit></clinit>，改用懒加载代理或延迟初始化容器（如 Holder 模式）； -
自定义类加载器必须严守双亲委派：禁止重写
loadClass；构造时显式传入父加载器（如super(Thread.currentThread().getContextClassLoader())）； -
上线前注入初始化探针：用
Instrumentation.addTransformer拦截<clinit></clinit>，记录类加载顺序与耗时，提前暴露循环依赖风险点； -
生产环境配置 jvm 参数兜底：添加
-XX:+UnlockDiagnosticVMOptions -XX:+PrintClassHistogramAfterFullGC辅助定位，配合ThreadMXBean.findDeadlockedThreads()主动巡检。
