我们知道，Java程序的启动，其实是依赖于我们编译之后的.class文件，那么JVM是如何读取.class文件的？这一切都离不开ClassLoader这个类，ClassLoader可以将Java字节码加载入JVM当中，供后面使用。
前言
一个Java程序的启动流程，大致分为：编译->加载->链接->初始化->运行。
- 编译，也就是我们常见的将
.java文件转换为.class文件的过程。一般我们可以通过javac命令进行编译，或者在ide中我们build一下就进行了编译 - 加载，也就是这个环节利用了ClassLoader，将
.class文件加载进JVM中 - 链接，包括验证、准备和解析等几个步骤
- 初始化，主要是执行了类中的静态代码
- 运行，顾名思义，通过JVM虚拟机在对应平台上运行程序代码
三个类加载器
我们知道Java程序的启动，需要类加载器ClassLoader来将java字节码载入JVM，那么ClassLoader又是从何处开始加载呢？
概述
在Java中，系统自带了三个类记载器：
-
BootStrap ClassLoader最顶层的类加载器，Java会最先启动这个类加载器，加载核心类库，加载%JRE_HOME%\lib目录下的jar包和class文件等，其中就包括了Java的基础类，如String，IO等等 -
Extention ClassLoader第二层的类加载器，加载拓展类库，会加载%JRE_HOME%\lib\ext目录下的jar包和class文件等，其中包括了各地的时间语言包等。 -
App ClassLoader第三层的类加载库，加载当前应用目录下的jar包和class文件。
加载顺序
-
BootStrap ClassLoader
刚才说了，BootStrap ClassLoader是最顶层的类加载器，负责加载核心类库，自然也就是最先加载的ClassLoader了，然而我们却没办法在Java中找到对应的类。黑人问号脸？？？
刚才也说了，String，File等基础类都是由他在最开始加载的。我们尝试调用以下代码：
System.out.println(String.class.getClassLoader());
结果却是null？？？
通过查阅资料可以得知，BootStrap ClassLoaer其实是C/C++实现的，是它本身是虚拟机的一部分，所以我们在Java代码中并没有办法找到他。所以自然也就是null咯
-
Extention ClassLoader&AppClassLoader
和BootStrap ClassLoader不同，Extention ClassLoader&AppClassLoader我们可以在代码中找到，他们都是Launcher类的内部类：
public class Launcher {
public Launcher() {
//省略大量代码
Launcher.ExtClassLoader var1;
//加载ExtClassLoader，没有传入参数
var1 = Launcher.ExtClassLoader.getExtClassLoader();
//加载AppClassLoader，传入ExtClassLoader作为参数，并将AppClassLoader设为Launcher的ClassLoader
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
……
}
static class AppClassLoader extends URLClassLoader {
//省略
AppClassLoader(URL[] var1, ClassLoader var2) {
super(var1, var2, Launcher.factory);
}
}
static class ExtClassLoader extends URLClassLoader {
//省略
public ExtClassLoader(File[] var1) throws IOException {
super(getExtURLs(var1), (ClassLoader)null, Launcher.factory);
}
}
}
查阅资料可以得知，Launcher是由JVM的入口应用，由虚拟机启动时通过JNI启动该类。
我们可以看到Launcher的构造函数中，依次加载了ExtClassLoader和AppClassLoader。
所以我们可以总结出：JVM会首先加载BootStrap ClassLoader，接着加载ExtClassLoader，然后才加载AppClassLoader。
工作原理——双亲委托
我们可以先看看ClassLoader的构造函数：
public abstract class ClassLoader {
private final ClassLoader parent;
private ClassLoader(Void unused, ClassLoader parent) {
this.parent = parent;
……//省略一堆
}
}
可以看到，在构造函数中，传入了一个ClassLoader作为parent。
同时ClassLoader有一个getParent的方法，可以通过这个方法获取当前ClassLoader的Parent，那么AppClassLoader和ExtClassLoader的parent是什么鬼呢，我们实验一下：
System.out.println(Test.class.getClassLoader());
System.out.println(Test.class.getClassLoader().getParent());
System.out.println(Test.class.getClassLoader().getParent().getParent());
打印结果：
sun.misc.Launcher$AppClassLoader@28d93b30
sun.misc.Launcher$ExtClassLoader@14ae5a5
null
看到这样的输出结果，我们难免会有些疑惑：
-
AppClassLoader的parent是ExtClassLoader? -
ExtClassLoader的parent是null？ - 那
BootStrapClassLoader呢？？？
为了解开这些疑惑，我们看一下AppClassLoader&ExtClassLoader的构造函数：
public class Launcher {
public Launcher() {
//省略大量代码
Launcher.ExtClassLoader var1;
//加载ExtClassLoader，没有传入参数
var1 = Launcher.ExtClassLoader.getExtClassLoader();
//加载AppClassLoader，传入ExtClassLoader作为参数，并将AppClassLoader设为Launcher的ClassLoader
this.loader = Launcher.AppClassLoader.getAppClassLoader(var1);
……
}
static class AppClassLoader extends URLClassLoader {
//省略
AppClassLoader(URL[] var1, ClassLoader var2) {
// var2对应传入了ExtClassLoader作为parent
super(var1, var2, Launcher.factory);
}
}
static class ExtClassLoader extends URLClassLoader {
//省略
public ExtClassLoader(File[] var1) throws IOException {
// 传入null作为parent
super(getExtURLs(var1), (ClassLoader)null, Launcher.factory);
}
}
}
可以看到，Launcher在构造时会先创建ExtClassLoader然后将创建的ExtClassLoader做为参数构建AppClassLoader。而ExtClassLoader创建时会传入null作为parent，AppClassLoader会传入刚构建的ExtClassLoader作为parent。
这也就印证了我们刚才的输出结果。但是parent的意义有是什么呢？
加载过程
接下来我们需要先看一下ClassLoader是如何加载一个Class的：
在Java会通过ClassLoader的loadClass方法来加载一个类，我们先看一下这个方法：
public abstract class ClassLoader {
/**
* 使用特定的二进制名来加载类
* 默认会执行如下的顺序：
* 1. 通过findLoadedClass()判断这个类时候已经加载过了
* 2. 通过parent.loadClass()尝试让parent加载这个class
* 如果parent是null，那么调用虚拟机创建的ClassLoaer
* 3. 通过findClass()加载类，最终defineClass方法将jar文件转为Class
*
* 如果通过上述步骤可以加载出对应的class，那么调用resolveClass(Class 处理结果。
* 子类应该重写findClass()方法而不是这个方法
*/
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException
{
//省略部分代码
synchronized (getClassLoadingLock(name)) {
// 首先检查这个类是否已经被加载过
Class<?> c = findLoadedClass(name);
//如果没有被加载过
if (c == null) {
// 如果parent不为空
if (parent != null) {
c = parent.loadClass(name, false);
} else {
// 如果parent为空，那么调用Bootstrap classLoader加载这个类
c = findBootstrapClassOrNull(name);
}
if (c == null) {
// 如果仍然为空，那么调用findClass
c = findClass(name);
}
}
if (resolve) {
// 处理结果
resolveClass(c);
}
return c;
}
}
}
通过注释我们可以清楚的看到这个方法的主要逻辑:
- 通过
findLoadedClass()判断这个类时候已经加载过了 - 通过
parent.loadClass()尝试让parent加载这个class
如果parent是null，那么调用虚拟机创建的BootStrapClassLoaer - 通过
findClass()(最终转到defineClass方法)加载类，将jar文件转为Class
TODO：= =本来打算画个图。。可是怎么画都不合意。。
可以看到，ClassLoader会先委托parent进行加载，如果加载不出来才会自己进行加载，所以Classloader的parent其实是一个层级关系。
这也正是刚才说的双亲委托机制：先委托parent进行加载，加载不出来再自己加载。
为什么要选择这种机制呢？试想一下如果现在我也实现了一个String类(包名也一样)，这样JVM中是不是就会有两种String呢？这样不就乱套了吗，而且也出现了安全问题
采用双亲委托机制就很好的解决了这种情况，我们永远没有办法加载一个自定义的String类(包名也相同)。
总结
首先JVM会依次加载
BootStrapClassLoader(C/C++)，ExtClassLoader，AppClassLoader。AppClassLoader的parent是ExtClassLoader，而ExtClassLoader的parent可以认为是BootStrapClassLoader(因为当parent为null时，会调用BootStrapClassLoader来加载)ClasLoader加载时采用双亲委托机制，会优先委托parent加载，如果null，再自己加载
