java虚拟机系列（3）

类加载器

虚拟机设计团队把类的加载阶段中的通过一个类的全限定名称去获取此类的二进制字节流，这个动作给放到java虚拟机的外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块称之为，类加载器。java类加载器可以说是java语言的一项创新，也是java语言流行起来的原因之一。

类与类加载器

类加载器虽然只用于实现类的加载动作，但是它在java程序中起到的作用却非常大，对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机中的唯一性，每一个类加载器，都有一个独立的类名称空间。这句话可以表达的更加通俗一点就是，比较两个类是否相等，只有当这两个类由同一个类加载器加载的情况下才有意义，否则就算他们是来自于同一个class文件，被同一个虚拟机加载，但是由不同的类加载器加载，那么它们也是不相等的。

这里所指的相等，包括代表类的class对象的equals 方法等，返回的结果，也包括hi用instanceof 关键字做对象的所属关系的判定等情况，如果没有注意到类加载器的影响，在某些情况下可能会产生具有迷惑性的结果。

我们自定义一个类加载器去加载某一个自己写的类，并且实例化对象，但是我们自己写的这个类会被系统的类加载器给加载，虽然他们都是来自与一个Class文件，但是是由两个不同的类加载器加载的，虚拟机中会存在两个Class类，它们是互相独立的，所以毫不相干。

双亲委托机制

从java虚拟机的角度来讲，只存在两种类加载器：
- 启动类加载器 ：启动类加载器由c++实现，是虚拟机自身的一部分
- 其他类加载器 ：这些类加载器由java语言实现，独立与虚拟机外部，全都继承classloader

大部分虚拟机都会用到以下类加载器

启动类加载器：这个类加载器负责将存放在java/lib目录中的的类库加载到虚拟机内存中，启动类加载器无法被java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可

扩展类加载器：这个贾庵子其由sun.misc.Launcher$ExtClassLoader 实现，它负责加载/lib/ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用程序类加载器：这个类加载器由sun.misc.Launcher $App-ClassLoader 实现，由于这个类加载器是是ClassLoader中的getSystemClassLoader()方法的返回值，所以也叫系统类加载器，它负责加载用，户类路径所指定的类库，开发者可以直接使用，如果写的程序没有定义过类加载器，那么默认就使用应用程序类加载器。通常我们自己写的java类就是由这个加载器加载的。

我们的应用程序都是由这三种类加载器加载的，如果有必要那么我们也可以自己写一个类加载器

启自定义类加载器 ->应用程序类加载器 ->扩展类加载器 -> 启动类加载器

这种层次的关系，成为类加载器的双亲委派模型。

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器。这里类加载器之间的关系一般不用继承来实现，而都是用组合关系来复用父加载器的代码。

双亲委派模型的工作过程是： 如果一个类加载器收到了类加载的请求，它首先不会自己去加载，而是委派给父类加载器去加载，每一个层次的加载器都是如此，只有当父类加载器无法加载时，子类加载器才会自己尝试加载，使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。就防止了恶意篡改类，防止出现多个Object 类的情况，否则程序将会一片混乱。