深入理解Java类加载器与双亲委派模型：从原理到实战排查-代码聚汇网

深入理解Java类加载器与双亲委派模型：从原理到实战排查

山月刀岚月刀·2026-09-06·阅读 22 GEO检测（免费）

Java类加载器双亲委派模型ClassNotFoundException

|难度：普通|阅读约 49 分钟

1. 类加载器到底是什么：一个容易被忽略的Java根基

说实话，做了这么多年Java开发，面试过不少候选人，也带过不少新人，我发现一个很有意思的现象：很多人能把双亲委派模型的流程背得滚瓜烂熟，但真要问他"类加载器到底解决了什么问题"，或者让他排查一个ClassNotFoundException，往往就卡壳了。

先说个最基础的问题：Java程序是编译成字节码运行的，.class文件要被JVM加载进来才能被执行。那么这个"加载"的动作由谁来做？就是类加载器（ClassLoader）。你可以把它想象成一个搬运工——把磁盘上或者网络上的.class文件搬进JVM的内存里，然后JVM才能通过这块内存创建对应的对象、调用对应的方法。

但这只是最浅层的理解。类加载器真正复杂和精妙的地方在于两点：

它不是只有一个，JVM里有多个类加载器，各司其职，而且有父子层级关系。
它有一套严格的"请求-委派"机制，也就是我们常说的双亲委派模型（Parent Delegation Model）。

为什么要搞这么多加载器？为什么不弄一个"万能加载器"把所有的class一口气全加载了？这背后涉及到安全性、隔离性、版本冲突等一系列问题。

我先用面试最常见的场景来说明这玩意儿为什么值得学：面试必考。不管你是应届生还是工作了五年的程序员，"类加载器"和"双亲委派模型"几乎出现在每份Java面试题里。但我想说的是，这绝不是一个八股文考点那么简单——线上环境出现NoClassDefFoundError，Tomcat部署多个应用导致类冲突，热部署功能失效，这些真实的坑，根源全都在这一块。

我对这篇文章的定位是：不只会背定义，而是把类加载器从"是什么"到"为什么"，再到"实际开发中怎么用、怎么排查问题"完整捋一遍。看完之后你再去看面试题，会发现那些题目突然变得很简单了。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 三个内置加载器：JVM默认的"家谱"体系

2.1 启动类加载器（Bootstrap ClassLoader）：JVM的"根"

JVM内置了三个类加载器，它们之间形成了天然的层级关系。最顶端的是启动类加载器，也叫根加载器。

启动类加载器用C++实现，是JVM自身的一部分，并不继承自java.lang.ClassLoader类。它的职责是加载JVM最核心的基础类库——也就是$JAVA_HOME/lib目录下的核心类，比如rt.jar里的java.lang.*、java.util.*、java.io.*这些。你能写出String s = "123"，就是靠它把String类加载进内存的。

有个细节需要注意：启动类加载器加载的是-Xbootclasspath指定的路径，以及系统属性sun.boot.class.path对应的路径。在Java 9之后，因为模块化（Jigsaw）的引入，这个加载路径变成了jrt:文件系统，这个我们后面单独说。

为什么必须是它来加载核心类？ 因为越底层的类越要"纯净"。如果某个核心类能被应用程序随意覆盖，整个JVM就乱套了。你想，如果你能在代码里定义一个java.lang.String，然后塞进一些恶意逻辑，那涉及String的所有代码都会受影响——这就是类加载安全性的最初考虑。

2.2 扩展类加载器（Extension ClassLoader）：中间层，存在感最低

扩展类加载器，Java 8及以前叫ExtClassLoader，对应加载$JAVA_HOME/lib/ext目录下的类，或者java.ext.dirs指定的路径。它的作用是为了扩展JDK的功能，把一些非核心但有通用性的类放到扩展目录里。

这里我想特别说一下Java 9的变化——很多人还在用JDK 8，突然切到JDK 11就懵了：ExtClassLoader没了。

在JDK 9之后，扩展类加载器被改名为平台类加载器（Platform ClassLoader），由ClassLoader.getPlatformClassLoader()获取，加载的不再是lib/ext目录，而是模块化系统里的特定模块。这个变化是Jigsaw模块化改革的配套措施。面试的时候如果被问到"JDK 9的类加载器有什么变化"，这个点就是关键答案。

