Java类加载机制与双亲委派模型：从原理到自定义ClassLoader实践

1. 为什么面试官总爱问类加载：先搞懂它解决了什么问题

如果你准备过 Java 面试，八成会遇到“你了解 Java 的类加载器吗”这个问题。它不是单纯的八股文考点，而是检验你对 Java 运行时机制理解深度的试金石。我当年面试时被问到“双亲委派机制为什么能避免类重复加载”，一开始也是背概念，后来真正读了 HotSpot 源码、动手写过自定义类加载器，才明白这套设计背后的精妙之处。

先说结论：类加载机制解决的是“Java 类从哪来、怎么变成可执行代码、由谁说了算”这三个问题。 Java 程序跑起来的第一步，不是执行 main 方法，而是由类加载器（ClassLoader）把 .class 字节码文件加载进 JVM，经过一系列处理后变成 Class 对象，才能被后续的 new、反射、方法调用等操作使用。

类加载器本身是一个对象，它实现了“按名称查找类或接口的二进制字节流”的能力。每个类加载器都管理着自己负责的那部分类加载行为，JVM 启动时默认会创建三到四个内置类加载器，共同协作完成类搜索与加载工作。

这里有个大多数新手都忽略的点：类加载不是一次性把所有类都读进内存，而是按需加载。 也就是说，JVM 在运行过程中只有当某个类第一次被主动使用时，才会触发类加载。这个“按需”的设计直接决定了后边要讲的双亲委派机制存在的意义——JVM 需要在运行时动态决定“找谁要这个类”。

而且类加载器不只是面试题，工作中也会频繁遇到相关问题。比如部署 Web 应用时遇到 ClassNotFoundException 或 NoSuchMethodError，排查思路的核心就是类加载器隔离问题；写 SPI 框架时用 Thread contextClassLoader 绕过双亲委派限制；做热部署和热替换方案时自定义类加载器管理新旧版本的类。懂了类加载机制，这些实操问题你才能做到“遇到不慌，能按套路排查”。

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 对象”的过程。它有三个关键动作：

1. 通过类的全限定名获取定义此类的二进制字节流。这个“获取”不一定是从 .class 文件读，也可以从 ZIP/JAR 包、网络、动态代理运行时生成、数据库等任何来源。
2. 将字节流所代表的静态存储结构转化为方法区的运行时数据结构。
3. 在堆内存中生成一个代表这个类的 java.lang.Class 对象，作为方法区这个类的各种数据的访问入口。

加载阶段是类加载器直接参与的核心环节，也是唯一的“主动”获取字节流的阶段。后续的验证、准备、解析操作都依赖这一步产出的 Class 对象。类加载器名字里的“加载”二字，指的正是这一步，只不过实际编码中我们常把“定义加载器”（真正执行 defineClass 的那个）与“初始加载器”（发起加载请求的那个）区分开。

3.2 验证：JVM 的第一道安全防线

验证阶段是为了确保字节流中的信息符合 JVM 规范，不会危害 JVM 自身安全。这部分工作细致且繁重，包含四个子校验：文件格式验证（魔数、版本号等）、元数据验证（类是否继承了被 final 修饰的类、是否实现了所有抽象方法等）、字节码验证（操作数栈的数据类型与指令是否匹配、跳转指令指向是否合理等）、符号引用验证（常量池中的符号引用能否正确定位到目标类/方法/字段）。

日常开发中我们写的类基本不会卡在验证阶段，但当字节码被篡改或来自不可信来源时，这个阶段就是关键保护。面试时可以补充一句：验证阶段可通过 -Xverify:none 关闭，但只建议在明确可信的环境下使用，JDK 13 开始默认是 -Xverify:remote，本机类默认不验证已逐渐改变，这个演进能体现你关注新版特性。

3.3 准备：为静态变量分配内存并设置零值

准备阶段正式为类变量（static 修饰的变量）分配内存，并设置默认零值。注意，这个阶段设置的是零值，不是我们在代码里写的初始值。例如 private static int count = 100; 在准备阶段 count 的值是 0，等到初始化阶段执行 <clinit>() 方法时才会被赋值为 100。

有一个特例：如果字段是 static final 的常量，并且在编译期就能确定值，那准备阶段就会直接赋上该常量值，比如 private static final int MAX = 100; 准备阶段就把 100 放进去了。但如果是 private static final Integer MAX = Integer.valueOf(100); 这种需要运行期计算的，就还是先零值后初始化的流程。

3.4 解析：把符号引用替换成直接引用

