Wong Kosheng在校招面试和日常 JVM 排障里，“Class 文件的加载机制”属于被问得最多、但很多人答得最浅的知识点。多数人能说出“加载、验证、准备、解析、初始化”这几个阶段，也能背出“双亲委派”四个字，可一旦追问到“准备阶段到底做了什么”“为什么 NoClassDefFoundError 和 ClassNotFoundException 不一样”“什么情况下一个类会重复加载”，现场就会卡住。
这篇内容我用十几年的排查经验把它掰开来讲，先说清楚 JVM 加载 Class 文件的完整链路，再深入类加载器的设计逻辑，最后给出一套能直接用于分析和排查的命令、参数、自定义加载器骨架。不管你是准备面试，还是真的要解决生产环境的类冲突问题，读完都应该有自己的排查框架。
1. 类的“一生”：先搞清楚这个机制到底管哪些事
1.1 加载、连接、初始化不是一回事
JVM 加载 Class 文件，官方规范把它拆成三大块：加载（Loading）、连接（Linking）、初始化（Initialization）。而连接又细分为验证（Verification）、准备（Preparation）、解析（Resolution）。因此你常听到的“五个阶段”，准确说是一个加载阶段加三个连接子阶段再加一个初始化阶段。
很多人把“加载”理解成“把 Class 读进来”，这不算错，但不完整。加载阶段真正做的事是：通过类的全限定名找到对应的 .class 字节流，把字节流里的静态存储结构转换成方法区里的运行时数据结构，然后在堆中生成一个代表这个类的 java.lang.Class 对象。加载完成之后，这个类还没有进入可用状态，因为字节码格式是否正确、语义是否安全，都还没确认。
接下来的验证阶段，就是干“安检”的活。JVM 要对字节流做四轮检查：文件格式验证、元数据验证、字节码验证、符号引用验证。文件格式验证保证魔数是 0xCAFEBABE、主次版本号能被当前 JVM 接受，元数据验证检查类是否有父类、是否继承了被 final 修饰的类这类语义问题。字节码验证是整个验证阶段最耗时的部分，它通过数据流分析确认操作数栈类型、局部变量类型不会在运行时出现安全问题，比如不把一个 Object 直接当成 String 强转。
验证通过之后进入准备阶段。准备阶段是为类变量（static 修饰的字段）分配内存并设置零值。注意，这里的“零值”不是程序里写的初始值，而是各类型的默认值，比如 int 是 0，boolean 是 false，引用类型是 null。真正执行赋值语句里的初始化动作，要等初始化阶段。
解析阶段是把常量池里的符号引用替换为直接引用的过程。符号引用就是一个字面量，比如 com/example/User 这种，它不指向实际内存；直接引用才是指向目标在内存中的位置。解析可以发生在类被激活后的任意时刻，HotSpot 虚拟机默认采用懒解析策略，也就是某个符号引用第一次被用到的时候才去解析，不一定非要等初始化前全部做完。
最后一个阶段才是初始化。这个阶段才真正执行类构造器 <clinit>() 方法，它会收集所有静态变量的赋值语句和静态代码块，按源码顺序合并执行。一个类是否被初始化，是判断它有没有被“真正激活”的关键标志。关于哪些场景会触发初始化，我放到后面单独说，这里先记住一个结论：加载、连接可以由 JVM 自主控制时机，但初始化必须在“主动使用”类时才触发。
1.2 类什么时候才加载？不是启动就全部加载
这是我面试时最愿意追问的点。很多人以为 JVM 启动会把 classpath 下所有类一次性读进来，这是典型误解。JVM 用的是懒加载策略，类只有在“第一次被主动使用时”才会触发加载和初始化。
哪些行为算主动使用？有且仅有六种：创建类的实例；访问类的静态变量（不包括被编译期常量折叠的静态常量）；调用类的静态方法；通过反射执行 Class.forName()，并且参数 initialize 为 true；初始化一个类的子类（父类会先被初始化）；作为 JVM 启动入口的类（也就是含 main 方法的那个类）。
这个机制看起来简单，实际坑很多。举个最常见的例子，你写：
java复制public class Test {
static {
System.out.println("Test 被初始化了");
}
public static final String NAME = "zhang3";
public static String randomStr() {
return "hello";
}
}
如果你在别的类里访问 Test.NAME，JVM 根本不会触发 Test 的初始化。因为 NAME 是编译期常量，Java 编译器在编译调用方时就把字符串 "zhang3" 直接内联到了常量池里，运行期根本不需要加载 Test。但如果你访问 Test.randomStr() 或直接 new Test()，则一定会触发初始化。这就是为什么你改一个类的静态常量、重启应用后却没看到效果，往往是因为调用方早把常量值“写死”编译进自己的字节码了。
还有一个容易忽略的点：定义数组的引用不会触发元素类初始化。比如你写 Test[] tests = new Test[0]，这行代码只会创建一个数组类，它由 JVM 直接生成，不会触发 Test 的加载和初始化。这个机制在写框架、做插件系统时很有用，可以通过创建空数组来探测某个类是否可加载，而不用真的初始化它。
1.3 类加载完存在哪：堆和元空间要分清
关于类加载完之后的存储位置，是我见过混淆最多的地方。每次加载完成后，JVM 会在堆中创建一个 java.lang.Class 对象，这个对象是外部能通过“对象.getClass()”拿到的入口。但它背后的类元数据——字段、方法、接口、常量池、注解信息等，存放在方法区中。
Java 8 之前方法区的实现叫永久代（PermGen），Java 8 以后改名为元空间（Metaspace）。二者最大的区别是元空间不再使用 JVM 堆内存，而是使用本地内存，默认情况下只受可用系统内存限制。这个变动的直接后果就是：以前常见的 java.lang.OutOfMemoryError: PermGen space 变成了 Metaspace。如果你遇到的是后者，通常就是自定义类加载器把类无节制地加载进来，又没能及时回收，导致本地内存被元数据占满。
想观察当前加载的类存放在哪个区域，可以用 jcmd 或者 JFR 抓元空间信息，但更简单的思路是理解一个基础判断：类元数据不是普通 Java 对象，不要用堆大小去估算它，它是 JVM 用 native memory 管理的一部分。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 双亲委派模型：为什么不能谁加载到就归谁
2.1 三种内置加载器，Java 版本差异要分清
类加载器本身是 Java 对象，它的职责只有一个：通过类的全限定名找到字节流，然后把字节流转换成 JVM 中的 Class 对象。JDK 内置了三层相互协作的类加载器，但它们在不同 JDK 版本下的叫法和职责有差异。
先看 Java 8 及之前：启动类加载器（Bootstrap ClassLoader）负责加载 JAVA_HOME/lib 下的核心类库，比如 rt.jar、tools.jar 里的大部分类，它由 C++ 实现，在 Java 代码中拿不到引用，显示为 null；扩展类加载器（Extension ClassLoader）负责加载 `JAVA_HOME/l