但实际上，日常开发中我们很少直接跟扩展/平台类加载器打交道。它更像一个中转站——承上启下。

2.3 应用类加载器（App ClassLoader）：咱们代码的"直接老板"

应用类加载器也叫系统类加载器，AppClassLoader，负责加载classpath（也就是环境变量配置的CLASSPATH路径）下的所有类。你自己写的业务代码、引用的第三方jar包，默认都是它来加载。

这个加载器在绝大多数情况下是我们要打交道的"默认加载器"：

java复制public class ClassLoaderDemo {
    public static void main(String[] args) {
        ClassLoader loader = ClassLoaderDemo.class.getClassLoader();
        System.out.println(loader);                         // sun.misc.Launcher$AppClassLoader
        System.out.println(loader.getParent());             // sun.misc.Launcher$ExtClassLoader
        System.out.println(loader.getParent().getParent()); // null
    }
}

这段代码跑在JDK 8上，输出结果如上注释所示。注意最后一行输出的是null——启动类加载器在Java代码中就是表示为null，因为它是JVM的一部分，不是Java类。

这就是我说"家谱"的原因：AppClassLoader的父加载器是ExtClassLoader，ExtClassLoader的父加载器是BootstrapClassLoader，BootstrapClassLoader没有父加载器。很多初学者会在这里被概念绕晕，"getParent()拿到的不是加载器的父类，而是它上一级的加载器"，这个要分清楚。

3. 双亲委派机制：加载请求到底是怎么传递的

3.1 一句话讲清楚流程

双亲委派模型（Parent Delegation Model）的流程可以用一句话概括：

当某个类加载器收到类加载请求时，它不会自己去尝试加载这个类，而是先把请求委派给父加载器去处理，每一层都是如此，直到最顶层的启动类加载器。只有当父加载器反馈自己无法完成加载时（它的搜索范围内没有这个类），子加载器才会尝试自己去加载。

画成流程图大概是：

code复制自定义类加载器 → 应用程序类加载器 → 扩展类加载器 → 启动类加载器
                     ↑                    ↑                ↑
                 父加载不到时         父加载不到时       真正开始加载

注意方向：请求是自下而上传递的，真正的类查找是自上而下开始的。启动类加载器会在自己的搜索范围内尝试加载，如果找不到就"甩锅"给下一级，直到有人能加载成功为止。如果所有加载器都找不到该类，才会抛出ClassNotFoundException。

3.2 loadClass源码逐行拆解

双亲委派模型的核心逻辑就在java.lang.ClassLoader.loadClass()方法中，我建议每个人都把这源码认认真真读一遍。关键代码贴在这里：