解析阶段将常量池中的符号引用（以字符串形式描述的目标类、方法、字段的全限定名等）替换为直接引用（指向目标在内存中的实际地址或句柄）。

比如代码里写了一行 obj.hashCode()，编译后常量池里记录的是“java/lang/Object.hashCode:()I”这样的符号引用。解析阶段就会去方法区找到 hashCode 方法实际的内存入口，把引用替换成可以直接调用的地址。

这个阶段是 JVM 实现“动态链接”的基础。Java 里多态、接口调用、反射都依赖解析阶段的灵活性。解析可以发生在初始化之后，这是 JVM 规范允许的，目的是为了延迟解析、减少性能开销。

3.5 初始化：执行类构造器 <clinit>()，静态代码块和静态变量赋值在这里发生

初始化阶段是类加载过程的最后一步，也是真正执行 Java 代码的开始。JVM 会收集类中所有静态变量的赋值动作和静态代码块中的语句，合并生成 <clinit>() 方法并执行。

触发初始化的时机有几种经典场景：new 对象、访问静态变量或调用静态方法（被 final 修饰且编译期常量除外）、反射调用、初始化子类时先初始化父类、JVM 启动时初始化含 main 方法的类。

这个阶段经常被拿来设计单例模式的双重检查锁，因为 JVM 保证了 <clinit>() 在多线程环境下只会被执行一次，而且是线程安全的。利用这个特性可以写出天然安全的静态内部类单例。面试时如果被问到“什么时候会触发类初始化”，建议把这几条完整的触发条件列出，并说明子类初始化会连带触发父类初始化（但通过子类访问父类静态字段时，只会触发父类初始化）。

4. 双亲委派机制：核心原理、源码走读与设计目的

4.1 一句话说清它的工作规则

双亲委派机制（Parent Delegation Model）的规则非常简洁：当一个类加载器接收到类加载请求时，它首先不会自己去尝试加载这个类，而是把这个请求委派给父加载器去完成。每一层的类加载器都是如此，因此所有的加载请求最终都应该传送到最顶层的启动类加载器。只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围内找不到这个类）时，子加载器才会尝试自己去加载。

这个机制保证了一个类在 JVM 中只会被某一个加载器加载一次，且加载它的“链路上的类加载器”是一致的。通俗讲，就像你遇到问题先找直属上级，上级推给更上级，直到最顶层，顶层解决不了才逐级往下传回。这是一种“层层上报、委派优先”的协作模式。

4.2 源码走读：loadClass 方法里到底发生了什么

要真正理解双亲委派，必须看 java.lang.ClassLoader#loadClass(String name) 方法的实现。JDK 8 的典型代码如下（略有删减）：

