JDK默认ClassLoader
JDK 默认提供了如下几种ClassLoader
1. Bootstrp loader（启动类加载器）
Bootstrp加载器是用C++语言写的，它是在Java虚拟机启动后初始化的，它主要负责加载%JAVA_HOME%/jre/lib,-Xbootclasspath参数指定的路径以及%JAVA_HOME%/jre/classes中的类。
1. ExtClassLoader （标准扩展类加载器）
Bootstrp loader加载ExtClassLoader,并且将ExtClassLoader的父加载器设置为Bootstrploader.ExtClassLoader是用Java写的，具体来说就是 sun.misc.Launcher$ExtClassLoader，ExtClassLoader主要加载%JAVA_HOME%/jre/lib/ext，此路径下的所有classes目录以及java.ext.dirs系统变量指定的路径中类库。
2. AppClassLoader（应用程序类加载器）
Bootstrp loader加载完ExtClassLoader后，就会加载AppClassLoader,并且将AppClassLoader的父加载器指定为 ExtClassLoader。AppClassLoader也是用Java写成的，它的实现类是sun.misc.Launcher$AppClassLoader，另外我们知道ClassLoader中有个getSystemClassLoader方法,此方法返回的正是AppclassLoader.AppClassLoader主要负责加载classpath所指定的位置的类或者是jar文档，它也是Java程序默认的类加载器。
为什么采用这个样的委派机制
首先classloader 分三个级别，最上级 ： bootstrap classLoader 中间级：extension classLoader 最低级 app classLoader.
当需要加载某个类的时候，会看看这个类是否已经被加载了，如果没有，会请求app 级来加载，app 请求 extension 级 extension 请求 bootstrap级， 由最高级来负责加载（这个就是双亲委派，委托 上两级的loader来做加载），如果高级的无法加载 则会将人物返回给 下一级 以此类推 最后如果双亲都不行 就由自己来加载。 为什么要用这个机制？ 比如 java.lang.String 这个类，这个是jdk提供的类， 如果我们自定义个 包名：java.lang 然后在里面创建一个String 类， 当我在用String类的时候，根据前面所说，是由bootstrap级的loader 来进行加载的，这个时候它发现其实已经加载过了jdk的String了，那么就不会去加载自定义的String了，防止了重复加载 也加大了安全性。
参考文章：
https://blog.csdn.net/wangyang1354/article/details/49448007