java复制protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // 1. 先检查这个类是否已经被当前类加载器加载过
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            try {
                if (parent != null) {
                    // 2. 父加载器不为null，请求父加载器去加载
                    c = parent.loadClass(name, false);
                } else {
                    // 3. 父加载器为null，说明自己就是启动类加载器
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // 父加载器抛出ClassNotFoundException说明找不到，继续往下执行
            }

            if (c == null) {
                // 4. 父加载器都找不到，自己调findClass去找
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}

有几个细节值得单独拎出来说：

第一，synchronized锁。 注意到没有，整个加载过程是加锁的，锁对象是getClassLoadingLock(name)。这个设计是为了保证同一个类在同一个类加载器中只会被加载一次，避免并发情况下重复加载产生多个副本。这是JVM类加载的线程安全保证。

第二，findLoadedClass是第一步。 很多人忽略这个检查。每个类加载器内部都维护了一个已加载类的缓存，findLoadedClass就是查这个缓存。如果已经加载过，直接返回，不会重复加载。这就是为什么同一个类加载器加载同一个类不会产生多个Class对象。

第三，父加载器加载不到不等于"不存在"。 ClassNotFoundException在这里被捕获是有深意的——它只是表示父加载器的搜索范围内没有这个类，不代表这个类本身有问题。这给了子加载器继续尝试的机会。

3.3 为什么双亲委派能带来"类一致性"

面试中最常问的问题之一：为什么JVM要采用双亲委派模型？

核心答案就一个词：避免类被重复加载，保证核心类的唯一性和安全性。

举个例子。假设没有双亲委派机制，你写了一个恶意的java.lang.String类，然后你的应用加载器把它加载进来了。此时JVM内存中就存在两个String类：一个是由启动类加载器加载的，一个是你的应用类加载器加载的。这两个String是完全不同的类型，没有任何关系。那你的代码运行起来会乱成什么样？String参数的方法签名都对不上，所有依赖String的内置库全部瘫痪。

双亲委派模型直接就杜绝了这种可能性。所有加载请求先交给父加载器，java.lang.String的加载请求一路上抛，最终被启动类加载器接住，在它那里加载的永远是JVM自带的、可控的、原始的String。你的应用类加载器这辈子都碰不到String了。

还有一个容易被忽略的好处是一致性。同一个类在同一个类加载器中只会被加载一次，你可以在代码里用==比较两个Class对象，这在类加载机制上是安全的。如果每个加载器都各自加载一份，那obj instanceof Xxx这种判断就会出大问题——同一个包路径的类，在不同类加载器中是不同的类型。

4. 双亲委派模型的"破防"时刻：SPI与线程上下文类加载器

4.1 当父加载器"倒过来"向子加载器求助

双亲委派模型不是万能的，它有一个典型的先天缺陷。这个缺陷出在JDK核心类库和第三方实现库的配合上。

最经典的例子就是JDBC。java.sql.DriverManager是核心类库，由启动类加载器加载。但是JDBC是接口标准，真正干活的是具体数据库厂商的驱动实现——比如MySQL的com.mysql.cj.jdbc.Driver，这些实现类在你的classpath里，应该由应用程序类加载器加载。

可是问题来了：DriverManager的代码运行在启动类加载器中，它要加载MySQL驱动类，按双亲委派模型，它只能让父加载器去加载（没有父加载器），它的搜索范围里根本没有MySQL驱动。也就是说，启动类加载器"看不见"应用classpath里的驱动类。

这就形成了一个死局：核心类（父加载器加载的）需要调用第三方实现类（子加载器加载的），但双亲委派模型是单向的、自上而下的，父加载器没法"下探"去子加载器的势力范围加载东西。

4.2 线程上下文类加载器（Thread Context ClassLoader）如何解围

Java的解决方案是引入线程上下文类加载器。它的核心思想很简单：打破双亲委派的"自上而下"单向性，允许线程级别指定一个"底层的"类加载器，让核心类可以通过这个类加载器反向加载第三方实现。

来看JDBC的典型执行流程：

java复制// 传统的JDBC驱动加载
Class.forName("com.mysql.cj.jdbc.Driver");
Connection conn = DriverManager.getConnection(url, user, password);

Class.forName("com.mysql.cj.jdbc.Driver")这个调用是在应用代码里执行的，由AppClassLoader加载，所以这种方式没有问题。但现代JDBC 4.0之后支持自动注册驱动——不再需要手写Class.forName，DriverManager会在初始化时从META-INF/services/java.sql.Driver文件里读取驱动类名，并加载它们。

这时候问题就来了。DriverManager的类初始化逻辑运行在启动类加载器的代码里，它怎么加载到应用classpath里的驱动类？

答案就是：

java复制// DriverManager类初始化时的核心逻辑（JDK 8及之后）
ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class);
Iterator<Driver> driversIterator = loadedDrivers.iterator();

ServiceLoader.load的内部实现里，会用Thread.currentThread().getContextClassLoader()获取线程上下文类加载器，然后用它去加载具体的驱动实现类。这样，启动类加载器"借助"应用类加载器的手，完成了加载第三方实现类的动作。

4.3 为什么说"上下文类加载器破坏双亲委派"这句话不够准确

关于线程上下文类加载器，面试的时候有一个高频陷阱题："线程上下文类加载器破坏了双亲委派模型，你怎么看？"

我的意见是：它确实打破了"向上委派"的默认机制，但你要说它"破坏了双亲委派"这个基本原则，不太准确。 更准确的说法是：它是一个"后门"，是为了解决父加载器无法加载子加载器范围内类的困境而引入的补充机制。

双亲委派模型本身的优点没有被破坏——核心类库依然由启动类加载器独占，仍然不会重复加载。线程上下文类加载器只是在特定场景下，给核心类打开了一条"下行通道"。

