JVM(三)从JVM源码角度看类加载器层级关系和双亲委派
类加载器我们都知道有如下的继承结构，这个关系只是逻辑上的父子关系。
我们一直听说引导类加载器没有实体，为什么没有实体呢？
因为引导类加载器只是一段C++代码并不是什么实体类，所谓的引导类加载器就是那一段C++逻辑，让JVM从C++代码转到Java代码来加载其它类。
一：引导类加载器/启动类加载器到底是啥？
JVM启动后要找我们的Main Class，在openJDK中有一个java.c的C++文件
在这个文件中我们可以看到JVM是怎么加载mainClass的。
在第二步中，会调用cls的checkAndLoadMain方法，那这个cls是什么东西？GetLauncherHelperClass返回是个什么？ 我接着看。
关键点来了。FindBootStrapClass 通过动态链接库加载需要的类。加载到sun/launcher/LauncherHelper 类。
启动类加载器就是上面这个逻辑，主要目的就是找到sun/launcher/LauncherHelper 这个类。找到这个类之后再去创建扩展类加载器，应用类加载器。
我们回到上面的第二步，知道cls就是LauncherHelper了。看下这个类里面的checkAndLoadMain方法，这个类在rt.jar包里面。
a处我们的看到通过ClassLoader.getSystemClassLoader()得到一个类加载器。在c处通过这个类加载器加载MainClass。
这个MainClass怎么得到的可以从b处看到，我们如果自己需要获取jar的相关信息可以参考里面的逻辑方法，具体内容不再探讨。
那么我们就去看下a处的这个类加载器是那个？
sc1是由Launcher.getLauncher()中的getClassLoader()得到的。
我们看this.loader是怎么赋值的。
终于看到们熟悉的东西了！！！ 原来扩展类加载器ExtClassLoader和应用类加载器AppClassLoader都是Launcher的内部类。
二：扩展类加载器ExtClassLoader创建
首先我们看到扩展类加载器继承URLClassLoader。其加载的路径是系统变量java.ext.dirs。 在第三步构造函数里面我们看到创建扩展类加载器的时候第二个参数传入的就是null，这个参数就是父类构造器。
这下我们知道为啥在项目中获取扩展类加载器父加载器的时候得到的为空了。
三：系统类加载器创建
从上面得到AppClassLoader的时候把扩展类加载器作为参数传了进去。
系统类加载器加载的路径是系统参数为：java.class.path路径。创建它的时候把扩展类加载器作为父类传了进去。
上面把得到的系统类加载器设置为了线程上下文的类加载器。这一点很重要。
到此我们从代码的角度看到引导类加载器，扩展类加载器，系统类加载器是怎么维护他们之间的逻辑关系的。他们的这种关系也是双亲委派的基础也是打破双亲委派的切入点。
关于类加载器加载的路径，可以通过下面的代码输出看到。
View Code
四：双亲委派
当使用一个类加载器进行 classLoader.loadClass(String name)的时候都会走到下面的这个逻辑。(记住这个方法是protected的，前提是自定义类加载器不重写这个方法)
1：检查需要加载的class是否已经加载了，如果加载过了直接返回。
2：如果没有加载过，先看父加载器是否为空，(这个parent参数在创建类加载器的时候当做参数传进来的，上面内容已经说过。),不为空的话让父类加载器尝试加载。父类加载器还有父类加载器就传递上去加载。
3：直到父类加载器为空，即到扩展类加载器，parent为空，就调用native方法通过动态链接通过C++代码来加载，还记得上面FindBootStrapClass 吗 ，就是它来加载的。
4：当所有父类加载不到的时候就走到findClass(name)了，这也是个protected的，需要自定义类加载来实现加载方法。也就是所说的父类加载不到才由自己加载。
下一节记录怎么打破双亲机制。
