前言
类加载器是Java语言的一个创新，也是Java语言流行的重要原因之一。它使得Java类可以被动态加载到Java虚拟机中并执行。类加载器从JDK1.0就出现了，最初是为了满足Java Applet的需要而开发出来的。Java Applet需要从远程下载Java类文件到浏览器中并执行。现在类加载器在Web容器和OSGi中得到了广泛的使用。一般来说，Java应用的开发人员不需要直接同类加载器进行交互。Java虚拟机默认的行为就已经足够满足大多数情况的需求了。不过如果遇到了需要与类加载器进行交互的情况，而对类加载器的机制又不是很了解的话，就很容易花大量的时间去调试ClassNotFoundException和NoClassDefFoundError等异常。
类加载器基本概念
顾名思义，类加载器（Class Loader）用来加载Java类到Java虚拟机中。一般来说，Java虚拟机使用Java类的方式如下：Java源程序（.java文件）在经过Java编译器编译之后就被转换成Java字节代码（.class文件）。类加载器负责读取Java字节代码到方法区，并转换成java.lang.Class类的实例。每个这样的实例用来表示一个Java类。通过此实例的newInstance()方法就可以创建出类的一个对象。实际情况可能更加复杂，比如Java字节代码可能是通过工具动态生成的，也可能是通过网络下载的。
基本上所有的类加载器都是java.lang.ClassLoader类的一个实力。下面详细介绍这个Java类。
java.lang.ClassLoader类介绍
java.lang.ClassLoader类的基本职责就是根据一个指定的类名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个Java类，即java.lang.Class类的一个实例。为了完成加载类这个职责，ClassLoader提供了一系列的方法，比较重要的方法如下表所示。这些方法的细节会在下面进行介绍。
ClassLoader中与加载类相关的方法
| 方法 | 说明 |
|---|---|
| getParent() | 返回该类加载器的父类加载器 |
| loadClass(String name) | 加载一个名称为name的类，返回的结果是java.lang.Class类的实例 |
| findClass(String name) | 查找名称为name的类，返回的结果是java.lang.Class类的实例 |
| findLoadedClass(String name) | 查找名称为name的已经被加载过的类，返回结果是java.lang.Class的实例 |
| defineClass(String) | 把字节数组b中的内容转换成Java类，返回的结果是java.lang.Class类的实例。这个方法被声明为final的。 |
| resolveClass(Class<?> c) | 链接指定的Java类 |
对于上述给出的方法，表示类名称的name参数的值是类的二进制名称。需要注意的是内部类的表示，如com.example.Sample$1和com.example.Sample$Inner等方式。这些方法会在下面介绍类加载器工作机制时，做进一步的说明。
类加载器的树状组织结构
Java中的类加载器大致可以分成两类，一类是系统提供的，另一类则是由Java应用开发人员编写的。系统提供的类加载器主要有下面三个：
-
引导类加载器（bootstrap class
loader）：它用来加载Java的核心类库，是用原生代码来实现的，并不继承自java.lang.ClassLoader。 -
扩展类加载器（extensions class loader）：它用来加载Java的扩展库。Java虚拟机的实现会提供一个扩展库目录。该类加载器在此目录里面查找并加载Java类。
-
系统类加载器（system class loader）：它根据Java应用的类路径（CLASSPATH）来加载Java类。一般来说，Java应用的类都是由它来完成加载的。可以通过ClassLoader.getSystemClassLoader（）来获取它。
除了系统提供的类加载器以外，开发人员可以通过集成java.lang.classLoader类的方式实现自己的类加载器，以满足一些特殊的需求。
除了引导类加载器之外，所有的类加载器都有一个父类加载器。通过上表中给出的getParent（）方法可以得到。对于系统提供的类加载器来说，系统加载器的父类加载器是扩展类加载器；对于开发人员编写的类加载器来说，其父类加载器是加载此类加载器Java类的类加载器。因为类加载器Java类如同其他Java类一样，也是要由类加载器来加载的。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。类加载器通过这种方式组织起来，形成树状结构。树的根节点就是引导类加载器。下图给出了一个典型的类加载器树状组织结构示意图，其中的箭头指向的是父类加载器。
演示类在加载器的树状组织结构
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()方法就可以获取到此引用。上述代码中通过递归调用getParent()方法来输出全部的类加载器。运行结果如下所示。
sun.misc.Launcher$AppClassLoader@9304b1
sun.misc.Launcher$ExtClassLoader@190d11
第一个输出的ClassLoaderTree类的类加载器，即系统类加载器。它是
sun.misc.Launcher
A
p
p
C
l
a
s
s
L
o
a
d
e
r
类
的
实
例
；
第
二
个
输
出
的
是
扩
展
类
加
载
器
，
是
s
u
n
.
m
i
s
c
.
L
a
u
n
c
h
e
r
AppClassLoader类的实例；第二个输出的是扩展类加载器，是sun.misc.Launcher
AppClassLoader类的实例；第二个输出的是扩展类加载器，是sun.misc.LauncherExtClassLoader类的实例。需要注意的是这里并没有引导类加载器，这是由于有些JDK的实现对于父类加载器是引导类加载器的情况，getParent()方法返回null。
在了解了类加载器的树状组织结构之后，下面介绍类加载器的代理模式。
类加载器的代理模式
类加载器在尝试自己去查到某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推。在介绍代理模式背后的动机之前，首先需要说明一下Java虚拟机是如果判定两个Java类是相同的。Java虚拟机不仅要看类的全名是否相同，还要看加载此类的类加载器是否一样。只有两者都相同的情况下，才认为两个类是相同的。即便是同样的字节代码，被不同的类加载器加载之后所得到的类，也是不同的。比如一个Java类com.example.Sample，编译之后生成了字节码文件Sample.class文件，并定义出两个java.lang.Class类的实例来表示这个类。这两个实例是不相同的。对于Java虚拟机来说，它们是不同的类，试图对这两个类的对象相互赋值，会抛出运行异常ClassCastException。下面通过示例来具体说明。
package com.example;
public class Sample {
private Sample instance;
public void setSample(Object instance) {
this.instance = (Sample)instance;
}
}
如上所示，com.example.Simple类的方法setSample接受一个java.lang.Object类型的参数，并且会把该参数强制转换成com.example.Sample类型。测试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();
}
}
上例中使用了类FileSystemClassLoader的两个不同实例来分别加载类com.example.Sample，得到了两个不同的java.lang.Class的实例，接着通过newInstance()方法分别生成了两个类的对象obj1和obj2，最后通过Java的反射API在对象obj1上调用方法setSample，试图把对象obj2给obj1内部的instance对象。运行结果如下所示。
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虚拟机认为是相同的。
了解了这一点之后，就可以理解代理模式的设计动机了。代理模式是为了保证Java核心库的类型安全。所有Java应用都至少需要引用java.lang.Object类，而且这些类之间是不兼容的。通过代理模式，对于Java核心库的加载工作由引导类加载器来同意完成，保证了Java应用所使用的是同一个版本的Java核心库的类，是互相兼容的。
不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在Java虚拟机中，只需要用不同的类加载器来加载他们即可。不同类加载器加载的类之间是不兼容的，这就相当于在Java虚拟机内部创建了一个个相互隔离的Java类空间。这种技术在许多框架中都被用到，后面会详细介绍。
加载类的过程
在前面介绍类加载器的代理模式的时候，提到过类加载器会首先代理给其它类加载器来尝试加载某个类。这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载器，有可能不是同一个。真正完成类加载工作是通过调用defineClass来实现的；而启动类的加载过程是通过调用loadClass来实现的。前者成为一个类的定义加载器（defining loader），后者成为初始加载器（initiating loader）。在Java虚拟机判断两个类是否相同的时候，使用的是类定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两种类加载器的关联之处就在于：一个类的定义加载器是它引用的其它类的初始加载器。如类com.example.Outer的定义加载器负责启动类com.example.Inner的加载过程。
方法loadClass（）抛出的是java.lang.ClassNotFoundException异常，方法defineClass（）抛出的是java.lang.NoclassDefoundError异常。
类加载器在成功加载某个类之后，会把得到的java.lang.Class类的实例缓存起来。下次在请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。也就是说，对于一个类加载器的实例来说，相同全名的类只加载一次，即loaderClass方法不会被重复调用。
下面讨论另外一种类加载器：线程上下文类加载器。
线程上下文类加载器
线程上下文类加载器（context class loader）是从JDK1.2开始引入的。类java.lang.Thread中的方法getContextClassLoader()和setContextClassLoader(ClassLoader cl)用来获取和设置线程的上下文类加载器。如果没有通过setContextClassLoader(ClassLoader cl)方法进行设置的话，线程将继承其父线程的上下文加载器。Java应用运行的初始线程的上下文类加载器是系统类加载器。在线程中运行的代码可以通过此类加载器来加载类和资源。
前面提到的类加载器的代理模式并不能解决Java应用开发中会遇到的类加载器的全部问题。Java提供了很多服务提供者接口（Service Provider Interface，SPI），允许第三方为这些接口提供实现。常见的SPI有JDBC、JCE、JNDI、JAXP和JBI等。这些SPI接口由Java核心库来提供，如JAXP的SPI接口定义包含在javax.xml.parsers包中。这些SPI的实现代码很可能是作为Java应用所依赖的jar包被包含进来，可以通过类路径（CLASSPATH）来找到，如实现的JAXP SPI的Apache Xerces所包含的jar包。SPI接口中的代码经常需要加载具体的实现类。如JAXP中的javax.xml.parsers.DocumentBuilderFactory类中的newInstance()方法用来生成一个新的DocumentBuilderFactory的实例。这里的实例的真正的类是继承自javax.xml.parsers.DocumentBuilderFactory ，是由SPI的实现锁提供的。如在Apache Xerces中，实现的类是org.apache.xerces.jaxp.DocumentBuilderFactoryImpl。而问题在于，SPI的接口是Java核心库的一部分，是由引导类加载器来加载的；SPI实现的Java类一般是由系统类加载器来加载的。引导类加载器是无法找到SPI的实现类的，因为它只加载Java的核心库。它也不能代理给系统类加载器，因为它是系统类加载器的祖先类加载器。也就是说，类加载器的代理模式无法解决这个问题。
线程上下文加载器正好解决了这个问题。如果不做任何的设置，Java应用的线上上下文类加载器默认就是系统上下文类加载器。在SPI接口的代码中使用线程上下文类加载器，就可以成功的加载到SPI实现的类。线程上下文类加载器在很多SPI的实现中都会用到。
下面介绍另外一种加载类的方法：Class.forName。
Class.forName
Class.forName是一个静态方法， 同样可以用来加载类。改方法有两种形式：Class.forName(String name, boolean initialize, ClassLoader loader)和Class.forName(String className)。第一种形式的参数name表示的是类的全名；initialize表示是否初始化类；loader表示加载时使用的类加载器。第二种形式则相当于设置了参数initialize的值为true，loader的值为当前类的类加载器。Class.forName的一个很常见的用法是在加载数据库驱动的时候。如Class.forName(“org.apache.derby.jdbc.EmbeddedDriver”).newInstance用来加载Apache Derby数据库的驱动。
扫一扫
8556
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
