类加载器及类的加载机制

类加载器

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放在java虚拟机外部去实现，以便让应用程序自己决定如何获取所需要的类。实现这个动作的代码模块称为“类加载器”。
JDK提供了三种类加载器，分别是Bootstrap ClassLoader(启动类加载器)，ExtClassLoader(扩展类加载器)，AppClassLoader(应用类加载器)。每一种加载器都有指定的加载路径。

1. Bootstrap ClassLoader 主要加载JAVA_HOME/jre/lib里的jar包，该目录下的所以jar包都是运行JVM时所必需的jar包。注意：类加载其自身也是个Java类，因此，自身类加载器需要被其他类加载器进行加载后方可使用，显然必须有一个类加载器的顶级父类（就是Bootstap ClassLoader,该类加载器都是由C语言代码进行开发的）是其他类加载器的父类，如果一个类的类加载器是Bootstrap ClassLoader,那么该类的getClassLoader()方法返回null.。
2. ExtCLassLoader 主要加载java核心扩展类，即JAVA_HOME/jre/ext目录下的jar文件。
3. AppClassloader 主要加载的是开发者在应用程序中编写的类，即CLASSPATH路径下的所有jar文件。

双亲委派模型

上图所展示的类加载器的这种层次关系，称为双亲委派模型。
双亲委派模型的工作过程如下：
（1）当前类加载器从自己已经加载的类中查询此类是否已经加载，如果已经加载则返回原来已经加载的类。
（2）如果没有找到，就去委派父类加载器去加载，父类加载器也会采用同样的策略，查看自己已经加载过的类是否包含这个类，又就返回，没有就委托父类去加载，直到委托到启动类加载器为止。
（3）如果启动类加载器加载失败，就会使用扩展类加载器来尝试加载，继续失败则会使用AppClassLoader来加载，继续失败就会抛出一个异常ClassNotFoundException。
使用双亲委派模型的好处：

1. 安全性，避免用户自己编写的类动态替换Java的一些核心类。如果不采用双亲委派模型的加载方式进行加载，那我们就可以随时使用自定义的类来动态替代Java核心API中定义的类。
2. 避免类的重复加载，因为JVM判定两个类是否是同一个类，不仅仅根据类型是否相同进行判定，还需要判断加载该类的类加载器是否是同一个类加载器，相同的class文件被不同的类加载器加载得到的结构就是两个不同的类。

参考文献《深入理解Java虚拟机》