一、先搞懂：什么是双亲委派机制？

很多人第一次听到 “双亲委派”，会误以为是 “父加载器 + 母加载器” 的继承关系 —— 其实完全不是！它本质是 JVM 加载类时的一套 **“向上委托、向下查找” 的规则 **，核心逻辑可以总结为一句话：

当一个类加载器需要加载某个类时，它不会先自己动手，而是先把加载请求 “上报” 给它的 “父加载器”；只有当父加载器说 “我找不到这个类，加载不了”，子加载器才会自己尝试加载。

这里的 “双亲” 不是字面意义的继承，而是逻辑上的委托层级。打个比方：就像你在公司遇到一个问题，会先找直属领导（父加载器）解决；领导解决不了，再找他的领导（更上层父加载器）；如果所有领导都解决不了，才会回到你这里，由你自己处理。

二、三大核心类加载器：双亲委派的 “骨架”

双亲委派机制能跑起来，全靠 JVM 默认提供的三个核心类加载器（注：JDK 9 + 引入模块系统，加载器结构有调整，但核心逻辑不变，本文以经典的 JDK 8 为例）。

这三个加载器就像 “三级部门”，各司其职，又通过委托关系形成统一的加载体系。

1. 三个加载器的 “职责清单”

类加载器名称	加载范围（负责的类）	父加载器	通俗理解
启动类加载器	JRE 核心类（如java.lang.Object、java.util.ArrayList）	无（C++ 实现）	公司 “总部”，只管最核心的业务
（Bootstrap ClassLoader）	具体路径：JRE/lib/rt.jar、resources.jar等核心 jar 包
扩展类加载器	JRE 扩展功能类（非核心，但补充核心能力）	启动类加载器	公司 “分部”，管核心之外的扩展业务
（Extension ClassLoader）	具体路径：JRE/lib/ext目录下的所有 jar 包
应用类加载器	我们自己写的代码、第三方依赖（如 Spring、MyBatis）	扩展类加载器	公司 “项目组”，管具体的业务代码
（Application ClassLoader）	具体路径：classpath（项目编译后的 class 文件、lib目录下的依赖 jar）

这里有个关键细节：启动类加载器是用 C++ 写的，无法被 Java 代码直接访问（比如你想通过getClass().getClassLoader()获取它，得到的会是null），而扩展类加载器和应用类加载器是 Java 类（继承自URLClassLoader），可以被代码访问。

2. 委托流程实战：加载一个自定义类

光看表格不够直观，我们以 “加载项目中的com.example.User类” 为例，一步步看双亲委派是怎么工作的：

1. 应用类加载器接活：我们的User类在classpath下，首先由应用类加载器接收加载请求，但它不自己干，而是把请求委托给 “父加载器”—— 扩展类加载器；

1. 扩展类加载器上报：扩展类加载器收到请求后，也不自己干，继续委托给 “父加载器”—— 启动类加载器；

1. 启动类加载器检查：启动类加载器去自己的 “管辖范围”（JRE/lib/rt.jar等）找com.example.User，发现没有这个类，于是 “拒绝加载”，把请求退回给扩展类加载器；

1. 扩展类加载器检查：扩展类加载器去自己的 “管辖范围”（JRE/lib/ext）找，也没有User类，同样 “拒绝加载”，把请求退回给应用类加载器；

1. 应用类加载器干活：应用类加载器去classpath下找，终于找到了com.example.User.class文件，成功加载这个类。

整个流程就像 “逐级上报、逐级退回、最后执行”，确保了 “核心加载器优先” 的原则。

三、双亲委派的两大 “王牌” 好处：安全与唯一

为什么 JVM 要设计这么一套 “绕弯子” 的机制？不是为了复杂，而是为了解决两个核心问题：防止核心类被篡改和保证类的唯一性。这两个好处，也是双亲委派机制的 “灵魂”。

好处 1：防止核心类被篡改 ——JVM 的 “安全盾”

Java 的核心类（如java.lang.String、java.lang.Object）是所有程序的基础，如果这些类被恶意篡改（比如自定义一个java.lang.String，在equals方法里植入恶意代码），整个程序的安全都会被击穿。

