Java类加载问题需按五阶段定位：加载（ClassNotFoundException）、链接（NoClassDefFoundError、LinkageError）、初始化（ExceptionInInitializerError）；查路径、类加载器、资源位置；双亲委派可打破但须有明确理由；初始化受七种主动使用规则约束。
Java 类加载不是靠“百问百答教程”来解的，而是靠理解它的阶段逻辑、加载器协作关系和触发时机。所谓“百问百答”，本质是把常见现象（如 ClassNotFoundException、NoClassDefFoundError、热部署失败、SPI 不生效）还原到类加载生命周期中去定位——问题不在答案数量，而在能否准确映射到加载、验证、准备、解析、初始化这五个关键环节。
下面直击核心，分四块讲清楚怎么真正“解”：
类加载出问题，先看处在哪个阶段
大部分报错都能按阶段归因：
-
java.lang.ClassNotFoundException：发生在加载阶段，类加载器根本没找到.class字节流（路径错、包名错、资源未打包、ClassLoader 用错） -
java.lang.NoClassDefFoundError：发生在初始化或使用阶段，说明类曾成功加载过，但后续因依赖类缺失、静态块抛异常、或被卸载导致无法链接 -
java.lang.ExceptionInInitializerError：卡在初始化阶段，<clinit>方法执行失败（比如静态字段赋值时 NPE、IO 异常） -
LinkageError（如IncompatibleClassChangeError）：多出现在解析或初始化后，通常是同一类被不同类加载器重复定义，或字节码版本/签名不兼容
找不到类？重点查三件事
不是代码写错，而是加载路径断了：
立即学习“Java免费学习笔记（深入）”；
- 检查
getResourceAsStream("xxx.class")或Class.forName("pkg.Clz")的参数是否带.class后缀（forName用全限定名，不含.class；getResourceAsStream用路径，含/不含.class） - 确认当前线程上下文类加载器（
Thread.currentThread().getContextClassLoader()）是否与你预期的一致（尤其在 Tomcat、Spring Boot、Dubbo 中，它常被显式切换） - 验证资源是否真在 classpath 下：用
ClassLoader.getSystemResource("xxx.class")打印 URL，看路径是否指向 JAR 包内、classes 目录，还是 null
双亲委派不是铁律，打破它要有明确理由
别为了“自定义”而自定义：
- 热部署（如 JRebel）、模块隔离（OSGi）、SPI 扩展点（
META-INF/services/xxx）才需要绕过委派 - 打破方式只有三种标准做法：重写
loadClass()（跳过parent.loadClass()）、重写findClass()（只负责字节码获取）、或设置线程上下文类加载器（TCCL） - 错误示范：在
findClass里又调用super.loadClass()—— 这等于没打破，还可能引发死循环
初始化不是“一劳永逸”，它受主动使用规则约束
一个类可以加载成功，但长期不初始化：
- 触发初始化的七种主动使用场景包括：
new实例、读写静态字段（非 final）、调用静态方法、反射、初始化子类（父类先）、JVM 启动主类、java.lang.invoke.MethodHandle解析 -
final static基本类型常量（如public static final int VAL = 1;）在准备阶段就直接赋值，不走初始化，所以不会触发<clinit> - 子类引用父类静态字段，若该字段为编译期常量，则不会触发父类初始化（这是常被忽略的细节）
不复杂，但容易忽略。
