Nicholas Qin1. 为什么面试官总爱问类加载：先搞懂它解决了什么问题
如果你准备过 Java 面试，八成会遇到“你了解 Java 的类加载器吗”这个问题。它不是单纯的八股文考点，而是检验你对 Java 运行时机制理解深度的试金石。我当年面试时被问到“双亲委派机制为什么能避免类重复加载”，一开始也是背概念，后来真正读了 HotSpot 源码、动手写过自定义类加载器，才明白这套设计背后的精妙之处。
先说结论：类加载机制解决的是“Java 类从哪来、怎么变成可执行代码、由谁说了算”这三个问题。 Java 程序跑起来的第一步，不是执行 main 方法，而是由类加载器（ClassLoader）把 .class 字节码文件加载进 JVM，经过一系列处理后变成 Class 对象，才能被后续的 new、反射、方法调用等操作使用。
类加载器本身是一个对象，它实现了“按名称查找类或接口的二进制字节流”的能力。每个类加载器都管理着自己负责的那部分类加载行为，JVM 启动时默认会创建三到四个内置类加载器，共同协作完成类搜索与加载工作。
这里有个大多数新手都忽略的点：类加载不是一次性把所有类都读进内存，而是按需加载。 也就是说，JVM 在运行过程中只有当某个类第一次被主动使用时，才会触发类加载。这个“按需”的设计直接决定了后边要讲的双亲委派机制存在的意义——JVM 需要在运行时动态决定“找谁要这个类”。
而且类加载器不只是面试题，工作中也会频繁遇到相关问题。比如部署 Web 应用时遇到 ClassNotFoundException 或 NoSuchMethodError，排查思路的核心就是类加载器隔离问题；写 SPI 框架时用 Thread contextClassLoader 绕过双亲委派限制；做热部署和热替换方案时自定义类加载器管理新旧版本的类。懂了类加载机制，这些实操问题你才能做到“遇到不慌，能按套路排查”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. JVM 内置的三大类加载器：各自管什么、边界在哪
2.1 Bootstrap ClassLoader：JVM 的根，用 C++ 写的那个
启动类加载器（Bootstrap ClassLoader）是类加载体系的最顶层。它负责加载 JDK 核心类库，最典型的是 <JAVA_HOME>/jre/lib/rt.jar 里的内容——java.lang、java.util、java.io 等最基础、最重要的包，都在它的管辖范围内。
它的特殊之处在于：它不是由 Java 代码实现的，而是 JVM 的一部分（HotSpot 里由 C++ 编写），因此在 Java 层面拿不到它的实例。 你在代码里写 String.class.getClassLoader()，得到的是 null，这不是 String 没有类加载器，而是它的加载器是启动类加载器，Java 层面对它“不可见”，所以返回 null 表示“由 Bootstrap 加载”。
这个设计有两个直接后果。第一，核心类库不能被 Java 程序员自定义覆盖（除非用极端手段），保证了 JDK 基础类型的一致性。第二，所有类加载器最终都要把请求委派给它，它是递归链条的终点。
2.2 Extension ClassLoader：加载扩展包的中间层
扩展类加载器（Extension ClassLoader）负责加载 <JAVA_HOME>/jre/lib/ext 目录下或系统变量 java.ext.dirs 指定目录下的类。它是 Java 层实现的，在 HotSpot 中它是 sun.misc.Launcher$ExtClassLoader，父加载器理论上指向 Bootstrap（但由于 Bootstrap 不是 Java 对象，它的 parent 字段实际为 null，逻辑上归 Bootstrap 管）。
JDK 9 之后，这个目录机制变成了模块化机制（jmods），扩展类加载器被平台类加载器（Platform ClassLoader）取代，职责类似。不过面试时绝大多数考官还在用 JDK 8 以下的概念问答，所以回答时可以把“JDK 8 及以前是 Extension，JDK 9 之后是 Platform”这个演进一并提出来，能体现你真的读过新版文档。
实践里我们很少直接依赖 ExtClassLoader，但它作为“中间层”的存在让整个委派链条形成了“根 → 扩展 → 应用”的三级结构。如果某天你发现某个 jar 放在 ext 目录下能被全局可见，而放在 classpath 里反而不行，那就能立刻想到是这两个加载器的管辖范围差异造成的。
2.3 App ClassLoader：平时最常接触的应用类加载器
系统类加载器（Application ClassLoader，也叫 App ClassLoader）负责加载 classpath（环境变量 CLASSPATH 指定的路径或 -classpath/-cp 参数指定的路径）上的所有类。平时我们写的业务代码，默认都是由它来加载的。
它是 sun.misc.Launcher$AppClassLoader 的实例。我们调用 ClassLoader.getSystemClassLoader() 拿到的就是它。它的 parent 加载器是 ExtClassLoader，这一点非常重要，因为在双亲委派机制中，AppClassLoader 接收到加载请求后，会先把请求交给 ExtClassLoader，然后再交到 Bootstrap，逐级向上委派。
这三种加载器的层级关系可以概括为：AppClassLoader 的父加载器是 ExtClassLoader，ExtClassLoader 的父加载器是 Bootstrap（逻辑上）。 它们构成了 JVM 默认的委派链。面试时画这条链（文字描述即可，比如“应用加载器向上委派给扩展加载器，再向上委派给启动加载器”）是最常见的考察点之一。
2.4 类加载器不是“继承”关系，是“组合”关系
这里必须澄清一个高频误解。很多人以为 AppClassLoader 继承 ExtClassLoader，ExtClassLoader 继承 Bootstrap，这是错的。
类加载器之间的层级关系不是通过 Java 的继承实现，而是通过每个类加载器内部的 parent 字段关联起来的。 ClassLoader 类有一个 private final ClassLoader parent 字段，用来记录“我的上级是谁”。AppClassLoader 创建时传入了 ExtClassLoader 实例作为 parent，而 ExtClassLoader 的逻辑父级是 Bootstrap。代码上它们都是 ClassLoader 的子类实例，但彼此是组合关系，不是继承关系。
搞清楚这一点，你才能理解为什么可以人为地“破坏”双亲委派——因为 parent 是一个普通的 Java 字段，自定义类加载器时完全可以选择不调用 super.loadClass()，不去委派，自己定义加载逻辑。
3. 类加载机制的完整流程分解：五个阶段各干了什么
类从磁盘上的 .class 文件到变成 JVM 里可用的 Class 对象，一共经历五个阶段：加载、验证、准备、解析、初始化。面试时多数人只能说出名字，但每个阶段具体做了什么、哪些阶段可以被延迟到运行期，能讲清楚的人不多。我带大家逐段过一遍。
3.1 加载：把字节流变成 Class 对象（这是唯一与类加载器直接相关的一步）
加载是“获取类的二进制字节流并在 JVM 中生成 Class 对象”的过程。它有三个关键动作：
- 通过类的全限定名获取定义此类的二进制字节流。这个“获取”不一定是从 .class 文件读，也可以从 ZIP/JAR 包、网络、动态代理运行时生成、数据库等任何来源。
- 将字节流所代表的静态存储结构转化为方法区的运行时数据结构。
- 在堆内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。
加载阶段是类加载器直接参与