虚拟机类加载机制 第二节:类加载器（JVM笔记）

类与类加载器

对于任意一个类都要由加载他的类加载器和这类本身一同确定其在java虚拟机中的唯一性。也就是说比较两个类是否相等，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则即使这两个类是来源于同一个Class文件，只要加载他的加载器不同，这两个类就必定不相等。

双亲委派模型

站在JVM的角度讲只有两种不同的类加载器：

1. 启动类加载器，这个类加载器使用C++语言实现，虚拟机自身的一部分
2. 其他类加载器，这些类加载器都是用java语言实现，独立于虚拟机，并且全部继承自抽象类java.lang.ClassLoader

从java开发人员的角度讲，可以划分更细，但绝大多数程序都会用到一下三种类加载器：

1. 启动类加载器（Bootstrap ClassLoader），这个类加载器负责加载< JAVA_HOME >/lib目录中的，并且被虚拟机识别的（按照文件名识别，如rt.jar，名称不符合即使放在lib中也无法被识别加载）类库加载到虚拟机内存中。启动类加载器无法被java程序直接引用
2. 扩展类加载器（Extension ClassLoader）：由sun.misc.Launcher$ExtClassLoader实现，负责加载< JAVA_HOME >/lib/ext目录中的，或者被java.ext.dirs系统变量所指定路劲中的所有类库，开发者可以直接使用。
3. 应用程序类加载器（Application ClassLoader）：这个类由sun.misc.Launcher$AppClassLoader来实现，也被称为系统类加载器。他负责加载用户类路劲下所指定的类库，开发者可以直接使用这个类加载器，如果应用程序没有自定义过自己的类加载器，一般情况下这个就是默认的类加载器。

我们的应用程序都是三种类加载器相互配合进行加载的，如有必要可自定义。类加载器之间的关系如下图所示：

上图所示的类类加载器之间的层次关系，成为类加载器的双亲委派模型。双亲委派模型除了顶层的启动类加载器外，其余的类加载器都应当有自己的福类加载器。这里的父子关系一般不会用集成，而是使用组合关系来复用父加载器的代码。

双亲委派模型工作过程：

如果一个类加载器收到了类加载的请求，它首先不会自己尝试加载这个类，而是把这个类请求委派给父类加载器去完成,每一层的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有父加载器反馈无法完成这个家在请求时候，子类加载器才会尝试自己加载