类似地，Tomcat等Web容器的类加载器体系也自定义了类加载顺序——每个Web应用都有独立的WebAppClassLoader，它优先从自己WEB-INF/classes和WEB-INF/lib下加载类，加载不到再委派给父加载器。这么做是为了实现不同Web应用之间的隔离。如果你部署了同一个jar包的不同版本到不同的Web应用里，没有这种隔离机制，就会因为类冲突直接打起来。

Tomcat类加载器的设计思路其实就是"反向的"双亲委派——优先自己加载，不行再向上委派。这也说明了一件事：双亲委派模型是JVM的默认约定，但如果实际业务有隔离需求，内核是支持你打破这个约定的。

5. 打破双亲委派的三条实战路径：热部署与Tomcat隔离

5.1 自定义类加载器的关键：重写findClass还是loadClass

面试题里问"如何自定义一个类加载器"，大多数人第一反应是继承ClassLoader类，然后重写方法。但重写哪个方法是有讲究的。

正确做法是重写findClass()方法，而不是loadClass()方法。 原因很简单：loadClass()方法里包含完整的双亲委派逻辑，如果你重写了它，就相当于把这个逻辑整个替换掉的，这会导致你的加载器不再向上委派。这不能说完全错——如果你实现了ClassLoader，你就知道：热部署的时候，往往不需要重写整个loadClass逻辑。实际上，https://docs.oracle.com/javase/8/docs/api/java/net/URLClassLoader.html 是个很好的参考实现骨架。

findClass()默认就是抛出ClassNotFoundException，它的作用就是"自己找类"——如果你不想破坏双亲委派，只是想在父类加载不到的时候补充一条自己的查找路径，就直接重写findClass。这样双亲委派模型的框架逻辑还在，只是最后一步多了你自定义的兜底方案。

而如果你要完全控制加载流程（比如热部署场景，想每次直接加载最新版的class，绕过父加载器的缓存），就需要重写loadClass方法，把它替换成自己定义的加载顺序。

5.2 热部署的核心原理：同一个类加载器加载同一个类只会加载一次

热部署（Hot Swap）是打破双亲委派模型的经典应用场景。先说结论：当类的代码变了，你想让JVM加载新的代码，靠"重新加载同一个类加载器"是行不通的；必须创建新的类加载器来加载新的类。

原因就在我们前面讲过的findLoadedClass机制。一个类加载器加载过一个类之后，它会一直缓存住这个类的Class对象，之后再有相同名字的加载请求，它直接返回缓存的Class对象，根本不会重新去读.class文件。系统重新加载之前，应用服务器的逻辑是——禁用旧的类加载器，新建一个类加载器来加载所有的类。旧的类加载器没有被显式销毁，但如果没有任何对象引用它们，它们可以被GC回收。

这就要说到Tomcat的实践了。Tomcat每部署一个Web应用，就创建一个WebAppClassLoader。应用更新时，就把这个类加载器丢掉，再new一个新的出来，让新的WebAppClassLoader去加载更新后的类。由于不同类加载器加载的类是互相隔离的，新的类加载器里加载到的就是最新版本的类，不会命中旧ClassLoader的缓存。

热部署对类的"隔离"和"覆盖"设计有很高的要求。如果每次热部署都创建新的类加载器，但旧的类加载器又没有及时垃圾回收，时间久了就可能导致永久代/元空间内存溢出。这在老版本Resin经常出现，因为Resin的类加载器是"重型的"，每次发布web应用都有严格的内存控制。如果是Spring Boot的devtools，它的思路也类似，不过它有两层类加载器，外层加载第三方依赖，内层加载开发者自己的代码。只有内层类加载器在代码变更时会被替换，第三方jar包不变就不动——这样重启速度快得多。这是Spring Boot devtools设计的精华所在。

5.3 Tomcat类加载器体系：优先自己加载，再向上委派

对于日常开发来说，Tomcat的类加载器是最能让你感受到类加载器实力范本的东西。它的目录结构本身就暗示了加载顺序：

code复制WEB-INF/classes   → 你项目自己的.class文件
WEB-INF/lib       → 你这个web应用依赖的jar包

Tomcat的WebAppClassLoader加载顺序是：

