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 块
静态块不是“兜住异常就安全”，而是“异常后继续访问未就绪类”才致命。必须剥离所有非原子、非确定性操作：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 禁止在
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")，不硬编码路径，防止因加载器不同导致资源不可见
规避匿名类与 Lambda 引发的隐式初始化
匿名内部类、Lambda 表达式、方法引用在字节码层面可能绑定外部类状态，若在 static 块中创建，会强制触发外部类完整初始化，极易形成闭环：
- 避免在
static{}中 new 匿名 Runnable、Thread 或使用()->{...} - 如需延迟执行，改用普通方法封装，或借助
AtomicReference+ 懒加载控制 - 方法引用（如
SomeClass::method）相对安全，因其不立即触发目标类初始化，但仍有风险，需结合实际字节码验证
