Java ClassLoader

参考：http://blog.csdn.net/zhuojiajin/article/details/38962087
　　　http://blog.csdn.net/xyang81/article/details/7292380

大家都知道，当我们写好一个Java程序之后，不是管是CS还是BS应用，都是由若干个.class文件组织而成的一个完整的Java应用程序，当程序在运行时，即会调用该程序的一个入口函数来调用系统的相关功能，而这些功能都被封装在不同的class文件当中，所以经常要从这个class文件中要调用另外一个class文件中的方法，如果另外一个文件不存在的，则会引发系统异常。而程序在启动的时候，并不会一次性加载程序所要用的所有class文件，而是根据程序的需要，通过Java的类加载机制（ClassLoader）来动态加载某个class文件到内存当中的，从而只有class文件被载入到了内存之后，才能被其它class所引用。所以ClassLoader就是用来动态加载class文件到内存当中用的。

ClassLoader是负责加载类的对象，作用是根据Jvm请求提供的类信息，将请求的类加载的内存中或者说加载到Jvm中。另外，每一个类的Class对象（注意Class是类类型）都持有一个对应的ClassLoader的引用。可以通过Class对象的getClassLoader（）方法得到。类和它的ClassLoader是对应的，所以类只能通过它对应的ClassLoader加载。

Java的Classloader有四种分别为：
**bootstrap classloader **：引导（也称为原始）类加载器。
extension classloader ：扩展类加载器。
Application ClassLoader：应用程序类加载器。
User Defined ClassLoader：自定义类加载器。

Bootstrap ClassLoader：是用C++编写的，是JVM的内置加载器，它的名字是null。它用来加载核心类库，即在lib下的类库。做个实验，首先，String类肯定是java的核心类，那我们就以它为例来看看：

public static void main(String[] args)
{  
        String a="x";  
        System.out.println(a.getClass().getClassLoader());  
}  

输出结果为null。我们通过代码获得了加载String类的ClassLoader的名字，也就是null。
Extension ClassLoader：加载lib/ext下的类库。
App ClassLoader：加载Classpath里的类库。

层次关系

每一个Class对象都会持有一个对应的ClassLoader对象的引用。每一个ClassLoader对象也会持有一个Parent ClassLoader对象的引用。这里需要特别注意的是：这里所指的的Parent ClassLoader不是我们熟悉的继承关系，不是父类！
举个例子：

public static void main(String[] args)
{       
        ClassLoader c = TestClassLoader.class.getClassLoader();  
        do {  
            System.out.println(c.getClass().getName());  
            c=c.getParent();  
        }while(c!=null);          
    }  
}  

输出为：

sun.misc.Launcher$AppClassLoader
sun.misc.Launcher$ExtClassLoader

这里简单解释下上面的代码，首先获取TestClassLoader这个类的类类型，通过类类型获得该类的ClassLoade的对象的引用，将其赋值给c这个新定义的引用变量。通过这个ClassLoader对象的引用获得其Parent ClassLoader的对象的引用。

双亲加载机制

层次关系中我们了解到了很重要的一点：加载器对象之间的引用关系。被引用的对象称之为引用对象的父加载器，可以通过getParent()方法得到。那么双亲加载机制就是基于这种引用的层次关系。即：当一个ClassLoader接到请求时，它不是直接加载对应的类，而是询问它引用的ClassLoader是否能够加载，而这个父ClassLoader则会询问自己的引用的ClassLoader是否加载了该类。只有当所有的父ClassLoader都没有加载该类时，这个最初的ClassLoader才自己去加载申请的类。

双亲加载机制可以一定程度上保证安全性，因为只要顶层ClassLoader能加载的东西就一定不会让下层的ClassLoader有机会加载。也就保证了有些自定义的带有破坏性的类不会被加载到Jvm核心中。
我们试想一下，如果不使用这种委托模式，那我们就可以随时使用自定义的String来动态替代java核心api中定义的类型，这样会存在非常大的安全隐患，而双亲委托的方式，就可以避免这种情况，因为String已经在启动时就被引导类加载器(Bootstrcp ClassLoader)加载，所以用户自定义的ClassLoader永远也无法加载一个自己写的String，除非你改变JDK中ClassLoader搜索类的默认算法。