从JVM的bootstrap类中找（避免核心类被覆盖）
从WEB-INF/classes中找
从WEB-INF/lib的jar包中找
以上都找不到，才委派给父加载器（AppClassLoader）及其他

注意第2、3步优先级非常高，比系统classpath还要高。这意味着如果web应用的WEB-INF/lib里放了某个jar包，系统classpath里也有，web应用会优先使用自己目录里的那份。这就是很多开发环境和老项目出现"类重复"问题根源：系统classpath里放了老版本的jar，WEB-INF/lib里又放了新版本的，然后就发生方法签名不匹配之类的诡异报错。这时候你第一时间就要排查Tomcat类加载顺序。

6. 从NoClassDefFoundError看类加载问题排查思路

类加载相关的异常可能是Java开发中遇到的最让我头疼的一类问题。因为它的报错信息很"委婉"，不太直接。但如果我们理解类加载机制，排查的思路就会清晰很多。

6.1 ClassNotFoundException和NoClassDefFoundError的区别

这两个异常是Java程序员最容易搞混的，实际上它们的本质完全不同：

对比项	ClassNotFoundException	NoClassDefFoundError
类型	受检异常（Exception）	错误（Error）
触发时机	类加载过程动态查找时找不到类，抛出	编译期存在、运行期加载失败（类定义找不到）
常见原因	Class.forName、ClassLoader.loadClass、ClassLoader.findSystemClass 显式加载不到	依赖的类在编译后缺失，或者静态初始化失败
排查方向	classpath路径、jar依赖、类名拼写	编译产物是否完整、依赖版本是否冲突、静态初始化块是否抛异常

NoClassDefFoundError的经典场景是这样一个案例：你编译运行了一个依赖某个jar的类，后来这个jar被移除了，运行时报了NoClassDefFoundError。错误信息里的类可能只是某个方法内部用到的类，并非自己写的那个类。

更坑的是另一种情况：某个类的静态初始化块抛了异常，导致类初始化失败。之后凡是引用了这个类的代码，都会报NoClassDefFoundError。这是JVM的"快速失败"机制——类初始化失败后，JVM会认为这个类不可用，后续加载请求都直接抛错。排查的时候除了看classpath，还要重点检查静态块的逻辑，比如有没有访问不存在的资源文件、有没有配置项没加载进来就初始化了。

再来一个用户常遇到的现象：UnknownSourceFile（UnsupportedClassVersionError） 其实是另一个类错误。运行环境JDK版本过低（比如用JDK 8运行编译版本为17的class文件），在报告UnsupportedClassVersionError之前可能还夹杂诸多的“OutofMemoryError: insufficient memory”导致JVM极度不稳定。这类版本不兼容的问题能通过编译版本配置（如-source/-target/--release）规避不少。可悲的是，很多生产环境的问题集合里，OutOfMemoryError和类加载问题常常同时出现，定位时容易互相掩盖。

排查方法并不会太多花样，推荐从下面几个维度找：

确认类的Jar包是否存在于classpath
用-verbose:class启动JVM，观察运行时类加载日志，能直接看到每个类从哪个jar加载的
检查静态初始化块，用-XX:+TraceClassLoading也可以观测
检查JDK版本是否兼容

6.2 实际案例：一个Spring Boot应用启动时的"NoClassDefFoundError"

我之前处理过一个比较典型的线上问题。一个Spring Boot 2.x应用，在某个环境启动正常，换了个环境就一直启动失败，报错信息是：

code复制java.lang.NoClassDefFoundError: org/springframework/boot/web/embedded/tomcat/TomcatServletWebServerFactory

第一反应是这个类缺失了？但奇怪的是，代码里引用了Tomcat的embedded jar，而且这个jar就在classpath里。

后来排查发现，是JVM内存配置的问题：环境启动脚本加了-XX:MaxMetaspaceSize=64m，元空间明显不够用。Tomcat的类加载器创建了大量类，合并元空间之后OOM了。在OOM之前JVM的内部状态已经不稳定，类初始化进入"失败"状态，后续加载就狂报NoClassDefFoundError。

