JDK源码中的双亲委派机制

类加载器和双亲委派机制 上面的类加载过程主要是通过类加载器来实现的，Java里有如下几种类加载器 引导类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的核心类库，比如 rt.jar、charsets.jar等
扩展类加载器：负责加载支撑JVM运行的位于JRE的lib目录下的ext扩展目录中的JAR 类包
应用程序类加载器：负责加载ClassPath路径下的类包，主要就是加载你自己写的那些类自定义加载器：负责加载用户自定义路径下的类包

类加载器初始化过程： 参见类运行加载全过程图可知其中会创建JVM启动器实例sun.misc.Launcher。 sun.misc.Launcher初始化使用了单例模式设计，保证一个JVM虚拟机内只有一个 sun.misc.Launcher实例。 在Launcher构造方法内部，其创建了两个类加载器，分别是 sun.misc.Launcher.ExtClassLoader(扩展类加载器)和sun.misc.Launcher.AppClassLoader(应用类加载器)。 JVM默认使用Launcher的getClassLoader()方法返回的类加载器AppClassLoader的实例加载我们 的应用程序。
双亲委派机制 JVM类加载器是有亲子层级结构的，如下图

这里类加载其实就有一个双亲委派机制，加载某个类时会先委托父加载器寻找目标类，找不到再委托上层父加载器加载，如果所有父加载器在自己的加载类路径下都找不到目标类，则在自己的 类加载路径中查找并载入目标类。 比如我们的Math类，最先会找应用程序类加载器加载，应用程序类加载器会先委托扩展类加载器加载，扩展类加载器再委托引导类加载器，顶层引导类加载器在自己的类加载路径里找了半天没找到Math类，则向下退回加载Math类的请求，扩展类加载器收到回复就自己加载，在自己的类加载路径里找了半天也没找到Math类，又向下退回Math类的加载请求给应用程序类加载器， 应用程序类加载器于是在自己的类加载路径里找Math类，结果找到了就自己加载了。。 双亲委派机制说简单点就是，先找父亲加载，不行再由儿子自己加载

源码中应用程序类加载器AppClassLoader加载类的双亲委派机制，AppClassLoader 的loadClass方法最终会调用其父类ClassLoader的loadClass方法，
该方法的大体逻辑如下：

1. 首先，检查一下指定名称的类是否已经加载过，如果加载过了，就不需要再加载，直接返回。
2. 如果此类没有加载过，那么，再判断一下是否有父加载器；如果有父加载器，则由父加载器加载（即调用parent.loadClass(name, false);）.或者是调用bootstrap类加载器来加载。
3. 如果父加载器及bootstrap类加载器都没有找到指定的类，那么调用当前类加载器的findClass方法来完成类加载。源码如下:
4. 

为什么要设计双亲委派机制？
沙箱安全机制：例如自己写的java.lang.String类不会被加载，这样可以防止核心API库被随意更改。
避免类的重复加载：当父亲已经加载了该类时，就没有必要子ClassLoader再加载一 次，保证被加载类的唯一性

自定义类加载器使用方式示例：
自定义类加载器只需要继承 java.lang.ClassLoader 类，该类有两个核心方法，一个是 loadClass(String, boolean)，实现了双亲委派机制。还有一个方法是findClass，默认实现是空方法，所以我们自定义类加载器主要是重写findClass方法。
示例：

打破双亲委派机制
再来一个沙箱安全机制示例，尝试打破双亲委派机制，用自定义类加载器加载我们自己实现的 java.lang.String.class 实现方式很简单，将classLoader中的loadclass方法重写即可，重写中将原有的委派的代码删除即可，如图

出错的根本原因在于，Object.class是所有类的父类，则在类加载的过程中，Object类也会被自定义的类加载器加载，但是自定义的类加载器无法加载Object类，则出错（Object类是引导类加载器加载的）

**解决方式：**保留原有的双亲委派机制，在原有基础上，除了指定路径的类通过自定义加载器加载外，其他的还是走默认的类加载器加载，如图：