Java 类加载流程和双亲委派机制是什么？｜阿里巴巴后端开发面经解析

60 秒回答模板

Java 类加载是 JVM 把 class 字节码转成运行时可用类型的过程。整体可以分为加载、链接、初始化，链接内部又包含验证、准备、解析，所以面试里常说五个阶段：加载、验证、准备、解析、初始化。加载阶段根据类的全限定名获取二进制字节流，并在 JVM 中生成类的元数据和对应的 Class 对象；验证阶段保证字节码格式、语义和安全约束正确；准备阶段为类变量分配内存并设置默认零值；解析阶段把常量池里的符号引用转换为直接引用；初始化阶段执行类构造器 <clinit>，也就是静态变量显式赋值和 static 代码块。双亲委派是 ClassLoader 默认的查找策略：先检查类是否已经加载，未加载则把请求交给父加载器，父加载器再继续向上委派，直到 Bootstrap；如果父加载器都找不到，才由当前加载器自己尝试加载。这样能保证核心类库不被随意替换，也能避免同一个类被重复加载。需要补充的是，类的唯一性不是只看包名类名，还要看定义它的类加载器；并且双亲委派是默认模型，不是绝对强制，像 SPI、Tomcat、OSGi、插件化场景会通过线程上下文类加载器或 child-first 策略做扩展。

考点 整体生命周期

主线 加载阶段

易错点 把类加载阶段只背成五个名词，却说不出链接阶段内部的验证…

深入解析

整体生命周期

类加载不是一次性把所有类都加载进内存，而是通常在首次主动使用时按需发生。规范层面可以概括为加载、链接、初始化三大阶段，链接再细分为验证、准备、解析，因此面试常见答案是加载、验证、准备、解析、初始化。加载解决“找到字节码并创建运行时类型”的问题，链接解决“让类型进入 JVM 运行时状态并可被安全引用”的问题，初始化解决“执行静态初始化逻辑”的问题。后续还有使用和卸载，但它们通常不属于狭义类加载阶段。

加载阶段

加载阶段的核心是根据类的全限定名获取二进制字节流，输入可以是本地 class 文件、jar 包、网络、动态生成字节码等。JVM 会把这份字节流转换为方法区中的类元信息，并在堆上生成一个 java.lang.Class 对象，作为程序访问该类型元数据的入口。这里还要强调类身份：同一个全限定名的类，如果由不同类加载器定义，在 JVM 看来就是不同类型，这也是插件隔离、容器隔离能成立的基础，同时也解释了某些 ClassCastException 的来源。

验证阶段

验证是链接的第一步，目标是保证被加载的字节码不会破坏 JVM 的安全和运行时约束。它不只是检查文件开头魔数、版本号、常量池格式，还会检查元数据是否合法、继承关系是否正确、方法字节码是否满足栈帧和类型约束、符号引用是否具备访问权限等。验证的意义在于 Java 代码不一定来自可信编译器，甚至可能来自网络或字节码增强工具，因此 JVM 必须在运行前挡住非法或恶意字节码。

准备阶段

准备阶段为类变量，也就是 static 变量，在方法区相关运行时结构中分配存储并设置默认初始值。这里容易被答错：准备阶段不是执行 Java 代码里的显式赋值，例如 static int x = 10 在准备阶段通常先得到 0，真正赋值为 10 要等初始化阶段执行 <clinit>。但如果是编译期常量，例如 static final int 这类可在编译期确定的常量，可能在准备阶段就放入常量值。区分默认零值和显式赋值，是这道题的关键细节。

解析阶段

解析阶段把常量池中的符号引用替换为直接引用。符号引用可以理解为用字符串和描述符表示的目标，例如某个类、字段、方法或接口方法；直接引用则是 JVM 能够直接定位到目标的句柄、偏移量或内部指针。解析并不一定必须在初始化之前全部完成，JVM 可以选择提前解析，也可以在实际使用某个符号引用时再解析。这个弹性设计让虚拟机可以在启动速度、内存占用和运行期性能之间做实现层面的取舍。

初始化阶段

初始化阶段才真正执行类的静态初始化逻辑，JVM 会执行编译器生成的 <clinit> 方法，它由静态变量显式赋值语句和 static 代码块按源码顺序合并而成。触发初始化的典型场景包括 new 对象、读取或设置非编译期常量的 static 字段、调用 static 方法、反射主动使用类、初始化子类前先初始化父类等。初始化具有线程安全语义，同一个类的 <clinit> 在多线程场景下只会被一个线程执行，其他线程需要等待或看到初始化结果。

