类加载器

什么是类加载器(ClassLoader)

虚拟机设计团队把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类。实现这个动作的代码模块称为“类加载器”。

类加载器可以说是Java语言的一项创新，类加载器在类层次的划分，OSGi，热部署，代码加密等领域大放异彩。

类与类加载器

类加载器虽然只用于实现类的加载动作，但它在Java程序中起到的作用却远远不限于类加载阶段。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，每一个类加载器，都拥有一个独立的类名称空间。这句话的意思是：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

这里所指的"相等"，包括代表类的Class对象的equals()方法，isAssignableFrom()方法，isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。

类加载器的工作机制

类装载器就是寻找类的字节码文件并构造出类在JVM内部表示的对象组件。在Java中，类加载器把一个类装入JVM中，要经过以下步骤：
1.装载：检查和导入Class文件；
2.链接：执行校验，准备和解析步骤，其中解析步骤是可以选择的：
a>校验：检查载入Class文件数据的正确性；
b>准备：给类的静态变量分配存储空间；
c>解析：将符号引用转成直接引用；
3.初始化：对类的静态变量，静态代码块执行初始化工作。
类装载工作由ClassLoader及其子类负责，ClassLoader是一个重要的Java运行时系统组件，它负责在运行时查找和装入Class字节码文件。

双亲委派模型

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一个种就是其他类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

从Java开发人员的角度来看，类加载器还可以划分更细致一些，绝大部分Java程序都会使用到以下三种系统提供的类加载器，少数还有用到自定义的类加载器。

启动类加载器（Bootstrap ClassLoader）
负责加载\lib

扩展类加载器（Extension ClassLoader）
负责加载\lib\ext

应用程序类加载器（Application ClassLoader）
负责加载用户类路径上所指定的类库,开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

自定义类加载器

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

类加载器双亲委派模型

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，他首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

protected synchronized Class loadClass(String name,boolean resolve) throws ClassNotFoundException{
    //首先，检查请求的类是否已经被加载过了
    Class c = findLoadedClass(name);
    if(c==null){
        try{
            if(parent !=null){
                c=parent.loadClass(name,false);
            }else{
                c=findBootstrapClassOrNull(name);
            }
        }catch(ClassNotFoundException e) {
            //如果父类加载器抛出ClassNotFoundException异常
            //说明父类加载器无法完成加载请求
        }
        if(c=null){
            //在父类加载器无法加载的时候
            //再调用本身的findClass方法来进行类加载
            c=findClass(name);
        }
        if(resolve){
            resolveClass(c);
        }
        return c;
    }

破坏双亲委派模型

双亲委派模型并不是一个强制性的约束模型，而是Java设计者推荐给开发者的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外，到目前为止，双亲委派模型有三次较大规模的破坏。

第一次被破坏是出现在双亲委派模型之前——即JDK1.2发布之前。类加载器在1.0时代就有了，面对已经存在的用户自定义类加载器的实现代码，Java设计者引入双亲委派模型不得不做出一些妥协。JDK1.2之后的java.lang.ClassLoader添加了一个新的protected方法findClass()，在此之前，用户去继承java.lang.ClassLoader的唯一目的是为了重写loadClass()方法，因为虚拟机在进行类加载的时候会调用加载器的私有方法loadClassInternal(),而这个方法的唯一逻辑就是去调用自己的loadClass()。

第二次被破坏是由这个模型自身的缺陷所导致的，双亲委派很好地解决了各个类加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载），基础类之所以成为“基础”，是因为它们总是被用户代码调用的API，但世事往往没有绝对的完美，如果基础类又要调用回用户的代码，那该怎么办？如JNDI服务，它的代码由启动类加载器去加载，但JNDI的目的就是对资源进行集中管理和查找，它需要调用由独立厂商实现并部署在应用程序的ClassPath下的JNDI接口提供者（SPI，Service Provider Interface）的代码，但启动类加载器不可能“认识”这些代码啊？
为了解决这个问题，Java设计团队只好引入了一个不太优雅的设计：线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过java.lang.Thread类的setContextClassLoader()方法进行设置，如果创建线程时还没未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个加载器默认就是应用程序类加载器。

双亲委派模型的第三次被破坏是由于用户对程序动态性的追求而导致的，这里所说的“动态性”指的是当前一些非常热门的名词：代码热替换(HotSwap)，模块热部署(Hot Deployment)等。在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展更加复杂的网状结构，当收到类加载请求时，OSGi将按照一定的规则进行类搜索。

ClassLoader重要方法

在Java中，ClassLoader是一个抽象类，位于java.lang中。下面对该类的一些重要接口方法进行介绍：

Class loadClass(String name)
name参数指定类装载器需要装载类的名字，必须使用全限定类名，如com.baobaotao.beans.Car。该方法有一个重载方法loadClass(String name,boolean resolve),resolve参数告诉类是否需要解析该类。在初始化类之前，应该考虑进行类解析的工作，但并不是所有的类都需要解析，如果JVM只需要知道该类是否存在或找出该类的超类，那么就不需要进行解析。
Class findSystemClass(String name)
从本地文件系统载入Class文件，如果本地文件系统不存在该Class文件，将抛出ClassNotFoundException异常。该方法是JVM默认使用的装载机制。
ClassfindLoadedClass(String name)
调用该方法来查看ClassLoader是否已装入某个类。如果已经装入，那么返回java.lang.Class对象，否则返回null。如果强行装载已经存在的类，将会抛出链接错误。
ClassLoader getParent()
获取类装载器的父装载器，除根装载器外，所有的类装载器都有仅有一个父装载器，ExtClassLoader的父装载器是根装载器，因为根装载器非Java编写，所以无法获得，将返回null。