双亲委派机制

什么是双亲委派模型呢 讲个故事吧！

这个故事就很离谱 很荒诞

假如小明目前可以结婚
有一天 小花请求小明说：“我们结婚吧”！
小明说：“我是没问题的，但是我要问问我爸，是不是他想和你结婚，怎么说也要长辈优先（哈哈）”
小明爸爸：“我不想，你去问问你爷爷”
小明爷爷：“开玩笑呢，我岁数大了，你别TMD逗我，你让你爸去结婚吧，单身这么多年了”
小明爸爸：“不说了吗，我不结婚”
小明:“我可给您们机会了昂，你们不来我可来了昂”
于是小明就结婚了；

这个故事的逻辑是这样的，不论小明能不能结婚，咱都走个流程，问问长辈，然后从最年长的开始选择，要是结婚，就没后面子孙啥事了，要是不结，向下顺序请求。如果都不选择结婚，那小花肯定不靠谱，谁都不认识小花。

期间还有一个过程就是，如果小花和一个人和小花结过婚了，就不会直接向上询问了，直接和小花结婚了，因为都结过婚了都是一家子了，确认没毛病了，没事还搞啥事情。

这里就是双亲委派机制
小明 AppClassLoader：主要负责加载应用程序的主函数类
爸爸 ExtClassLoader：主要负责加载jre/lib/ext目录下的一些扩展的jar。
爷爷 AppClassLoader：主要负责加载应用程序的主函数类
小花 Marry.class文件

小花开始在线请求配对啦
下面就是上图的论证

从上图中我们就更容易理解了，当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理会先检查自己是否已经加载过，如果没有再往上。注意这个过程，知道到达Bootstrap classLoader之前，都是没有哪个加载器自己选择加载的。如果父加载器无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。
为什么要设计这种机制
这种设计有个好处是，如果有人想替换系统级别的类：String.java。篡改它的实现，但是在这种机制下这些系统的类已经被Bootstrap classLoader加载过了，所以并不会再去加载，从一定程度上防止了危险代码的植入。

就是这样，小明爷爷已经和小花结婚了，但是突然有人冒充小花要结婚，根据流程到达爷爷这里的时候，爷爷说，，我草 无情啊 ，小花都是你奶奶了，搞事情啊，快点打消念头。

故事有些荒谬，不喜勿喷昂。