JVM双亲委派机制

运行java程序时，首先会通过jvm.dll创建出c++实现的java虚拟机，在C++中创建bootstrap类加载器，之后会调用java的Launcher类的getLauncher初始化方法创建出ext类加载器和app类加载器。
源码：

当类加载器初始化完毕之后，就可以加载类了。
加载类的核心方法loadClass就是双亲委派机制的核心代码

loadClass方法加载过程
1、findLoadedClass判断当前类有没有加载过
2、判断parent父加载器是否不为空，如果不为空，调用父加载器的loadClass方法进行加载，如果为空调用c++的bootstrap类加载器加载。
描述：这里第一次调用进来的类加载器是appClassLoader，可以看最开始贴的一张图，当初始化出来类加载器后，会调用getClassLoader方法获取类加载，那么这个获取到的类加载器其实就是appClassLoader，如图：

getClassLoader方法返回了当前的loader，那么当前的loader是什么呢？回到初始化的构造方法中:

所以在loadClass的方法中第一次调用进来的类加载器就是app类加载器，app类加载器的父加载是ext类加载器，如图：


调用链比较深所以就不一一截图了，只是截图了开始和最终赋值的代码，所以可以看出，父子关系其实是通过parent这个变量来做的，而不是继承的关系。
3、判断有没有加载到，如果加载到，c不等于null，基本可以认为类已经加载完了，如果c等于null，代表当前类加载器没有加载成功，那么会继续尝试使用下级的类加载器继续加载,加载的核心代码是findClass

在findClass方法中主要用来扫描你要加载的文件，如果扫描到会进行加载解析，如果扫描不到，代表加载的class不在当前类加载器的作用域中，作用域可以看launcher的初始化方法，在创建加载器时会赋值加载的路径。
这里只是简单说明一下：
bootstrap加载器主要加载jre下的jar
ext加载器主要加载jre/ext下的jar
app加载器主要加载classPath下的文件
4、当在findClass中扫描到可以被加载后，会解析class，也就是常说的类加载过程中的几个步骤：加载、验证、准备、解析、初始化等等
如果对解析过程感兴趣可以查看以前写过的一篇短文：jvm类加载过程

总结：
jvm双亲委派机制主要的流程就是要知道由哪个类加载器加载。
画了一个简单的图，供参考：

比如要加载xxx.class文件
首先通过app类加载器，app判断有没有加载过，如果有 返回已经加载的对象，如果没有，向上传递给ext，ext判断有没有加载过，如果有，返回加载的对象，如果没有，向上传递给bootstrap加载器。由bootstrap加载器尝试加载，如果加载成功，返回加载的对象，如果加载失败，向下传递，ext尝试加载，如果加载成功，返回加载的对象，如果加载失败，向下传递给app加载器加载，加载成功后返回。

思考：
jvm的双亲委派机制解决的问题
其一可以解决类重复加载的问题
其二可以解决安全方面的问题，防止jvm的底层类库被篡改，虽然你写了一个与底层文件一样的名字，但是真实加载的还是jvm的文件，而不是项目中的文件（因为加载器的顺序是从下往上查，但是在加载时是从上向下加载）
其三用appClassLoader当作默认类加载器，可能是因为项目中还是我们自己开发的文件会多一些，都是在classPath目录下的，所以按照双亲委派的这种做法当加载我们项目中的类时，直接在第一层的appClassLoader中判断是否存在，如果存在就直接可以返回出去了。

中间有些地方截图可能截图的不是很明确，特别是一些调用链以及文件的继承结构等等，如果要彻底搞清楚的话，还是需要去阅读一遍源码可能会更清晰一些。

留下人生足迹，一步一个脚印