java复制protected Class<?> loadClass(String name, boolean resolve)
        throws ClassNotFoundException {
    synchronized (getClassLoadingLock(name)) {
        // 第一步：检查这个类是否已经被加载过了
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                if (parent != null) {
                    // 第二步：如果父加载器不为 null，先委派给父加载器
                    c = parent.loadClass(name, false);
                } else {
                    // 第三步：如果父加载器为 null，说明是 Bootstrap 直接加载
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父加载器抛出异常，说明父加载器无法完成加载请求
            }
            if (c == null) {
                // 第四步：父加载器加载不到，才自己在 findClass 中查找
                long t1 = System.nanoTime();
                c = findClass(name);
                // 记录耗时统计...
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

这段代码的核心逻辑就四步：

1. 查缓存（findLoadedClass），已加载过直接返回，避免重复加载。
2. 看 parent 字段，非空就委派给 parent.loadClass()。
3. parent 为 null 时，直接用 Bootstrap 加载器尝试加载。
4. parent 加载失败（抛 ClassNotFoundException 或返回 null），自己走 findClass()。

注意，findClass() 在 ClassLoader 基类中默认抛 ClassNotFoundException。真正干活的 defineClass()（读取字节流并生成 Class 对象）通常是我们重写 findClass 时调用的。这也是为什么自定义类加载器最规范的做法是“重写 findClass，而不是重写 loadClass”——因为重写 loadClass 会破坏委派链，而重写 findClass 是让父加载器失败后再执行自己的加载逻辑。

4.3 为什么一定要往上委派：三个层面解读

第一，避免类的重复加载。 如果每个加载器都自己加载一遍同一个类，JVM 里就会出现多个内容相同但类名相同的 Class 对象，程序中的 == 比较、instanceof 判断、方法重写都会出问题。双亲委派保证同一个类在整条委派链中只会被最高层的那个加载器加载一次，其他层拿到的都是同一个结果。

第二，保证 Java 核心类库的安全性。 设想一下，如果没有双亲委派，程序员自己写一个 java.lang.String，可以随意替换掉 JDK 核心类，整个 Java 沙箱安全模型就崩了。但有了双亲委派，用户定义的 String 加载请求会被逐层上报到 Bootstrap ClassLoader，而 Bootstrap 发现自己已经加载过标准 String，就直接返回标准类，用户自定义类永远不会被加载。这从根本上排除了恶意代码冒充核心类型的问题。

第三，按“视野范围”隔离类库。 每个类加载器都有自己“熟悉”的搜索路径，上一层加载器看不到下一层路径里的类，但下一层能看到上一层的类。这种层级边界天然形成了类库的隔离，比如后边要讲的 Tomcat 多 Web 应用隔离，就是借助这个思路更深层的定制。

4.4 双亲委派不保证“全局唯一”：一个常见误区

说完优点，必须提一个常见的理解偏差。很多人以为双亲委派保证了“一个类在 JVM 中绝对唯一”，这是不对的。双亲委派只是保证了“同一个类加载器实例发起的、且委派链上的加载器能加载到的类”是唯一的。 如果两个不同的类加载器都定义了自己的类，即使类名完全相同，它们在 JVM 中也是两个不同的 Class 对象，相互之间无法直接赋值（会出现 ClassCastException）。

举个例子，你在同一个 JVM 里 new 了两个自定义 ClassLoader，分别加载同一份 com.example.User.class，那么 loader1.loadClass("com.example.User") 和 loader2.loadClass("com.example.User") 得到的 Class 对象是不同的。判等时用 == 是 false，用 isAssignableFrom 也是 false。这就解释了为什么做热部署时要回收旧加载器、创建新加载器，而不是复用旧的——只有新加载器才能加载出新版类，同名的旧类已经在旧加载器缓存里了。

5. 双亲委派的“破坏”与经典场景：不只是背结论

面试官问完“什么是双亲委派”，大概率会紧跟一句“有没有被破坏过？怎么破坏的？”这类问题实际上是在考察你有没有在真实项目或框架源码里看到过这个机制的边界，而不只是背概念。我梳理三个最典型的破坏场景，每一个都有自己的设计逻辑。

5.1 JDBC 与 SPI：父加载器反过来找子加载器要类

JDBC 是破坏双亲委派最经典的案例。DriverManager 在 java.sql 包里，由 Bootstrap ClassLoader 加载。DriverManager 初始化时要加载数据库驱动实现类，比如 com.mysql.cj.jdbc.Driver。问题是，驱动 jar 在 classpath 上，Bootstrap 和 Extension 都不知道它在哪里，能加载它的只有 AppClassLoader。按照双亲委派，Bootstrap 根本不会往下找，那驱动怎么被加载？

解决方案是线程上下文类加载器（Thread Context ClassLoader）。DriverManager 初始化时通过 Thread.currentThread().getContextClassLoader() 获取当前线程的上下文加载器，用这个加载器去加载用户配置的驱动类。这就实现了“父加载器请求子加载器加载类”的逆向委派，打破了向上委派的默认规则。

源码上看，ServiceLoader 是 SPI 机制的核心，它的 load 方法默认使用线程上下文类加载器：

java复制public static <S> ServiceLoader<S> load(Class<S> service) {
    ClassLoader cl = Thread.currentThread().getContextClassLoader();
    return ServiceLoader.load(service, cl);
}

这个设计的意义在于：JDK 只定义了接口规范（如 java.sql.Driver），实际的实现由厂商提供并放在应用 classpath 中。 核心 lib 无法预知具体实现类的加载路径，只能借助“线程上下文”这个运行期环境信息来定位实现类。

5.2 Tomcat 等 Web 容器：为了应用隔离，主动推翻向上委派

Tomcat 的类加载体系也“破坏”了双亲委派，但破坏得很精细。它需要解决的矛盾是：同一个 Tomcat 可以部署多个 Web 应用，每个应用可能依赖同一个第三方库的不同版本（比如 app1 用 Spring 4，app2 用 Spring 5）。如果都用 AppClassLoader 加载，必然后加载的覆盖先加载的，应用之间相互污染。

Tomcat 的方案是为每个 Web 应用创建一个独立的 WebAppClassLoader，并且改变了委派顺序：WebAppClassLoader 会优先加载自己 WEB-INF/classes 和 WEB-INF/lib 下的类，而不是先委派给父加载器。这就打破了“先父后子”的默认规则。

但这里有个精妙之处：对于 Java 核心类库（如 java.lang.String），WebAppClassLoader 仍然会优先委派给 Bootstrap，因为核心类的安全性不能妥协。也就是说，Tomcat 是“部分倒置”——对核心库保持向上委派，对应用库采用“自己优先”。这提醒我们，所谓的“破坏”并不是彻底推翻，而是根据不同类库的特性和可信度做有选择的策略调整。

5.3 OSGi 与热部署：按模块管理类加载，每个 Bundle 自成体系

OSGi 是一个更彻底的类加载隔离模型。在 OSGi 中，每个 Bundle（模块）都有自己的 ClassLoader，类加载不再遵循单一的层级委派，而是根据模块间的依赖关系动态决定。

OSGi 的类加载规则可以粗略描述为：先查自己 Bundle 导出的包，再查 Import-Package 声明的依赖 Bundle 的导出包，最后才委派给父加载器。这种模型的优点在于模块边界清晰、版本冲突可控、支持运行期动态安装/卸载 Bundle。但这套体系复杂度高，在普通业务开发里用得不多，面试中提一句可以展示广度，不建议展开太深，因为不是所有面试官都吃这一套。

5.4 自己实现并“破坏”双亲委派的示例：热替换的雏形

如果你在简历里写了“熟悉类加载机制”，面试官很可能会让你手写一个“打破双亲委派的自定义类加载器”。下面我给出一个最小可运行示例，代码注释里解释了关键点。

java复制public class HotSwapClassLoader extends ClassLoader {

    public HotSwapClassLoader(ClassLoader parent) {
        super(parent);
    }

    @Override
    protected Class<?> loadClass(String name, boolean resolve)
            throws ClassNotFoundException {
        // 破坏点：核心库仍然交给父加载器，保证 JDK 类安全
        if (name.startsWith("java.") || name.startsWith("javax.")) {
            return super.loadClass(name, resolve);
        }
        // 其他类：自己加载，不向上委派
        Class<?> clazz = findLoadedClass(name);
        if (clazz == null) {
            String fileName = name.replace('.', '/') + ".class";
            try (InputStream is = getClass().getResourceAsStream("/" + fileName)) {
                if (is == null) {
                    return super.loadClass(name, resolve);
                }
                byte[] bytes = toByteArray(is);
                clazz = defineClass(name, bytes, 0, bytes.length);
            } catch (IOException e) {
                throw new ClassNotFoundException(name, e);
            }
        }
        if (resolve) {
            resolveClass(clazz);
        }
        return clazz;
    }
}

这个类加载器在每次调用时都会重新读取 .class 文件并 defineClass，所以只要替换磁盘上的 class 文件，再新建一个 HotSwapClassLoader 实例去加载，就能拿到新版本的类。而旧类仍然被旧的类加载器持有，不影响正在运行的部分。热部署框架（如 JRebel、Spring Boot DevTools 的部分机制）的核心思路与此一致。

但要注意几个坑：defineClass 出来的类，其内部引用的其他类还是会走这个类加载器（或者它委派的链），如果新旧版本之间依赖类型不一致，会抛 NoSuchMethodError 或 NoClassDefFoundError。热替换只对“类加载器新建、类重新读取”有效，对已经被 JIT 编译的方法栈帧无能为力——已在栈上执行的方法不会因为类变了就自动变。这也是为什么很多热部署需要配合特定调试工具实现全量替换。

6. 高频面试追问与实战排查套路：别让八股文只停留在“背会了”

6.1 面试官最爱追问的 6 个变体问题

1. String.class.getClassLoader() 为什么返回 null？ 答案：String 由 Bootstrap ClassLoader 加载，Java 层无法直接获取该加载器实例，所以返回 null。

2. 能不能自己写一个 java.lang.String 类并在程序中使用？ 答案：编译可以通过（编译时不检查包名是否与 JDK 冲突），但运行时加载请求被委派到 Bootstrap，类加载阶段会因“试图加载 java.lang.String”而抛出 SecurityException（或如果你放到 bootclasspath 中才会覆盖，但那是改 JDK 本身了）。所以回答是“不能，至少不能以常规方式使用”。

3. new 对象和反射调用时类加载的时机一样吗？ 一样，都是首次主动使用某类时才触发加载和初始化。但反射（如 Class.forName）会强制触发初始化，而访问编译期常量不会触发初始化。

4. 两个类加载器加载同一个类，算两个类还是一个类？ 是两个类，类的唯一性由“类本身 + 定义它的类加载器”共同决定。JVM 规范中一个类的全限定名不止是 com.example.User，而是 com.example.User + 定义类加载器的标识。

5. 为什么需要线程上下文类加载器？ 因为父加载器无法向下感知子加载器路径中的类，但运行期线程能获取到当前类加载器上下文。SPI、JDBC、JAXB、JNDI 等框架都依赖它。

6. 怎么排查 ClassNotFoundException 是哪个加载器找不到类？ 最直接的是在启动参数加 -verbose:class，它会打印每个类的加载来源（哪个 jar、哪个 ClassLoader）。更精细的可以用 -Xlog:class+load=info（JDK 9+）。还有 arthas 的 classloader 命令可以列出所有加载器及各自加载的 jar 列表，排查线上类冲突非常方便。

6.2 一次线上类冲突排查实战：同一接口两个版本

我之前维护的一个 Spring Boot 服务在启动时突然抛 NoSuchMethodError，报错显示某个第三方库的 HttpUtils.execute 方法找不到。从报错栈看，调用方确实是引用了这个库，但方法签名对不上。

排查过程是这样的：先用 -verbose:class 启动，发现该类被加载了两次，一次来自 libA-1.0.jar，一次来自 libB-2.0.jar，而这两个 jar 分别是两个不同模块的传递依赖。由于类名相同但来源不同，实际被加载的是先被触发的那个，导致后一个模块调不到它期望的方法签名。

解决方法是使用 maven 的 dependency:tree 排查依赖冲突，统一到目标版本，排除多余传递依赖。但如果两个 jar 都必须存在（比如容器环境），就得借助类加载器隔离——把冲突的模块分别放到不同的 ClassLoader 域中，Tomcat 的多应用部署就是这种思路。Java 9 之后还可以用模块化把不同版本的库变成不同模块，但那套改造成本比较高，大多数团队还是优先选择依赖收敛。

6.3 新手最容易踩的三个类加载相关的坑

第一个是把业务 jar 放到 $JAVA_HOME/jre/lib/ext 下以为可以全局生效。这样做虽然在 JDK 8 及以前确实能被 ExtClassLoader 加载，但随着 JDK 9 的模块化改革，这个目录已经不再生效。而且把业务代码放进 JRE 扩展目录会引入难以排查的类冲突，强烈不建议在生产环境使用。

第二个是在自定义类加载器里调用了 super.loadClass() 之后又自己加载，导致重复加载。正确做法是重写 findClass 而不是 loadClass，让基类的双亲委派逻辑先跑完，父类加载不到才会调用你的 findClass。直接重写 loadClass 但写错时序，轻则加载两个同名类，重则直接死循环。

第三个是忽略线程上下文类加载器的设置。在 Web 容器或框架环境中，Thread.currentThread().getContextClassLoader() 返回的可能是容器的 WebAppClassLoader，如果不显式设置，某些 SPI 机制会加载不到应用里的实现类。常见的解决方式是：

java复制ClassLoader original = Thread.currentThread().getContextClassLoader();
try {
    Thread.currentThread().setContextClassLoader(targetClassLoader);
    // 执行需要特定类加载器的逻辑
    ServiceLoader.load(SomeService.class);
} finally {
    Thread.currentThread().setContextClassLoader(original);
}

这个“先保存、再设置、finally 恢复”的写法是线程上下文类加载器的标准操作姿势，写框架代码时经常用，忘了恢复会导致后续线程上下文错乱，出现一些非常诡异的加载错误。

7. 自定义类加载器的正确写法：从模板到避坑

7.1 什么时候需要自定义类加载器

面试官常问“你自己写过自定义类加载器吗”，问的目的不是让你背模板，而是考察你能否把类加载机制用在真实场景。需要自定义类加载器的场景大致有：

• 加密解密：class 文件被加密存储，需要在加载时解密（覆盖 findClass 方法读取并解密字节流）。
• 热部署/热替换：动态加载新版本类，如开发工具、在线升级系统。
• 网络加载：从远程服务器拉取类文件，如 RMI 等分布式场景。
• 隔离与安全：为不同模块建立独立类空间，防止依赖相互污染。
• 字节码增强：在 defineClass 前对字节码做插桩、增强，类似各种 agent 的效果。

7.2 标准的自定义类加载器写法

标准写法是重写 findClass(String name) 方法，让它读取字节流后调用 defineClass。不要重写 loadClass，除非你有明确的破坏双亲委派的需求。

java复制public class FileSystemClassLoader extends ClassLoader {

    private String classPath;

    public FileSystemClassLoader(String classPath, ClassLoader parent) {
        super(parent);
        this.classPath = classPath;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        byte[] bytes = loadClassData(name);
        if (bytes == null) {
            throw new ClassNotFoundException(name);
        }
        // defineClass 是 final 方法，底层会调用 JVM 的 defineClass1 原生方法
        return defineClass(name, bytes, 0, bytes.length);
    }

    private byte[] loadClassData(String name) {
        String path = classPath + "/" + name.replace('.', '/') + ".class";
        try (InputStream is = new FileInputStream(path);
             ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
            byte[] buffer = new byte[1024];
            int len;
            while ((len = is.read(buffer)) != -1) {
                baos.write(buffer, 0, len);
            }
            return baos.toByteArray();
        } catch (IOException e) {
            return null;
        }
    }
}

这个类加载器的逻辑是：当父加载器无法加载某个类时，loadClass 会调用我们的 findClass，我们从指定目录读取类的二进制字节流，再通过 defineClass 定义这个类。

实际使用时要注意一个问题：如果这个类加载器的父加载器（AppClassLoader）自己也能加载到相同路径下的同名类，那么我们的 findClass 根本不会被调用。 所以在测试时要把目标类从原来的 classpath 中移走，或者强制使用自定义加载器并确保父加载器的搜索路径不包含目标类。

7.3 一个冷门但好用的知识点：defineClass 的包名与 SecurityException

defineClass 在定义带 java. 前缀的包时，会抛出 SecurityException。这是 JVM 对核心类库的保护机制之一。如果你在自定义类加载器里尝试加载 java.lang.Hacker，会在 defineClass 这一步就被拦住。这门保护甚至比双亲委派更底层——即使你完全破坏了委派链，JVM 本身也不会允许你自定义核心包下的类。

写热替换类加载器时，这个限制反而帮你挡掉了很多低级错误。我曾经见过有人试图用自定义加载器“魔改” JDK 内置类来实现调试功能，结果卡在 SecurityException 上，折腾半天后发现还是用 normal agent 或者 -Xbootclasspath 这种正规入口更合理。

8. 类加载的全链路协作：从 JVM 启动到一次 new 操作

聊完各阶段和委派机制，我习惯把这些知识串成一个完整的链路，这样面试时讲起来是“体系化”的，而不是零散的知识点。

假设程序启动时执行 com.example.Main.main：JVM 启动时先由 Bootstrap 加载器加载核心类（如 java.lang.Object、java.lang.String 等），然后通过 AppClassLoader 加载 Main.class。加载 Main 类的过程中，遇到 new User() 这样的字节码指令，JVM 会解析常量池中的符号引用，发现需要 com.example.User 类，于是触发对 User 的加载请求。AppClassLoader 接收请求后，先查缓存没有，再委派给 ExtClassLoader，ExtClassLoader 再委派给 Bootstrap，Bootstrap 的搜索范围内没有 com.example.User，于是返回失败。ExtClassLoader 尝试加载（JDK 8 的 ext 目录里也没有），失败，最终 AppClassLoader 在自己的 classpath 中找到了 com.example.User.class，成功读取并 defineClass，完成加载。接着走验证、准备、解析，最后触发初始化，执行 User 类的静态代码块和静态变量赋值。然后 JVM 才能正常创建 User 对象。

这就是一次最普通的 new 操作背后，类加载体系跑完的完整协作链路。能把这个链路顺畅讲出来，面试官基本能确认你是真的理解了类加载机制，而不是背了几个名词。

串完链路你会发现，类加载机制最核心的思想是**“分工与协作”**：不同层级的加载器负责不同范围的类，加载请求层层上报，顶层解决不了再逐级下放。这套模型既保证了核心类的唯一性与安全性，又为扩展和隔离留下了空间。理解了这一点，不管面试题怎么变形，你都能抓住本质去回答。

最后分享一个我在实际调试中的心得：遇到类加载相关的报错，先别急着搜报错信息，先想清楚三个问题——这个类应该由哪个加载器加载、实际由哪个加载器加载了、两个加载器之间的委派关系是什么。把这三个问题想明白，大部分类加载问题都能快速定位根因。类加载机制看起来抽象，但只要你动手写过一次自定义加载器，再用 -verbose:class 观察过一次真实的加载过程，它就会从面试题变成你最熟悉的工具之一。