类加载过程本身不会直接导致线程死锁，但自定义类加载器设计不当可能因隐式锁竞争、双亲委派缺陷或变量不可见引发“类加载锁死锁”；需从锁行为、类加载路径、变量可见性三方面排查修复。
类加载过程本身不会直接导致线程死锁，但自定义类加载器若设计不当，可能在多线程并发加载时触发隐式锁竞争，进而引发“类加载锁死锁”——这不是 JVM 规范定义的标准死锁，而是因 ClassLoader.loadClass 内部同步、双亲委派链路阻塞、或静态初始化器（<clinit></clinit>）互相依赖所诱发的线程挂起现象。排查和解决需聚焦三个层面：锁行为、类加载路径、变量可见性。
一、识别类加载阶段的隐式锁竞争
JVM 对每个类的首次加载会加锁（以类的全限定名作 monitor），确保同一类只被一个线程成功定义。若多个线程同时尝试加载尚未初始化的类，且该类的 <clinit></clinit> 块中又调用了其他未初始化类的方法，就可能形成锁等待闭环。
- 用
jstack <pid></pid>检查线程栈，重点关注处于java.lang.ClassLoader.loadClass或java.lang.Class.forName调用链中、状态为BLOCKED或WAITING的线程 - 搜索关键词：
waiting to lock 和 <code>locked ，比对锁地址是否成对出现循环引用 - 特别注意 protobuf 类等含大量嵌套静态内部类的场景——它们的
<clinit></clinit>往往顺序触发，极易因加载顺序不一致引发阻塞
二、修复自定义类加载器的双亲委派缺陷
多数“加载失败+疑似死锁”问题，根源在于自定义类加载器未正确设置父加载器，导致重复加载、类隔离失败或符号引用解析异常。
- 构造时必须显式传入父加载器，例如：
super(ClassLoader.getSystemClassLoader())；否则默认父为null，跳过系统类加载器，造成ClassNotFoundException（如找不到java.lang.Object或 protobuf 生成类依赖的基类） - 仅重写
findClass(String)，不要重写loadClass(String)—— 否则绕过双亲委派，破坏类一致性，引发LinkageError或运行时ClassCastException - 在
findClass中，先检查findLoadedClass(name)，避免重复 define；再读取字节码，最后调用defineClass(name, bytes, 0, bytes.length)
三、解决自定义加载器中变量/资源不可见问题
所谓“变量加载问题”，通常指通过自定义加载器加载的类，其静态字段、配置参数或外部资源（如 protobuf descriptor）在运行时无法正确获取，本质是类隔离或初始化时机错误。
- 确认资源路径是否随类加载器变化：用
this.getClass().getClassLoader().getResource("xxx.proto")替代硬编码路径，避免因类加载器不同导致getResource返回null - protobuf 类若由自定义加载器加载，其内部
getDescriptor()所依赖的com.google.protobuf.Descriptors$FileDescriptor必须由同一类加载器（或其父加载器）提供；否则抛出NoClassDefFoundError或空 descriptor - 避免在静态块中直接 new 其他由不同加载器加载的类；改用反射 + 显式指定类加载器：
Class.forName("X", true, yourClassLoader)
不复杂但容易忽略：类加载不是纯函数调用，它牵扯锁、内存可见性、静态初始化顺序和加载器命名空间。一次正确的自定义加载器，核心就三点——设对父加载器、只动 findClass、资源访问走当前加载器上下文。
