一个类想要在JVM中使用，势必要经过加载、验证、准备、解析、初始化等步骤。
而JVM的所有类加载，都是通过一个叫类加载器的东西来进行加载的。类加载器做的就是上面五个步骤做的事情。
常规的JVM中，例如Hotspot提供的类加载方式都是懒加载的，也就是说，是按需加载，有需要了再去加载。
JDK提供了三个类加载器
Bootstrap ClassLoader
这个加载器是JDK的启动加载器，加载的是Java的核心类库， rt.jar、resources.jar、charsets.jar 等。就连写的语言都不是Java的，而是C++。
Extention ClassLoader
拓展类加载器，主要用于加载%JAVA_HOME%/jre/lib/ext目录下的jar包和.class文件。可以通过系统变量 java.ext.dirs来指定这个目录。这个加载器是Java语言写的
Application ClassLoader
系统类加载器（System ClassLoader），这个是我们写的Java类的默认加载器，我们写的代码优先使用这个类加载器进行加载。
自定义类加载器
当然加载器并不是定死只能用JDK提供的，除了JDK提供的加载器，我们自己也可以定义类加载器（Custom ClassLoader），支持一些个性化的功能。
为什么JDK要这么设计类加载器？
Java中有三种基础的类加载器主要为了安全。
由于类加载器加载的时候会根据一个类的权限定名来加载类，如果我写了一个类全类名为：java.lang.String 这样，如果只有一个类加载器，那么类加载器就会去覆盖核心类库中的String类，甚至是去覆盖Object类。这样的操作是很危险的！
那么还是有个问题，如果我编写了一个java.lang.Object类，并把它放到了classPath中，由用自定义加载器去加载这个类的话，还是会出问题，因为系统中会存在很多Object类，所以为了解决这个问题，JDK的加载器就有了双亲委派模型
双亲委派模型
类加载器其实都是有“父子关系”的，这也就是双亲委派模型。先上一张图
可以发现除了Bootstrap加载器外，其他的加载器都有自己的父类加载器，但是这里需要注意的是这种父类，不是继承关系，而是组合关系，我们可以通过源码看到。
有兴趣的同学可以去查看sun.misc.Launcher类(它是一个java虚拟机的入口应用)的源码去研究JVM如何在启动中将类加载器加载好。我可以截一张图，因为我也没研究明白,这里就不过多赘述。
双亲委派模型的工作机制
某一个类加载器在接收到类加载请求时，会先询问父类加载器是否加载了此类，如果父类加载器抛出了ClassNotFoundException异常，则再调用自己的findClass()方法进行加载。以此类推
举个通俗易懂的例子，自己写了一个类，给了Application加载器加载，然后Application会将全类名提交给Extension加载去加载，然后Extension再将全类名交给Bootstrap加载器去加载。Bootstrap发现自己加载路径下没有这个类，然后抛出异常，Extension接到异常，然后去找自己加载路径下的类。也发现没有，继续抛出异常。最后Application加载器接到异常并调用findClass()方法找到了这个类。
双亲委派模型的好处
再回去思考那个问题：如果我编写了一个java.lang.Object类，并把它放到了classPath中，由用自定义加载器去加载这个类的话，还是会出问题，因为系统中会存在很多Object类。
有了双亲委派模型就不会出现这样的问题，因为java.lang.Object已经被Bootstrap加载器去加载了，自己写的Object并不会生效。从而保证了核心类库的唯一性，增加了安全性。
总结一句话，双亲委派模型的好处就是，为了防止内存中出现多份同样的字节码
双亲委派模型引出的问题
那如果我一台机器上有很多个相同类名，但是不同版本的代码怎么办？
例如我在Tomcat中，有两个不通版本的war包，启动的时候要互相隔离？
所以就出现了打破双亲委派机制的类加载器，下一篇博文继续：
本人为（VX）恭（gong）祝（zhong）号：一吱小确幸。欢迎大家关注