双亲委派机制通过 “核心加载器优先加载”，从根本上堵死了这个漏洞。我们举个实战例子：

假设你故意在项目里写了一个恶意的java.lang.String类：

package java.lang;

public class String {

// 恶意代码：比如打印敏感信息

public String() {

System.out.println("恶意String被加载！");

}

}

当你尝试运行程序时，会发现这个恶意类永远不会被加载 —— 原因如下：

1. 应用类加载器收到加载java.lang.String的请求，先委托给扩展类加载器；

1. 扩展类加载器再委托给启动类加载器；

1. 启动类加载器在JRE/lib/rt.jar里找到了 “正版” 的java.lang.String，直接加载正版类；

1. 既然父加载器已经加载成功，应用类加载器就不会再加载你写的恶意类了。

就这样，双亲委派像一道 “安全盾”，确保我们用的永远是 JVM 官方的核心类，避免了恶意篡改的风险。

好处 2：保证类的唯一性 —— 避免 “类混乱”

在 Java 中，一个类的 “身份” 不是由全限定名（如com.example.User）单独决定的，而是由 **“类加载器 + 全限定名”** 共同决定的。也就是说：同一个类被不同的加载器加载，会被视为两个完全不同的类，进而导致ClassCastException（类型转换异常）等诡异问题。

双亲委派机制通过 “统一加载源”，完美解决了这个问题。我们再举个实际场景：

假设你的项目里引入了两个不同版本的 Spring 依赖：spring-core-5.0.jar和spring-core-6.0.jar，这两个 jar 里都有org.springframework.context.ApplicationContext类。如果没有双亲委派：

• 应用类加载器可能会从两个 jar 里分别加载ApplicationContext类，形成两个不同的 “身份”；

• 当你在代码中把 6.0 版本的ApplicationContext对象赋值给 5.0 版本的引用时，就会抛出ClassCastException，因为 JVM 认为它们是两个不同的类。

而有了双亲委派，情况就不一样了：

1. 应用类加载器委托扩展类加载器，扩展类加载器再委托启动类加载器 —— 两者都加载不了ApplicationContext；

1. 最终回到应用类加载器，它会按照classpath的优先级（比如 Maven 的依赖顺序），只加载第一个找到的ApplicationContext类（比如先加载 5.0 版本）；

1. 后续所有需要ApplicationContext的地方，都会复用这个已经加载好的类，不会重复加载，自然也就不会出现 “类身份混乱” 的问题。

更关键的是，像java.lang.Object这样的核心类，只会被启动类加载器加载一次 —— 无论多少个子加载器请求，最终都复用同一个Object类，确保了所有类的 “父类” 都是唯一的，避免了整个类体系的混乱。

四、延伸：JDK 9 + 的小变化（不影响核心）

前面我们说的是 JDK 8 及之前的经典模型，JDK 9 引入了模块系统（Module System），对类加载器做了一些调整：

• 移除了 “扩展类加载器”，换成了 “平台类加载器（Platform ClassLoader）”；

• 启动类加载器不再只加载rt.jar，而是加载 JDK 的核心模块（如java.base模块）；

• 但核心的 “双亲委派逻辑” 没有变：依然是子加载器先委托父加载器，父加载器加载不了再自己加载。

所以不管 JDK 版本怎么变，理解了经典的双亲委派机制，就能轻松应对新版本的调整。

五、总结：记住这 3 个核心点

看到这里，相信你已经对双亲委派机制有了清晰的认识。最后我们用 3 句话总结核心：

1. 核心逻辑：子加载器先委托父加载器，父加载器加载失败，子加载器才自己加载；

1. 加载器关系：启动类加载器（顶层）→ 扩展 / 平台类加载器 → 应用类加载器（底层），构成委托层级；

1. 核心价值：防止核心类篡改（安全）、保证类唯一性（避免混乱），是 Java 程序稳定运行的基石。

下次再遇到 “自定义核心类不生效”“类转换异常” 等问题，不妨先想想：是不是双亲委派机制在起作用？理解了它，很多 Java 底层问题都会迎刃而解。

如果你在实际开发中遇到过类加载相关的问题，或者对双亲委派有其他疑问，欢迎在评论区留言讨论！