类加载器与双亲委派

站在Java虚拟机的角度来看，只存在两种不同的类加载器
一种是启动类加载器(Bootstrap ClassLoader)，这个类加载器使用C++语言实现[1]，是虚拟机自身的一部分;
另外一种就是其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类 java.lang.ClassLoader。

启动类加载器 (Bootstrap ClassLoader)，由C++实现，没有父类。
主要负责加载核心的类库(java.lang.*等)，构造ExtClassLoader和APPClassLoader。
拓展类加载器(ExtClassLoader)，由Java语言实现
主要负责加载jre/lib/ext目录下的一些扩展的jar。
系统类加载器(AppClassLoader)，由Java语言实现
主要负责加载应用程序的主函数类
自定义类加载器，父类加载器肯定为AppClassLoader

双亲委派机制：

双亲委派机制，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式，即每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己才想办法去完成。

从上图中我们就更容易理解了，当一个Hello.class这样的文件要被加载时。不考虑我们自定义类加载器，首先会在AppClassLoader中检查是否加载过，如果有那就无需再加载了。如果没有，那么会拿到父加载器，然后调用父加载器的loadClass方法。父类中同理也会先检查自己是否已经加载过，如果没有再往上。注意这个类似递归的过程，直到到达Bootstrap classLoader之前，都是在检查是否加载过，并不会选择自己去加载。直到BootstrapClassLoader，已经没有父加载器了，这时候开始考虑自己是否能加载了，如果自己无法加载，会下沉到子加载器去加载，一直到最底层，如果没有任何加载器能加载，就会抛出ClassNotFoundException。

为什么要设计这种机制

这种设计有个好处：如果有人想替换系统级别的类：String.java。篡改它的实现，在这种机制下这些系统的类已经被Bootstrap classLoader加载过了（因为当一个类需要加载的时候，最先去尝试加载的就是BootstrapClassLoader），所以其他类加载器并没有机会再去加载，从一定程度上防止了危险代码的植入。

确保jvm中类的唯一性；
保证类安全：解决包冲突:如果每个加载器自己去加载则会导致jdk最底层的行为无法保证，保证jvm只有一个Object对象；能编译但不会使用；
优先级的层次分明：解耦，职责分明，为扩展提供可能；每个加载器做自己的事情；
统一管理：rt.jar

判断是否是同一个类：类加载器 + 类包名 + 类名