双亲委派机制

3.2.2. 双亲委派机制

1）双亲委派介绍
双亲委派的理念：在当前类加载器的缓存中寻找是否加载过该类，没有则向父加载器中继续寻找，一直到顶层加载器为止，如果没有则再交由子加载器处理，一直到自定义类加载器为止，如果还没有找到则抛出ClassNotFindException。

双亲委派的具体流程：加载类时Custom ClassLoader先检查自己的缓存，如果没有则向他的父加载器APPlication的缓存中查找，如果有就返回结果，没有就继续向APP的父加载器Extension的缓存中查找，如果有就返回结果，如果没有就继续向Extension的父加载器BootStrap的缓存中查找，如果有就返回结果，如果没有就通过BootStrap的子加载器Extension进行查找，如果能找到该类则进行加载并返回结果，如果没有继续通过Extension的子加载器APP进行查找，如果找到该类则进行加载并返回结果，如果没有则继续通过APPlication的子加载器Custom ClassLoader进行查找，如果找到则进行加载并返回结果，否则抛出异常ClassNotFindException。

2）注意事项
双亲委派并不是指存在类似于继承的关系，只是存在两个过程，从子到父在cache中查找是否已经加载过该类和从父到子在各自指定的加载路径下是否能找到并加载该类。
3）使用双亲委派机制的原因
a . java类随着类加载一起具备了一种优先级的层次关系，通过这种层次关系可以避免类的重复加载，当父类中已经加载了该类时，子类中就没必要再次加载。
b. 为了系统类的安全，java核心API库中定义的类型不会被随意篡改。例如，“java.lang.Object”这种核心类，jvm需要保证他们生成的对象都会被认定为同一种类型。双亲委派中，对于java核心库的类的加载工作由BootStrap启动类加载器来统一完成，保证了所使用的都是同一个版本的java核心库的类。
4）面试题：能不能自己写个类叫java.lang.System
不可以，但是可以通过另类方法达到这个需求。
因为类加载器采用双亲委派机制，就造成父加载器会优先于子加载器进行加载类，System类是由Bootstrap启动类加载器进行加载的，所以总使用java系统提供的System，自己实现的System类永远不会被加载。
由于系统自带的三个类加载器都加载特定目录下的类，如果我们自己的类加载器加载的是一个特殊的目录，那么系统的加载器就无法加载，也就是最终由我们自定义的加载器进行加载，这样就可以实现要求。
5）面试题：能不能写个类叫java.lang.aa并放在classpath路径下呢
java.lang是核心API包，需要访问权限，强制加载会出现下面异常：java.lang.SecurityException: Prohibited package name: java.lang。
6）jvm如何认定两个对象属于同一个类型
a.都是用同名的类完成实例化；
b.两个实例各自对应的类加载器必须是同一个。例如，两个相同名字的类，但是一个类是由APPlication系统加载器加载的，另外一个是由Extension扩展加载器加载的，那么两个类生成的实例对象将被JVM认为不同类型的对象。
7）如何打破双亲委派
通过重写loadClass()方法打破双亲委派。
8）打破双亲委派的场景
场景1，JDK1.2之前，自定义ClassLoader都必须重写loadClass(),
场景2，ThreadContextClassLoader可以实现基础类调用实现类代码，通过thread.setContextClassLoader指定。
场景3，热启动，热部署,osgi tomcat 都有自己的模块指定classloader（可以加载同一类库的不同版本）。

3.2.3. 源码分析

3.2.3.1. 源码实现类加载器

从源码实现上来看，classLoader类是顶层类，除Bootstrap启动类加载器外，其余类加载器均继承自该类。但是从实际执行逻辑上看，是遵循双亲委派的，即 BootStrap启动类加载器是Extension扩展类加载器的父类，Extension扩展类加载器是APP应用程序类加载器的父类，APP应用程序类加载器是Custom Cla