这个案例给我最大的启发：类加载相关的错误，不要只盯着类本身。先看JVM内存状态，再看classpath里的依赖，最后才是代码自身逻辑。 尤其是线上环境里，NoClassDefFoundError经常和Metaspace OOM绑定出现。元空间存的就是类的元数据，类加载器加载的每个类都会占元空间。一旦元空间打满，即使老年代和年轻代都还活着，JVM也会在尝试加载新类时直接OOM然后报NoClassDefFoundError。排查这类问题，用jstat -gcutil看一眼Metaspace的使用率，比盯着错误日志瞎猜可靠得多。

6.3 用 `-verbose:class` 和 `-XX:+TraceClassLoading` 做现场监控

当问题反复出现而无法准确判断时，建议直接开启类加载追踪日志。JVM参数：

bash复制java -verbose:class -XX:+TraceClassLoading -jar app.jar

不过这里有个细节要注意：-verbose:class是观察类加载的基本参数，而-XX:+TraceClassLoading是HotSpot VM扩展参数，两个可以同时开。输出会非常啰嗦，基本每个类的加载都会打一行日志：

code复制[Opened /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar]
[Loaded java.lang.Object from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar]
[Loaded java.io.Serializable from /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/rt.jar]
...

看到哪一行之后就报错了，或者哪些类没有加载日志，基本就能确定加载链路上哪里断了。这种土办法虽然没有高级APM那么自动化，但在排查类加载问题时非常直接有效。

如果你是排查线上问题，还能进一步配合jstack看线程状态——如果大量线程都阻塞在ClassLoader的锁上，说明有并发加载或加载顺序死锁。两个不同类加载器互相等待对方加载类，会出现死锁情况。这种情况在自定义类加载器违反委派规律时可以见到，是个非常隐蔽的坑。

7. 类加载器的几个进阶场景与经验总结

7.1 加密类加载器：让class文件不可被反编译

自定义类加载器除了打破双亲委派做热部署，还有一个真实场景是加密class文件。商业软件经常这么做：把class文件加密后分发，运行时用自定义类加载器解密并加载。

思路大概是：

编译好的.class文件用AES/DES等算法加密
自定义ClassLoader的findClass逻辑里读取加密文件
解密后用defineClass()把字节数组转为Class对象

核心方法defineClass是ClassLoader提供的受保护方法，签名如下：

java复制protected final Class<?> defineClass(String name, byte[] b, int off, int len)

有了自定义类加载器，加载流程中"读取字节码"这个环节完全可以换装。双亲委派模型管的是"请求怎么传递"，而"字节码从哪里来、长什么样"其实由子类控制。加密、解密、网络传输，都可以放在findClass里做。

我实际做过一个基于AES加密的类加载器，关键代码思路如下：

java复制public class CryptoClassLoader extends ClassLoader {

    private final String password;

    public CryptoClassLoader(ClassLoader parent, String password) {
        super(parent);
        this.password = password;
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        try {
            byte[] encrypted = readEncryptedBytes(name);
            byte[] decrypted = decrypt(encrypted, password);
            return defineClass(name, decrypted, 0, decrypted.length);
        } catch (Exception e) {
            throw new ClassNotFoundException("无法解密加载类: " + name, e);
        }
    }
}

注意，这种实现并没有破坏双亲委派——仍然遵循"先让父加载器加载，加载不到时调用findClass"的顺序。这也是实际业务里"自定义加载器"最常见的安全合规姿势。

7.2 沙箱隔离：为什么OSGi和容器都要自定义类加载器

把话题拉大一点。OSGi框架和Spring Boot Fat Jar的类加载器设计，都有它们自己的考虑。

OSGi的核心诉求是模块化与服务热插拔。每个Bundle（模块）都有独立的类加载器。Bundle之间通过Import-Package和Export-Package声明依赖关系。这种模式下，每个Bundle的类加载器不再完全遵循双亲委派的"自下而上"流程，而是在"查找已导入的Package"和"优先从自身Bundle加载"之间做动态决策，实现真正的模块隔离和版本独立。

具体到Spring Boot，它的Fat Jar（可执行Jar）用JarLauncher做了一层很精巧的封装。它的LaunchedURLClassLoader把嵌套在Fat Jar内部的依赖jar加载起来。大家经常下载的开源Spring Boot项目，启动入口根本不是你的@SpringBootApplication类，而是org.springframework.boot.loader.JarLauncher。启动源码在LaunchedURLClassLoader这一步。这是一个“看着像普通URLClassLoader其实内嵌了自定义的目录查找逻辑”的版本。由于Fat Jar里的库路径都被封装了，所以这个类加载器就是“按自己的节奏”加载嵌套jar的类。

