类加载机制
类加载器
JVM主张把类加载阶段”通过一个类的全限定名来获取此类的二进制字节流”这个动作放到JVM外部去实现，以便让应用程序决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。
类与类加载器
类加载器虽然只用于实现类的加载动作，但它在java程序中起到的作用却远远不限定于类加载阶段。对于任意一个类，都需要有加载它的类加载器和这个类本身一同确立其在JVM中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。即：比较两个类是否相等，只有这两个类有同一类加载器加载的前提下才有意义，否则即使这两个类源于统一class文件，同一个JVM加载，只要加载它们的类加载器不一样，这两个类就不相等。这里的相等，包括代表类的class对象的equals方法、isAssignableFrom方法、isInstance方法的返回结果；还有instanceof关键字的判定情况。
类加载机制：虚拟机将描述类的数据从class文件加载到内存中，对加载的数据进行验证，解析，初始化，最后得到虚拟机认可后转化为直接可以使用的java类型的过程
类加载机制一共有七个阶段：加载，验证，准备，解析，初始化，使用，卸载，其中：验证，准备，解析合称为连接阶段。
双亲委派模型
类加载器种类
从Java虚拟机的角度，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），是虚拟机自身的一部分；另一种就是所有其他的类加载器，独立于虚拟机外部，并且全部继承自java.lang.ClassLoader。类加载器可以细分为：
- 启动（Bootstrap）类加载器：负责将 Java_Home/lib下面的类库加载到内存中（比如rt.jar）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作
- 标准扩展（Extension）类加载器：是由 Sun 的 ExtClassLoader（sun.misc.Launcher$ExtClassLoader）实现的。它负责将Java_Home /lib/ext或者由系统变量 java.ext.dir指定位置中的类库加载到内存中。开发者可以直接使用标准扩展类加载器
- 应用程序（Application）类加载器：是由 Sun 的 AppClassLoader（sun.misc.Launcher$AppClassLoader）实现的。它负责将系统类路径（CLASSPATH）中指定的类库加载到内存中。开发者可以直接使用系统类加载器。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，因此一般称为系统（System）加载器。
除此之外，还有自定义的类加载器，它们之间的层次关系被称为类加载器的双亲委派模 。该模型要求除了顶层的启动类加载器外，其余的类加载器都应该有自己的父类加载器，而这种父子关系一般通过组合（Composition）关系来实现，而不是通过继承（Inheritance）。
双亲委派模型
双亲委派模型过程
双亲委派模型的式作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完全这个加载请求时，子加载器才会尝试自己去加载。
使用双亲委派模型的好处在于Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存在在rt.jar中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的Bootstrap ClassLoader进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有双亲委派模型而是由各个类加载器自行加载的话，如果用户编写了一个java.lang.Object的同名类并放在ClassPath中，那系统中将会出现多个不同的Object类，程序将混乱。因此，如果开发者尝试编写一个与rt.jar类库中重名的Java类，可以正常编译，但是永远无法被加载运行。
双亲委派模型的系统实现
在java.lang.ClassLoader的loadClass()方法中，先检查是否已经被加载过，若没有加载则调用父类加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父加载失败，则抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载。
protected synchronized Class<?> loadClass(String name,boolean resolve)throws ClassNotFoundException{
//check the class has been loaded or not
Class c = findLoadedClass(name);
if(c == null){
try{
if(parent != null){
c = parent.loadClass(name,false);
}else{
c = findBootstrapClassOrNull(name);
}
}catch(ClassNotFoundException e){
//if throws the exception ,the father can not complete the load
}
if(c == null){
c = findClass(name);
}
}
if(resolve){
resolveClass(c);
}
return c;
}
大多数的类加载器都遵循这个模型，但是JDK中也有较大规模破坏双亲模型的情况，例如线程上下文类加载器（Thread Context ClassLoader）的出现。
