双亲委派模型，是加载class文件的一种机制。在介绍双亲委派模型之前，我需要先介绍几种类加载器（Class Loader）。
1，类加载器
Bootstrap，加载lib/rt.jar，charset.jar等中的核心类，由C++实现。其实就是加载的我们通常部署的jdk中的jar包。
Extension，加载扩展包，jre/lib/ext/*.jar，或者由-Djava.ext.dirs指定。pom中通过maven引入的依赖，就是由Ext类加载器加载而来。
App，加载classpath指定内容。就是加载我们自己编写的java类编译出来的class文件，这些类文件在idea中在target包下，在idea中可以查看和设定classpath的路径：
Custom，自定义类加载器，自定义的class loader。继承ClassLoader这个抽象类，重写findClass()方法即可实现自定义类加载器。
2，双亲委派机制
双亲委派机制是JVM加载并初始化class文件的机制，即JVM流程：Loading->Linking->Initializing中的Loading这一部分的机制。
双亲委派机制的流程如下：
在传入类的全限定名后，如java.lang.Object，JVM会首先去寻找类的class文件，挨个加载器去看看是否已经加载（前文已经说过类加载器加载类的范围不同），寻找顺序由下到上；
从下到上找了一遍都没有找到，说明该类的class文件不在JVM中就会从上到下的去让加载器尝试加载，如果该类不是这个加载器的范围，就不会加载，否则，加载器就会将这个类加载到JVM中。
双亲委派机制实质上是对类加载器的权限做了分级，并按照分级来进行寻找或加载。
3，Q&A
3.1，为什么双亲委派机制要区分不同的类加载器，使用一个加载器加载所有class文件不行吗？
使用不同的类加载器并进行加载权限上的区分，主要的作用是为了安全，试想一下，当使用一个加载器加载所有class文件时，那么加载权限上的混淆，使得这个加载器就可以自定义一个如java.lang.Object的类并加载，覆盖掉本来的object，这无疑是无法接受的。这就需要更重要的资源如jdk的class文件由单独一个类加载器加载，并且无法被其他加载器覆盖。
3.2，双亲委派机制为什么要这样从下到上的寻找、再从上到下的加载呢？
同样，也是为了安全。
为什么从上到下的加载？
比如我们还是自定义一个java.lang.Object，应该由Custom Classloader加载，如果不是优先由Bootstrap Classloader加载，而是Custom Classloader优先加载，那么会出现什么情况？custom加载后，就不会继续去bootstrap中加载，因为它会认为已经加载完毕了！所以，更重要的资源，应该优先加载，因此，jdk中的类->pom引入的依赖->自己编写的类编译出来的class文件(target目录中的class文件)->自定义加载器加载(可以自定义加载文件的位置和加载方式)
为什么要从下到上的寻找？
这里我的理解就是，如果有自定义的加载器，我们肯定是希望优先使用我们自定义的custom加载器的。如果没有，剩下App、Ext、Bootstrap三个加载器。这三个加载器，更重要的资源被加载过的可能性更大，因此查找的顺序放在后面；而如App加载自己编写的类的class文件，没有被加载过的可能性更大，因此优先查找。
3.3，双亲委派机制叫这个名字，是因为这些类是从上到下的继承关系吗？
并不是。双亲委派机制，名字翻译的不好，实际上这个机制就是指的孩子向父亲委派、父亲向孩子委派的过程。
实质上，Bootstrap是由C++实现的组件，Custom可以自定义一个继承抽象类ClassLoader，重写findClass()方法即可。而App和Ext，不是继承的关系，如下图：
3.4，能不能打破双亲委派机制
可以的。在自定义Custom类加载器，重写findClass()方法时，当找不到类时不要去向上寻找App类加载器，自然也就打破了双亲委派机制。
4.ClassLoader源码片段
ClassLoader是一个抽象类，其中寻找class文件的loadClass方法，从中可以一窥双亲委派的机制（Ext没有重写这个方法，使用的就是ClassLoader的这个方法）。
注意这里的parent指的是查找顺序上的parent，而不是通常所指的继承关系上的parent。