双亲委派流程

双亲委派描述的是 ClassLoader 查找类的默认流程。一次 loadClass 调用通常先检查当前加载器是否已经加载过这个类，如果没有，就把请求交给父加载器；父加载器继续向上交给自己的父加载器，最终到 Bootstrap ClassLoader。只有当父加载器无法找到目标类时，当前加载器才调用自己的查找逻辑。这个模型的重点不是“父加载器加载所有类”，而是“优先让更上层、更基础的加载器拥有加载机会”，从而形成稳定的类库边界。

模型价值

双亲委派最大的价值是安全性和一致性。安全性体现在核心类库不会轻易被应用侧同名类替换，例如用户自定义一个 java.lang.String 不应该覆盖 JDK 自带类；一致性体现在同一个基础类尽量由同一个上层加载器加载，避免运行时出现多个互不兼容的核心类型。它还降低了重复加载的概率，让类查找路径更可预测。面试中可以把它总结成三点：保护核心 API、避免重复定义、维持类身份稳定。

边界与例外

双亲委派是 Java ClassLoader 的默认推荐模型，但不是所有场景都严格按 parent-first 运行。典型例子是 JDBC、JNDI 等 SPI 场景，核心库需要反向发现应用 classpath 下的实现类，于是会使用线程上下文类加载器。Web 容器和插件系统也常做类加载隔离，例如每个应用使用独立加载器，甚至采用 child-first 来允许应用使用不同版本依赖。这里的取舍是：打破委派能换来隔离性和扩展性，但也会增加类冲突、泄漏和排查复杂度。

易错点

把类加载阶段只背成五个名词，却说不出链接阶段内部的验证、准备、解析分别解决什么问题。
误以为准备阶段会执行 static 赋值语句，混淆默认零值和初始化阶段的显式赋值。
把双亲委派里的父加载器理解成 Java 继承父类，没有说明它本质上是 ClassLoader 的 parent 链。
认为双亲委派绝对不能破坏，忽略 SPI、Web 容器、插件系统和线程上下文类加载器等实际场景。
只说类名相同就是同一个类，没有补充类加载器也是类型身份的一部分。
把解析阶段说成一定在初始化前全部完成，没有说明符号引用解析可能按需延迟发生。

面试官追问

哪些场景会触发类初始化？

典型主动使用会触发初始化，例如创建对象、读取或设置非编译期常量的静态字段、调用静态方法、通过反射主动使用类、初始化子类前先初始化父类、启动主类等。被动引用通常不会触发，比如通过子类引用父类静态字段时，可能只初始化父类而不初始化子类。

Class.forName 和 ClassLoader.loadClass 有什么区别？

常见区别是 Class.forName 默认会加载并初始化类，而 ClassLoader.loadClass 默认只完成加载，不一定触发初始化。工程上如果只是想拿到 Class 元数据或延迟初始化，loadClass 更适合；如果明确需要执行静态初始化逻辑，Class.forName 更直接。

为什么要有双亲委派机制？

双亲委派主要解决安全性、一致性和重复加载问题。它让核心类库优先由更上层加载器加载，避免应用侧伪造或覆盖 JDK 基础类；也让基础类型在进程内保持稳定来源，减少同名类被多处定义导致的类型不兼容。

双亲委派可以被打破吗？

可以。ClassLoader 的默认 loadClass 实现遵循 parent-first，但自定义加载器可以重写加载逻辑，线程上下文类加载器也能让父层代码发现子层实现。打破委派常见于 SPI、Web 容器、模块化和插件化系统，但代价是类冲突和排查复杂度上升。

为什么两个同名类不能互相强转？

因为 JVM 判断类型身份时同时看类的全限定名和定义它的类加载器。即使字节码完全相同，只要由不同类加载器定义，也会被视为两个不同类型。此时对象强转到另一个加载器定义的同名类型，可能抛出 ClassCastException。

卸载类需要满足什么条件？

类卸载通常要求定义该类的 ClassLoader 可以被回收，并且该类的 Class 对象、实例对象、静态字段引用等都不再可达。实际工程中 Web 应用热部署后的内存泄漏，常常就是线程、静态缓存或 ThreadLocal 持有应用类加载器导致卸载失败。