类加载死锁是JVM方法区层面的隐式锁闭环，由多线程并发触发A↔B循环静态依赖导致加锁阻塞；其锁以类全限定名为monitor、不可重入、无超时，jstack可见waiting to lock与locked地址成对循环，高频见于protobuf等嵌套静态类场景。

运行时由不当类加载机制引发的方法区全局类加载死锁，不是传统意义上的线程间互斥锁死锁，而是 JVM 在方法区（Metaspace）中对类初始化阶段施加的隐式同步所导致的阻塞闭环。它发生在多个线程并发触发彼此依赖的类初始化时，因 JVM 对每个类的 执行强制加锁，且锁粒度是“以类全限定名为 monitor”，一旦形成 A→B→A 的静态初始化依赖链，就会卡在类加载器的内部同步块里，所有相关线程永久 WAITING，整个应用挂起。

核心成因：类初始化锁 + 循环静态依赖

Java 规范要求：一个类首次被主动使用（如调用静态方法、访问静态字段等）时，若尚未初始化，JVM 必须先获取该类对应的 Class 对象锁，再执行其 方法。关键点在于：

• 锁不可重入但跨类不感知：线程1持有 ClassA 锁执行 ，期间调用 ClassB 的静态方法 → 触发 ClassB 初始化 → 尝试获取 ClassB 锁；
• 反向依赖即成闭环：若此时线程2正持有 ClassB 锁，并在其 中调用了 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 注解处理器生成类），因其 触发链深、顺序敏感；
• 重启后偶发，压力测试下复现率陡增，且无法通过增加线程数缓解——本质是初始化时机竞争，非资源不足。

硬核修复路径

这不是加个 synchronized 就能解决的问题，需从加载契约、初始化解耦、监控前置三方面入手：

• 杜绝静态块跨类强依赖：将 new B() 或 B.xxx() 移出 ，改用懒加载代理或延迟初始化容器（如 Holder 模式）；
• 自定义类加载器必须严守双亲委派：禁止重写 loadClass；构造时显式传入父加载器（如 super(Thread.currentThread().getContextClassLoader())）；
• 上线前注入初始化探针：用 Instrumentation.addTransformer 拦截 ，记录类加载顺序与耗时，提前暴露循环依赖风险点；
• 生产环境配置 jvm 参数兜底：添加 -XX:+UnlockDiagnosticVMOptions -XX:+PrintClassHistogramAfterFullGC 辅助定位，配合 ThreadMXBean.findDeadlockedThreads() 主动巡检。