Java 中如何解决类加载过程里的死锁问题

作者：袖梨 2026-07-12

Java类加载本身不直接引发死锁，但多线程并发初始化时因静态块互依赖、自定义加载器失当或资源顺序混乱，可能陷入JVM级初始化锁闭环，表现为线程卡在<clinit>且状态为RUNNABLE。

Java 类加载过程本身不直接引发死锁，但多线程并发触发类初始化时，若存在静态块互相依赖、自定义加载器设计失当或资源加载顺序混乱，就可能陷入 JVM 级别的类初始化锁等待闭环——表现为线程卡在 <clinit>、状态为 RUNNABLE 却无进展。解决关键不在“加锁”，而在切断隐式依赖链、控制初始化时机、保障加载路径一致。

识别死锁信号：看线程栈和锁地址

用 jstack -l <pid> 抓取线程快照，重点关注：

线程堆栈中是否连续出现多个 <clinit> 调用，例如 A.<clinit> → B.<clinit> → A.<clinit>
是否存在 waiting to lock <0x...> 和 locked <0x...> 成对出现且地址循环引用
阻塞点是否落在 Class.forName、ClassLoader.loadClass 或静态字段访问上
避免依赖日志框架打点——其自身 logger 可能正卡在初始化竞争中；改用 System.err.println 输出明确断点

切断静态初始化闭环：重构高危 static 块

静态块不是“兜住异常就安全”，而是“异常后继续访问未就绪类”才致命。必须剥离所有非原子、非确定性操作：

禁止在 static{} 中读取配置文件、环境变量、系统属性（IO 不稳定）
禁止发起网络请求、连接数据库、调用远程服务
禁止解析 JSON/XML、反序列化外部数据
禁止直接调用其他类的 static 方法（尤其该方法内部含 new、IO 或依赖注入）
改用 Holder 模式延迟初始化：private static class Holder { static final Service INSTANCE = new Service(); }，首次访问 Holder.INSTANCE 才触发
或封装为显式 init() 方法，由调用方控制重试、降级与告警

规范自定义类加载器行为

多数“加载失败+疑似死锁”源于加载器破坏双亲委派或锁管理失控：

立即学习“Java免费学习笔记（深入）”；

构造时必须显式传入父加载器：super(ClassLoader.getSystemClassLoader())，否则父为 null，导致 ClassNotFoundException（如找不到 java.lang.Object）
只重写 findClass(String)，不要重写 loadClass(String)——绕过双亲委派会引发 LinkageError 或 ClassCastException
在 findClass 中先调用 findLoadedClass(name) 避免重复 define，再读字节码，最后调用 defineClass(name, bytes, 0, bytes.length)
资源加载统一用 this.getClass().getClassLoader().getResource("xxx")，不硬编码路径，防止因加载器不同导致资源不可见