JVM 双亲委派模型

1. 前言

上节课程的小结部分提到，双亲委派模型是加载（Loading）步骤中所使用的模型，上节内容为本节内容的基础知识，学习本节内容之前，要确保已经掌握了上节所讲解的内容。本节主要知识点如下：

• 了解双亲委派模型的示意图，是本节课程的基础知识；
• 掌握双亲委派模型的工作原理，并结合示意图进行理解，为本节内容的核心知识点；
• 举出三个不同类型的案例供学习者参考，更深入的了解双亲委派模型的工作原理，为本节内容的重点内容；

2. 双亲委派模型

在讲解双亲委派模型之前，我们先来看看双亲委派模型的示意图，相信看到如下示意图中的模块信息，学习者会感到莫名的亲切感。示意图如下：

上图中的亲切感来自哪里呢？我们可以看到在双亲委派模型中，有三种类加载器是我们上节课程中所讲解的，有了上节课程的知识积淀，再理解双亲委派模型会非常的容易。

双亲委派模型原理：

• 向上委托：如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器。如果父类加载器可以完成类加载任务，就成功返回；
• 向下委派：倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。

如果对于原理性的描述还是比较模糊的话，不要着急，我们继续学习下边的内容，通过案例体会双亲委派模型的原理。

3. 案例 1：加载 /jre/lib/resources.jar

通过上节课程的学习，我们能够知道 /jre/lib/resources.jar 是需要被启动（BootStrap）类加载器加载的核心类库，那么我们来看看它的加载流程图。

加载流程图：根据双亲委派模型，我们来看下 resources.jar 的完整加载过程。

从上图中我们可以看到，对于核心类库 resources.jar 的加载，分为以下 4 步：

• 步骤 1：resources.jar 会先通过自定义类加载器（前提是我们实现了自定义类加载器），自定义类加载器不会做处理，直接向上委托给系统（System Application）类加载器；
• 步骤 2：系统（System Application）类加载器接到委托后，也不做任何处理，直接向上委托给扩展（Extension）类加载器；
• 步骤 3：扩展（Extension）类加载器接到委托后，也不做任何处理，直接向上委托给启动（Bootstrap）类加载器；
• 步骤 4：启动（Bootstrap）类加载器接到委托后，发现 resources.jar 是自己负责加载的核心类库，于是进行加载，最后成功加载了 resources.jar。

4. 案例 2：加载 /jre/lib/ext/cldrdata.jar

通过上节课程的学习，我们能够知道 /jre/lib/ext/cldrdata.jar 是需要被扩展（Extension）类加载器加载的核心类库，那么我们来看看它的加载流程图。

加载流程图：根据双亲委派模型，我们来看下 cldrdata.jar 的完整加载过程。

从上图中我们可以看到，对于核心类库 cldrdata.jar 的加载，分为以下 5 步：

• 步骤 1：cldrdata.jar 会先通过自定义类加载器（前提是我们实现了自定义类加载器），自定义类加载器不会做处理，直接向上委托给系统（System Application）类加载器；
• 步骤 2：系统（System Application）类加载器接到委托后，也不做任何处理，直接向上委托给扩展（Extension）类加载器；
• 步骤 3：扩展（Extension）类加载器接到委托后，也不做任何处理，直接向上委托给启动（Bootstrap）类加载器；
• 步骤 4：启动（Bootstrap）类加载器接到委托后，发现 cldrdata.jar 不是自己负责加载的核心类库，于是进行向下委派，委派给扩展（Extension）类加载器；
• 步骤 5：扩展（Extension）类加载器接到委派后，发现 cldrdata.jar 是自己负责加载的核心类库，于是进行加载，最后成功加载了 cldrdata.jar。

Tips：我们可以看到，在向上委托的过程中，cldrdata.jar 虽然在步骤 3 已经达到了扩展（Extension）类加载器，但是由于扩展（Extension）类加载器需要遵循向上委托的原则，必须要将 cldrdata.jar 向上委托给启动（Bootstrap）类加载器，直到启动（Bootstrap）类加载器向下委派 cldrdata.jar 到扩展（Extension）类加载器才进行类库的加载。

5. 案例 3：加载 /jre/lib/plugin.jar

通过上节课程的学习，我们能够知道 /jre/lib/plugin.jar 是需要被系统（System Application）类加载器加载的核心类库，那么我们来看看它的加载流程图。

加载流程图：根据双亲委派模型，我们来看下 plugin.jar 的完整加载过程。

从上图中我们可以看到，对于核心类库 plugin.jar 的加载，分为以下 6 步：

• 步骤 1：plugin.jar 会先通过自定义类加载器（前提是我们实现了自定义类加载器），自定义类加载器不会做处理，直接向上委托给系统（System Application）类加载器；
• 步骤 2：系统（System Application）类加载器接到委托后，也不做任何处理，直接向上委托给扩展（Extension）类加载器；
• 步骤 3：扩展（Extension）类加载器接到委托后，也不做任何处理，直接向上委托给启动（Bootstrap）类加载器；
• 步骤 4：启动（Bootstrap）类加载器接到委托后，发现 plugin.jar 不是自己负责加载的核心类库，于是进行向下委派，委派给扩展（Extension）类加载器；
• 步骤 5：扩展（Extension）类加载器接到委派后，发现 plugin.jar 也不是自己负责加载的核心类库，于是进行向下委派，委派给系统（System Application）类加载器；
• 步骤 6：系统（System Application）类加载器接到委派后，发现 plugin.jar 是自己负责加载的核心类库，于是进行加载，最后成功加载了 plugin.jar。

Tips：类似于案例 2 的讲解，虽然 plugin.jar 是系统（System Application）类加载器负责加载的，但是要遵循向上委托的原则，因此在步骤 2 不能够实时加载，只能等待父加载器向下委派时加载。

6. 小结

通过对双亲委派模型的讲解，我们了解到了双亲委派模型的定义以及原理，并通过 3 个案例详细的讲述了在双亲委派模型下是如何进行的类库的加载。

通篇皆为重点内容，所有的内容都是围绕双亲委派模型的原理展开的，需要学习者仔细品味案例，掌握双亲委派模型的原理。