Java 类初始化死锁分析报告(1)

发表于 分类于

概述

本文档分析了三种Java类初始化死锁案例的堆栈输出，定位了死锁发生的具体位置和原因。

1. 案例x1: 父子类初始化死锁

死锁模式

  • 线程A: 初始化Parent类 (ParentInitThread)
  • 线程B: 初始化Child类 (ChildInitThread)

死锁位置

Parent类第17行: CHILD = new Child();

// Parent类的静态初始化块
static {
    System.out.println(Thread.currentThread().getName() + ": 开始初始化Parent类");
    Thread.sleep(100);
    CHILD = new Child();  // ← 死锁点！需要初始化Child类
}

Child类第34行: int value = Parent.getStaticValue();

// Child类的静态初始化块
static {
    System.out.println(Thread.currentThread().getName() + ": 开始初始化Child类");
    Thread.sleep(50);
    int value = Parent.getStaticValue();  // ← 需要访问Parent类的静态方法
}

死锁原因

  1. 线程A获得Parent类的初始化锁（<clinit>）
  2. 线程B获得Child类的初始化锁（<clinit>）
  3. 线程A需要初始化Child（new Child()）→ 等待Child类的初始化锁
  4. 线程B需要访问Parent的静态方法（Parent.getStaticValue()）→ 等待Parent类的初始化锁
  5. 结果: 循环等待，死锁发生

堆栈证据

"ParentInitThread" #18 prio=5 os_prio=0 tid=0x00007f712c191000 nid=0x33251 in Object.wait()
    java.lang.Thread.State: RUNNABLE
    at demo.thread.deadlock.classinit.DeadlockParentChildDemo$Parent.<clinit>(DeadlockParentChildDemo.java:17)  ← 死锁点

"ChildInitThread" #19 prio=5 os_prio=0 tid=0x00007f712c193000 nid=0x33252 in Object.wait()
    java.lang.Thread.State: RUNNABLE  
    at demo.thread.deadlock.classinit.DeadlockParentChildDemo.lambda$demonstrateDeadlock$1(DeadlockParentChildDemo.java:62)
    at demo.thread.deadlock.classinit.DeadlockParentChildDemo$$Lambda$2/135721597.run(Unknown Source)

三重堆栈输出结果

  1. Java API堆栈: 86行，Java标准API检测不到此类死锁
  2. jstack堆栈: 140行，显示线程RUNNABLE状态，但实际在等待类初始化锁
  3. gstack堆栈: 633行，87.8KB，显示系统级等待状态

2. 案例x2: 循环依赖初始化死锁

死锁模式

  • 线程A: 初始化ClassA (ClassAInitThread)
  • 线程B: 初始化ClassB (ClassBInitThread)

死锁位置

ClassA类第17行: int value = ClassB.getStaticValue();

ClassB类第17行: int value = ClassA.getStaticValue();

死锁原因

  1. 线程A获得ClassA的初始化锁
  2. 线程B获得ClassB的初始化锁
  3. 线程A需要访问ClassB的静态方法 → 等待ClassB的初始化锁
  4. 线程B需要访问ClassA的静态方法 → 等待ClassA的初始化锁
  5. 结果: 对称循环等待

堆栈证据

"ClassAInitThread" #18 prio=5 os_prio=0 tid=0x00007f5b2c17b800 nid=0x342b0 in Object.wait()
    java.lang.Thread.State: RUNNABLE
    at demo.thread.deadlock.classinit.DeadlockCircularDependencyDemo$ClassA.<clinit>(DeadlockCircularDependencyDemo.java:17)

"ClassBInitThread" #19 prio=5 os_prio=0 tid=0x00007f5b2c17d800 nid=0x342b1 in Object.wait()
    java.lang.Thread.State: RUNNABLE
    at demo.thread.deadlock.classinit.DeadlockCircularDependencyDemo$ClassB.<clinit>(DeadlockCircularDependencyDemo.java:34)

三重堆栈输出结果

  1. Java API堆栈: 95行
  2. jstack堆栈: 148行
  3. gstack堆栈: 649行，90.1KB

3. 案例x3: 静态内部类初始化死锁

死锁模式

  • 线程A: 初始化OuterClass (OuterClassInitThread)
  • 线程B: 初始化StaticInnerClass (InnerClassInitThread)

死锁位置

OuterClass类第19行: int value = StaticInnerClass.getStaticValue();

StaticInnerClass类第15行: int value = OuterClass.getStaticValue();

