1.顾名思义 类加载器就是ClassLoader
用来加载 Java 类到 Java 虚拟机中。一般来说，Java 虚拟机使用 Java 类的方式如下：Java 源程序（.java 文件）在经过 Java 编译器编译之后就被转换成 Java 字节代码（.class 文件）。类加载器负责读取 Java 字节代码，并转换成 java.lang.Class类的一个实例。每个这样的实例用来表示一个 Java 类。通过此实例的 newInstance()方法就可以创建出该类的一个对象。实际的情况可能更加复杂，比如 Java 字节代码可能是通过工具动态生成的，也可能是通过网络下载的。

java.lang.ClassLoader类介绍
java.lang.ClassLoader类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个 Java 类，即java.lang.Class类的一个实例。除此之外，ClassLoader还负责加载 Java 应用所需的资源，如图像文件和配置文件等。不过本文只讨论其加载类的功能。为了完成加载类的这个职责，ClassLoader提供了一系列的方法，比较重要的方法如[表 1]所示。关于这些方法的细节会在下面进行介绍。

   方法                                                           说明
getParent()     返回该类加载器的父类加载器。

loadClass(String name)                   加载名称为 name的类，返回的结果是 java.lang.Class类的实例。

findClass(String name)                    查找名称为 name的类，返回的结果是 java.lang.Class类的实例。

findLoadedClass(String name)        查找名称为 name的已经被加载过的类，返回的结果是 java.lang.Class类的实例。

defineClass(String name, byte[] b, int off, int len)   
把字节数组 b中的内容转换成 Java 类，返回的结果是 java.lang.Class类的实例。这个方法被声明为 final的。

resolveClass(Class<?> c)                链接指定的 Java 类。

2.类加载器的树状组织结构
类加载可以分为两类: 一类是系统提供的，另外一类则是由 Java 应用开发人员编写的。系统提供的类加载器主要有下面三个：

引导类加载器(bootstrap class loader)
它用来加载 Java 的核心库，是用原生代码来实现的，并不继承自 java.lang.ClassLoader。

扩展类加载器(extensions  class loader)
它用来加载 Java 的扩展库。Java 虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载 Java 类。

系统类加载器(system class loader or app class loader)
它根据 Java 应用的类路径（CLASSPATH）来加载 Java 类。一般来说，Java 应用的类都是由它来完成加载的。可以通过 ClassLoader.getSystemClassLoader()来获取它

清单 1. 演示类加载器的树状组织结构

public class ClassLoaderTree { 
   public static void main(String[] args) { 
       ClassLoader loader = ClassLoaderTree.class.getClassLoader(); 
       while (loader != null) { 
           System.out.println(loader.toString()); 
           loader = loader.getParent(); 
       } 
   } 
}

每个 Java 类都维护着一个指向定义它的类加载器的引用，通过getClassLoader()方法就可以获取到此引用。
[代码清单 1]中通过递归调用 getParent()方法来输出全部的父类加载器。[代码清单 1]的运行结果如[代码清单 2]所示。

清单 2. 演示类加载器的树状组织结构的运行结果

sun.misc.Launcher$AppClassLoader@9304b1 
sun.misc.Launcher$ExtClassLoader@190d11

第一个输出的是 ClassLoaderTree类的类加载器，即系统类加载器。它是 sun.misc.Launcher$AppClassLoader类的实例；第二个输出的是扩展类加载器，是 sun.misc.Launcher$ExtClassLoader类的实例。需要注意的是这里并没有输出引导类加载器，这是由于有些 JDK 的实现对于父类加载器是引导类加载器的情况，getParent()方法返回 null。

3.类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。在介绍代理模式背后的动机之前，首先需要说明一下 Java 虚拟机是如何判定两个 Java 类是相同的。Java 虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。比如一个 Java 类 com.example.Sample，编译之后生成了字节代码文件 Sample.class。两个不同的类加载器 ClassLoaderA和 ClassLoaderB分别读取了这个 Sample.class文件，并定义出两个 java.lang.Class类的实例来表示这个类。这两个实例是不相同的。对于 Java 虚拟机来说，它们是不同的类。试图对这两个类的对象进行相互赋值，会抛出运行时异常 ClassCastException。下面通过示例来具体说明。[代码清单 3]给出了 Java 类 com.example.Sample。

package com.example; 
 
public class Sample { 
   private Sample instance; 
 
   public void setSample(Object instance) { 
       this.instance = (Sample) instance; 
   } 
}

如[代码清单 3]所示com.example.Sample类的方法 setSample接受一个 java.lang.Object类型的参数，并且会把该参数强制转换成 com.example.Sample类型。测试 Java 类是否相同的代码如 [代码清单 4]所示。
清单 4. 测试 Java 类是否相同

public void testClassIdentity() { 
   String classDataRootPath = "C:\\workspace\\Classloader\\classData"; 
   FileSystemClassLoader fscl1 = new FileSystemClassLoader(classDataRootPath); 
   FileSystemClassLoader fscl2 = new FileSystemClassLoader(classDataRootPath); 
   String className = "com.example.Sample";    
   try { 
       Class<?> class1 = fscl1.loadClass(className); 
       Object obj1 = class1.newInstance(); 
       Class<?> class2 = fscl2.loadClass(className); 
       Object obj2 = class2.newInstance(); 
       Method setSampleMethod = class1.getMethod("setSample", java.lang.Object.class); 
       setSampleMethod.invoke(obj1, obj2); 
   } catch (Exception e) { 
       e.printStackTrace(); 
   } 
}

[代码清单 4]中使用了类 FileSystemClassLoader的两个不同实例来分别加载类 com.example.Sample，得到了两个不同的 java.lang.Class的实例，接着通过 newInstance()方法分别生成了两个类的对象 obj1和 obj2，最后通过 Java 的反射 API 在对象 obj1上调用方法 setSample，试图把对象 obj2赋值给 obj1内部的 instance对象。
[代码清单 4]的运行结果如[代码清单 5]所示。
清单 5. 测试 Java 类是否相同的运行结果

java.lang.reflect.InvocationTargetException 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597) 
at classloader.ClassIdentity.testClassIdentity(ClassIdentity.java:26) 
at classloader.ClassIdentity.main(ClassIdentity.java:9) 
Caused by: java.lang.ClassCastException: com.example.Sample 
cannot be cast to com.example.Sample 
at com.example.Sample.setSample(Sample.java:7) 
... 6 more

给出的运行结果可以看到，运行时抛出了 java.lang.ClassCastException异常。虽然两个对象 obj1和 obj2的类的名字相同，但是这两个类是由不同的类加载器实例来加载的，因此不被 Java 虚拟机认为是相同的。

4.双亲委派模型

image001.jpg

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

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着
它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在
rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加
载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类。相反，如果没有
使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个称为
java.lang.Object的类，并放在程序的ClassPath中，那系统中将会出现多个不同的Object
类，Java类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。如果读者
有兴趣的话，可以尝试去编写一个与rt.jar类库中已有类重名的Java类，将会发现可以正常编
译，但永远无法被加载运行[2]。

双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲
委派的代码都集中在java.lang.ClassLoader的loadClass（）方法之中，如代码清单7-10所示，
逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方
法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，抛出
ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。

双亲委派模型的实现

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
//说明父类加载器无法完成加载请求
}i
f（c==null）{
//在父类加载器无法加载的时候
//再调用本身的findClass方法来进行类加载
c=findClass（name）；
}}i
f（resolve）{
resolveClass（c）；
}r
eturn c；
}