这套设计真正解决了依赖打包与运行的分发问题——你发给别人的就是一个jar，别人直接java -jar就能跑，不用管classpath怎么配。这就是类加载器"隔离"价值的直接体现。

7.3 常见面试题汇总与作答要点

既然开头就说了这个知识点面试必考，那最后我按面试官提问的思路，把相关题目汇总一下，也给大家提个醒——真正的面试官其实更看重你是否真正理解机制背后的动机，而不只是背流程：

Q1：什么是双亲委派模型？

答题要点：描述三个内置加载器的层级关系——启动类加载器、扩展/平台类加载器、应用类加载器。子加载器收到加载请求先委派给父加载器，父加载器加载不了才由自己加载。引用源码loadClass()说明流程。

Q2：为什么要用双亲委派模型？

答题要点：防止核心类被自定义类覆盖，保证类唯一性和类型安全；避免类重复加载，节省内存；保证类加载结果的可预期性。

Q3：怎么打破双亲委派模型？

答题要点：重写loadClass()方法，替换默认委派逻辑；典型场景如线程上下文类加载器（SPI）、Tomcat WebAppClassLoader（优先加载自身目录）、热部署自定义类加载器。线程上下文类加载器是JDK自身提供的"官方破坏机制"。

Q4：ClassNotFoundException和NoClassDefFoundError有什么区别？

答题要点：按前面表格的思路说，重点强调NoClassDefFoundError的"运行时缺陷"特性（依赖缺失、静态初始化失败、元空间OOM），并说明排查方法。

Q5：如何实现热部署？

答题要点：新建ClassLoader实例替换旧的ClassLoader，利用"类加载器隔离"让同名类在不同加载器中成为不同类型。注意内存释放，避免元空间泄漏。

7.4 关于类加载器，我的几条踩坑经验

做类加载器相关的工作久了，我发现很多坑其实是可以提前避开的：

第一，不要随便把第三方jar拷贝到JDK的lib目录或ext目录。 这会严重影响委托链的整洁性，也让问题难以排查。扩展类加载器的加载优先级比应用类加载器高，一旦它加载了某个类，你的classpath里的"高版本"jar可能根本不会被用到，甚至直接冲突。

第二，使用自定义类加载器前先确认父加载器是谁。 ClassLoader默认的父加载器是sun.misc.Launcher$AppClassLoader。但在某些框架容器（如Tomcat）里，你的代码跑在WebAppClassLoader中，它的父加载器和纯Java环境的截然不同。如果想当然地认为"父加载器一定是AppClassLoader"，会出现很多莫名奇妙的加载顺序问题。

第三，关于如何删除一个类加载器，真实答案可能让人失望——JVM没有提供直接销毁类加载器的API，你只能让它不再被引用，靠GC回收。 所以热部署如果没考虑内存释放，旧的类加载器因为被各种ThreadLocal、静态变量引用而无法回收，元空间就会慢慢被占满，到最后就是Metaspace OOM。有一次生产环境几乎每天都要重启一次，就是因为这个问题，后来在所有静态容器和线程上下文里清理了旧的类加载器引用，才彻底解决。

第四，关于Spring Boot的类加载器，容易踩的坑是——很多插件依赖的类在boot应用hot重载（devtools）后，由于类加载器不同导致Unable to load class报错。 最开始我不是很理解，后来查了官方资料才知道，devtools默认会启用一个restart类加载器来加载项目本地类。第三方依赖（非热加载类）还是默认的类加载器加载。改完代码重启后，项目类由新restart加载器加载，但某些接口可能还是被旧的restart加载器加载的，这就产生了跨类加载器引用。所以排查这类问题，先看看是不是类加载器不同导致的ClassCastException或者NoClassDefFoundError。

关于类加载器的最后一层体会：它就像一个国家的户籍系统，每个类在哪里注册的、归属谁管，有严格的规则，但这套规则在特殊情况下也能被打破，前提是你能说清楚打破的理由。搞懂了这些，再看那些隐藏在各种框架底层的诡异类报错，心里就有底了。