定义

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。

双亲委派模型的工作过程是：

• 如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成。

• 每一个层次的类加载器都是如此。因此，所有的加载请求最终都应该传送到顶层的启动类加载器中。

• 只有当父加载器反馈自己无法完成这个加载请求时（搜索范围中没有找到所需的类），子加载器才会尝试自己去加载。

很多人对“双亲”一词很困惑。这是翻译的锅，，，“双亲”只是“parents”的直译，实际上并不表示汉语中的父母双亲，而是一代一代很多parent，即parents。

作用

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。因此，使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处：类随着它的类加载器一起具备了一种带有优先级的层次关系。

例如类java.lang.Object，它由启动类加载器加载。双亲委派模型保证任何类加载器收到的对java.lang.Object的加载请求，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。

相反，如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为java.lang.Object的类，并用自定义的类加载器加载，那系统中将会出现多个不同的Object类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

结构

系统提供的类加载器

在双亲委派模型的定义中提到了“启动类加载器”。包括启动类加载器，绝大部分Java程序都会使用到以下3种系统提供的类加载器：

• 启动类加载器（Bootstrap ClassLoader）

负责将存放在＜JAVA_HOME＞/lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机按照文件名识别的（如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。

启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。

JDK中的常用类大都由启动类加载器加载，如java.lang.String、java.util.List等。需要特别说明的是，启动类Main class也由启动类加载器加载。

• 扩展类加载器（Extension ClassLoader）

由sun.misc.Launcher$ExtClassLoader实现。

负责加载＜JAVA_HOME＞/lib/ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库。

开发者可以直接使用扩展类加载器。

猴子对自己电脑＜JAVA_HOME＞/lib/ext目录下的jar包都非常陌生。看了几个jar包，也没找到常用的类；唯一有点印象的是jfxrt.jar，被用于JavaFX的开发之中。

• 应用程序类加载器（Application ClassLoader）

由sun.misc.Launcher$AppClassLoader实现。由于这个类加载器是ClassLoader.getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。

它负责加载用户类路径ClassPath上所指定的类库，开发者可以直接使用这个类加载器。如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

启动类Main class、其他如工程中编写的类、maven引用的类，都会被放置在类路径下。Main class由启动类加载器加载，其他类由应用程序类加载器加载。

自定义的类加载器

JVM建议用户将应用程序类加载器作为自定义类加载器的父类加载器。则类加载的双亲委派模型如图：

image.png

实现原理

实现双亲委派的代码都集中在ClassLoader#loadClass()方法之中。将统计部分的代码去掉之后，简写如下：

• 首先，检查目标类是否已在当前类加载器的命名空间中加载（即，使用二元组<类加载器实例，全限定名>区分不同类）。

• 如果没有找到，则尝试将请求委托给父类加载器（如果指定父类加载器为null，则将启动类加载器作为父类加载器；如果没有指定父类加载器，则将应用程序类加载器作为父类加载器），最终所有类都会委托到启动类加载器。

• 如果父类加载器加载失败，则自己加载。

• 默认resolve取false，不需要解析，直接返回。

自定义类加载器的正确姿势

系统提供的3种类加载器分别负责各路径下的Java类的加载。如果用户希望自定义一个类加载器（如从网络中读取class字节流，以加载新的类），该如何做呢？

错误姿势

先来看几个类加载的错误姿势。

再次提醒，以下这些错误姿势一定不影响编译，因为加载行为发生在运行期。

不定义类加载器

现在用户自定义了一个sun.applet.Main类，但不定义类加载器：

为保持与后续实验的连贯性，这里没有选择常用的java.lang包下的类。原因见后。

将该类作为Main class启动，会输出什么呢？或许你以为会输出12-13行声明的字符串，现实却总会啪啪啪抚摸我们的脸庞：

不管这些东西从哪来的，总之不是我们定义的。

实际被选中的Main class是jdk中的sun.applet.Main类。如果没有定义类加载器，则会使用默认的类加载器（应用程序类加载器）和默认的类加载行为（ClassLoader#loadClass()）。由双亲委派模型可知，最终将由启动类加载器加载＜JAVA_HOME＞/lib/rt.jar中的sun.applet.Main，并执行其main方法。

定义类加载器，但不委派

如何不委派呢？覆写ClassLoader#loadClass()：

当然，还要覆写ClassLoader#findClass()以支持自定义的类加载方式。

注意16-19行。由于jdk对"java."开头的包增加了权限保护，用户无法使用示例中的ClassLoader#defineClass()方法；而所有类都是java.lang.Object类的子类，sout输出时也要使用java.lang.System类等，所以我们又必须加载java.lang包下的类。因此，我们仍然将这些包委托给jdk加载。

同时，这也解释了，为什么不能将常用的java.lang包下的类作为同名类测试对象。

示例先加载jdk中的sun.applet.Main类，实例化main1，再使用不进行委派的自定义类加载器加载自定义的sun.applet.Main类，实例化main2。如果实例main2创建成功，则输出“constructed”。之后，输出main1、main2的类名和类加载器。

输出：

首先，1行说明实例main2创建成功了。2-3行表示main1、main2的全限定名确实相同。4-5行表示二者的类加载器不同，main1的类使用启动类加载器，main2的类使用自定义的类加载器。

正确姿势

一个符合规范的类加载器，应当仅覆写ClassLoader#findClass()，以支持自定义的类加载方式。不建议覆写ClassLoader#loadClass()（以使用默认的类加载逻辑，即双亲委派模型）；如果需要覆写，则不应该破坏双亲委派模型：

因为在自定义类加载器上正确使用了双亲委派模型，上述代码运行后，不会出现相同全限定名的类被不同类加载器加载的问题，也就不会引起混乱了.

输出：

在双亲委派模型下，运行时中只存在启动类加载器加载的sun.applet.Main类。

5-6行输出了类加载器在双亲委派模型中的位置：最下层是自定义类加载器，然后逐层向上是应用程序类加载器、扩展类加载器，最上层是启动类加载器（在扩展类加载器中记为null）。可与前面的结构图对照。

不过，实际情况中，覆写ClassLoader#loadClass()是非常常见的。JNDI、OSGi等为了实现各自的需求，也在一定程度上破坏了双亲委派模型。

双亲委派模型

原文：https://www.cnblogs.com/lynn16/p/10713484.html