死锁原因

  1. 线程A获得OuterClass的初始化锁
  2. 线程B获得StaticInnerClass的初始化锁
  3. 线程A需要访问内部类的静态方法 → 等待内部类的初始化锁
  4. 线程B需要访问外部类的静态方法 → 等待外部类的初始化锁
  5. 结果: 内外类循环等待

堆栈证据

"OuterClassInitThread" #18 prio=5 os_prio=0 tid=0x00007faa6c186000 nid=0x34cbc in Object.wait()
    java.lang.Thread.State: RUNNABLE
    at demo.thread.deadlock.classinit.DeadlockStaticInnerClassDemo$OuterClass.<clinit>(DeadlockStaticInnerClassDemo.java:19)

"InnerClassInitThread" #19 prio=5 os_prio=0 tid=0x00007faa6c188000 nid=0x34cbd in Object.wait()
    java.lang.Thread.State: RUNNABLE
    at demo.thread.deadlock.classinit.DeadlockStaticInnerClassDemo$OuterClass$StaticInnerClass.<clinit>(DeadlockStaticInnerClassDemo.java:44)

三重堆栈输出结果

  1. Java API堆栈: 87行
  2. jstack堆栈: 141行
  3. gstack堆栈: 630行，87.5KB

技术分析

1. 类初始化锁机制

  • JVM为每个类维护一个初始化锁（<clinit>）
  • 锁在类初始化期间被持有
  • 多个线程同时初始化互相依赖的类时，可能导致死锁

2. Java标准死锁检测的局限性

=== 死锁检测 ===
Java API未检测到标准死锁
注：类初始化死锁可能不被Java标准死锁检测机制识别

原因:

  • Java的ThreadMXBean.findDeadlockedThreads()只检测对象锁死锁
  • 类初始化锁是JVM内部机制，不在标准死锁检测范围内

3. 三重堆栈分析对比

分析层面 工具 定位能力 信息深度
应用层 Java API 显示线程状态为RUNNABLE Java应用级别，看不到类初始化锁
JVM层 jstack 显示RUNNABLE状态，<clinit>方法 能看到Java字节码层面的类初始化
系统层 gstack 显示系统级等待状态 C/C++层面，能看到JVM内部锁机制

4. gstack的系统级洞察

#7  0x00007f713471dc37 in os::PlatformEvent::park(long) [...]  ← JVM内部park
#8  0x00007f713470e60d in ObjectMonitor::wait(...)  ← 对象监视器等待
#9  0x00007f7134503582 in JVM_MonitorWait ()  ← JVM的MonitorWait调用

关键发现:

  • gstack显示线程实际上在ObjectMonitor::wait()中等待
  • 这与jstack显示的RUNNABLE状态不同
  • 证明类初始化锁是JVM内部的对象监视器

问题定位总结

死锁识别模式

  1. 查找<clinit>方法: 死锁线程堆栈顶都有<clinit>方法调用
  2. 分析依赖关系: 查看哪个类的初始化需要访问另一个类
  3. 检查访问点: 定位到具体的静态方法调用或类实例化语句

高风险代码模式

// 危险模式：类A的静态初始化依赖类B
static {
    // 访问其他类的静态成员
    ClassB.someStaticMethod();
}

// 危险模式：类B的静态初始化依赖类A  
static {
    // 访问其他类的静态成员
    ClassA.someStaticMethod();
}

解决方案建议

  1. 避免循环静态初始化依赖
  2. 将静态依赖移到实例方法中
  3. 使用延迟初始化模式
  4. 同步静态初始化块

工具使用建议

1. 快速定位

# 查找死锁线程
grep -n "InitThread\|<clinit>" /tmp/x1.jstack.txt

# 查看关键行号
grep -o "\.java:[0-9]*)" /tmp/x1.jstack.txt | head -5

2. 深度分析

# 对比三个工具的输出
diff /tmp/x1.api.threadstack.txt /tmp/x2.api.threadstack.txt

# 查看gstack的JVM内部调用
grep "libjvm\|JVM_" /tmp/x1.gstack.txt | head -10

3. 自动化检测脚本

建议创建自动化脚本，在死锁发生时自动：

  1. 执行三重堆栈转储
  2. 分析死锁模式
  3. 生成分析报告
  4. 提供解决方案建议

结论

  1. 类初始化死锁是JVM内部锁机制导致的，Java标准工具无法直接检测
  2. 三重堆栈分析是诊断关键：Java API + jstack + gstack互补
  3. 死锁模式可预测：避免类初始化期间的交叉静态依赖
  4. gstack提供系统级洞察：显示JVM内部的实际等待状态

核心发现: 类初始化锁是ObjectMonitor的实现，在<clinit>方法期间被持有，形成特殊的死锁场景。