java类加载本身不直接引发死锁，但多线程并发初始化时因静态块互依赖、自定义加载器失当或资源顺序混乱，可能陷入jvm级初始化锁闭环，表现为线程卡在且状态为runnable。
Java 中类加载本身不会主动制造死锁，但 JVM 对每个类的首次初始化（<clinit></clinit>）加了隐式锁，多线程并发触发互相依赖的类初始化时，极易形成“类初始化死锁”——线程 A 卡在 A.<clinit></clinit> 等 B 初始化，线程 B 卡在 B.<clinit></clinit> 等 A 初始化。这不是普通业务锁死锁，而是 JVM 规范强制的串行化机制与循环依赖共同导致的挂起。
避免静态初始化块中的跨类调用
这是最常见、最直接的诱因。只要 A 的 static{} 里调用了 B 的方法或访问了 B 的非编译期常量静态字段，而 B 又反过来依赖 A，就可能卡住。
- 不要在静态块中调用外部类的同步方法、日志工厂（如
Logger.getLogger()）、工具类（如Objects.requireNonNull()），它们可能间接触发其他类初始化 - 禁止写
static final int X = B.Y + 1;这类表达式，除非确认 B 完全不引用 A；若必须依赖，改用运行时计算 - 把静态资源初始化逻辑移到首次使用时（如单例的 getInstance() 方法内），用双重检查锁或
Holder模式延迟执行
确保自定义类加载器不破坏双亲委派
加载器设计不当会导致同一类被不同加载器多次加载，或关键父类（如 java.lang.Object、com.google.protobuf.GeneratedMessageV3）找不到，进而使 <clinit></clinit> 执行异常中断或反复重试，加剧锁竞争。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 构造自定义加载器时，必须显式传入父加载器：
super(ClassLoader.getSystemClassLoader())，不能留空或传null - 只重写
findClass(String)，不要重写loadClass(String)；否则绕过双亲委派，引发LinkageError或隐式加载冲突 - 在
findClass中，先调用findLoadedClass(name)检查是否已加载，避免重复 define
用 jstack 快速定位初始化锁等待链
不靠猜，靠证据。类初始化死锁在线程栈中特征鲜明：两个或多个线程都停在 <clinit></clinit>，且堆栈中交叉出现对方类名。
- 执行
jstack -l <pid></pid>获取完整线程快照 - 搜索关键词：
java.lang.Class.forName、at .*<clinit></clinit>、waiting to lock 、<code>locked - 重点看 BLOCKED 线程的堆栈顶部：线程 1 显示
A.<clinit> ... at B.test()</clinit>，线程 2 显示B.<clinit> ... at A.SOME_FIELD</clinit>→ 基本可判定为初始化循环依赖
对 protobuf 等嵌套静态类场景特别谨慎
Protobuf 生成类通常含大量静态内部类，其 <clinit></clinit> 会按字节码顺序依次触发，不同线程加载顺序稍有差异，就容易因锁抢占不一致造成阻塞。
- 避免在启动阶段并发调用多个 Protobuf 类的
getDefaultInstance()或反射访问其字段 - 统一在应用初始化早期，用单线程预加载关键 Protobuf 类（如
Class.forName("xxx.MyProto$Message")），让所有<clinit></clinit>在一个线程内完成 - 检查 proto 文件是否引入了不必要的跨文件依赖，减少生成类之间的隐式关联
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
