浅谈Java类加载器

原文转自：http://blog.csdn.net/cxhzqhzq/article/details/6686121

1.  从ClassNotFoundException谈起

编码的时候，我们常常可以看到ClassNotFoundException，比如在jdbc连接的时候，引入jar包不完全的时候等，我们一看就知道这个是由于找不到相关类库导致的，那么这个是从什么地方产生的？为什么会抛出这个异常呢？这就是本文要解决的问题。

2.  类加载器是什么

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

基本上所有的类加载器都是 java.lang.ClassLoader 类的一个实例。

2.1.  ClassLocader类介绍

java.lang.ClassLoader 类的基本职责就是根据一个指定的类的名称，找到或者生成其对应的字节代码，然后从这些字节代码中定义出一个Java 类，即 java.lang.Class 类的一个实例。除此之外，ClassLoader 还负责加载 Java 应用所需的资源，如图像文件和配置文件等。

这里我们只讨论其加载类的功能。为了完成加载类的这个职责，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 name, byte[] b, int off, int len)

把字节数组 b 中的内容转换成 Java 类，返回的结果是 java.lang.Class 类的实例。这个方法被声明为 final 的。

resolveClass(Class<?> c)

链接指定的 Java 类。

 

类加载器是负责加载类的对象。ClassLoader 类是一个抽象类。如果给定类的二进制名称，那么类加载器会试图查找或生成构成类定义的数据。一般策略是将名称转换为某个文件名，然后从文件系统读取该名称的“类文件”。

每个 Class 对象都包含一个对定义它的 ClassLoader 的引用。

数组类的 Class 对象不是由类加载器创建的，而是由 Java 运行时根据需要自动创建。数组类的类加载器由 Class.getClassLoader()返回，该加载器与其元素类型的类加载器是相同的；如果该元素类型是基本类型，则该数组类没有类加载器。

应用程序需要实现ClassLoader 的子类，以扩展 Java 虚拟机动态加载类的方式。

ClassLoader类使用委托模型来搜索类和资源。每个 ClassLoader 实例都有一个相关的父类加载器。需要查找类或资源时，ClassLoader实例会在试图亲自查找类或资源之前，将搜索类或资源的任务委托给其父类加载器。虚拟机的内置类加载器（称为 “bootstrapclass loader”）本身没有父类加载器，但是可以将它用作 ClassLoader 实例的父类加载器。

3.  分类

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 类一样，也是要由类加载器来加载的。一般来说，开发人员编写的类加载器的父类加载器是系统类加载器。类加载器通过这种方式组织起来，形成树状结构。树的根节点就是引导类加载器。下图中给出了一个典型的类加载器树状组织结构示意图，其中的箭头指向的是父类加载器。

3.1.  类加载过程

在前面介绍类加载器的代理模式的时候，提到过类加载器会首先代理给其它类加载器来尝试加载某个类。这就意味着真正完成类的加载工作的类加载器和启动这个加载过程的类加载器，有可能不是同一个。真正完成类的加载工作是通过调用defineClass 来实现的；而启动类的加载过程是通过调用loadClass 来实现的。前者称为一个类的定义加载器（defining loader），后者称为初始加载器（initiating loader）。在 Java 虚拟机判断两个类是否相同的时候，使用的是类的定义加载器。也就是说，哪个类加载器启动类的加载过程并不重要，重要的是最终定义这个类的加载器。两种类加载器的关联之处在于：一个类的定义加载器是它引用的其它类的初始加载器。如类com.example.Outer引用了类com.example.Inner，则由类 com.example.Outer 的定义加载器负责启动类com.example.Inner 的加载过程。

方法 loadClass() 抛出的是 java.lang.ClassNotFoundException 异常；方法defineClass() 抛出的是java.lang.NoClassDefFoundError 异常。

类加载器在成功加载某个类之后，会把得到的 java.lang.Class 类的实例缓存起来。下次再请求加载该类的时候，类加载器会直接使用缓存的类的实例，而不会尝试再次加载。也就是说，对于一个类加载器实例来说，相同全名的类只加载一次，即loadClass 方法不会被重复调用。

3.2.  类加载代理机制

类加载器在尝试自己去查找某个类的字节代码并定义它时，会先代理给其父类加载器，由父类加载器先去尝试加载这个类，依次类推,这种方式称为代理模型。

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

了解了这一点之后，就可以理解代理模式的设计动机了。代理模式是为了保证 Java 核心库的类型安全。所有 Java 应用都至少需要引用 java.lang.Object 类，也就是说在运行的时候，java.lang.Object 这个类需要被加载到 Java 虚拟机中。如果这个加载过程由 Java 应用自己的类加载器来完成的话，很可能就存在多个版本的 java.lang.Object类，而且这些类之间是不兼容的。通过代理模式，对于 Java 核心库的类的加载工作由引导类加载器来统一完成，保证了 Java 应用所使用的都是同一个版本的 Java 核心库的类，是互相兼容的。

不同的类加载器为相同名称的类创建了额外的名称空间。相同名称的类可以并存在 Java 虚拟机中，只需要用不同的类加载器来加载它们即可。不同类加载器加载的类之间是不兼容的，这就相当于在 Java 虚拟机内部创建了一个个相互隔离的 Java 类空间。这种技术在许多框架中都被用到。

我们可以通过分析java.lang.ClassLoader中的loadClass（String name）方法的代码就可以分析出虚拟机默认采用的代理模型到底是什么模样：

[java] view plaincopy

1. /** 
2.      * Loads the class with the specified <a href="#name">binary name</a>.  The 
3.      * default implementation of this method searches for classes in the 
4.      * following order: 
5.      * 
6.      * <p><ol> 
7.      * 
8.      *   <li><p> Invoke {@link #findLoadedClass(String)} to check if the class 
9.      *   has already been loaded.  </p></li> 
10.      * 
11.      *   <li><p> Invoke the {@link #loadClass(String) <tt>loadClass</tt>} method 
12.      *   on the parent class loader.  If the parent is <tt>null</tt> the class 
13.      *   loader built-in to the virtual machine is used, instead.  </p></li> 
14.      * 
15.      *   <li><p> Invoke the {@link #findClass(String)} method to find the 
16.      *   class.  </p></li> 
17.      * 
18.      * </ol> 
19.      * 
20.      * <p> If the class was found using the above steps, and the 
21.      * <tt>resolve</tt> flag is true, this method will then invoke the {@link 
22.      * #resolveClass(Class)} method on the resulting <tt>Class</tt> object. 
23.      * 
24.      * <p> Subclasses of <tt>ClassLoader</tt> are encouraged to override {@link 
25.      * #findClass(String)}, rather than this method.  </p> 
26.      * 
27.      * <p> Unless overridden, this method synchronizes on the result of 
28.      * {@link #getClassLoadingLock <tt>getClassLoadingLock</tt>} method 
29.      * during the entire class loading process. 
30.      * 
31.      * @param  name The <a href="#name">binary name</a> of the class 
32.      * 
33.      * @param  resolve  If <tt>true</tt> then resolve the class 
34.      * 
35.      * @return  The resulting <tt>Class</tt> object 
36.      * 
37.      * @throws  ClassNotFoundException  If the class could not be found 
38.      */  
39.     protected Class<?> loadClass(String name, boolean resolve)  
40.         throws ClassNotFoundException  
41.     {  
42.         synchronized (getClassLoadingLock(name)) {  
43.             // First, check if the class has already been loaded  
44.             Class c = findLoadedClass(name);  
45.             ////如果没有被加载，就委托给父类加载或者委派给启动类加载器加载  
46.             if (c == null) {  
47.                 long t0 = System.nanoTime();  
48.                 try {  
49.                     ////如果存在父类加载器，就委派给父类加载器加载  
50.                     if (parent != null) {  
51.                         c = parent.loadClass(name, false);  
52.                     } else {  
53.                         ////如果不存在父类加载器，就检查是否是由启动类加载器加载的类，  
54.                         //通过调用本地方法native Class findBootstrapClass(String name)  
55.                         c = findBootstrapClassOrNull(name);  
56.                     }  
57.                 } catch (ClassNotFoundException e) {  
58.                     // ClassNotFoundException thrown if class not found  
59.                     // from the non-null parent class loader  
60.                 }  
61.   
62.                 if (c == null) {  
63.                     // If still not found, then invoke findClass in order  
64.                     // to find the class.  
65.                     // // 如果父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能  
66.                     long t1 = System.nanoTime();  
67.                     c = findClass(name);  
68.   
69.                     // this is the defining class loader; record the stats  
70.                     sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);  
71.                     sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);  
72.                     sun.misc.PerfCounter.getFindClasses().increment();  
73.                 }  
74.             }  
75.             if (resolve) {  
76.                 resolveClass(c);  
77.             }  
78.             return c;  
79.         }  
80.     }  

通过上面对于源代码的分析 ，相比大家都已近对代理模型有所了解了吧。

4.  java程序动态扩展方式

Java的连接模型允许用户运行时扩展引用程序，既可以通过当前虚拟机中预定义的加载器加载编译时已知的类或者接口，又允许用户自行定义类装载器，在运行时动态扩展用户的程序。通过用户自定义的类装载器，你的程序可以装载在编译时并不知道或者尚未存在的类或者接口，并动态连接它们并进行有选择的解析。

运行时动态扩展java应用程序有调用Class.forName方法和自定义类加载器两种方法。

4.1.  调用java.lang.Class.forName(…)

[java] view plaincopy

1. public static Class<?> forName(String className)  
2. public static Class<?> forName(String name, boolean initialize,  
3.                                    ClassLoader loader)  

Class.forName 是一个静态方法，同样可以用来加载类。该方法有两种形式：Class.forName(Stringname, 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 数据库的驱动。

说明：

在一个实例方法中，表达式：

 Class.forName("Foo")

等效于：

 Class.forName("Foo", true, this.getClass().getClassLoader())

4.2.  用户自定义类加载器

一般用户自定义类加载器的工作流程如下：

1、首先检查请求的类型是否已经被这个类装载器装载到命名空间中了，如果已经装载，直接返回；否则转入步骤2

2、委派类加载请求给父类加载器（更准确的说应该是双亲类加载器，真个虚拟机中各种类加载器最终会呈现树状结构），如果父类加载器能够完成，则返回父类加载器加载的Class实例；否则转入步骤3

3、调用本类加载器的findClass（…）方法，试图获取对应的字节码，如果获取的到，则调用defineClass（…）导入类型到方法区；如果获取不到对应的字节码或者其他原因失败，返回异常给loadClass（…）， loadClass（…）转抛异常，终止加载过程（注意：这里的异常种类不止一种）。

下面是一个自己写的类加载器的示例：

[java] view plaincopy

1. public class FileSystemClassLoader extends ClassLoader {   
2.   
3.     private String rootDir;   
4.   
5.     public FileSystemClassLoader(String rootDir) {   
6.         this.rootDir = rootDir;   
7.     }   
8.   
9.     protected Class<?> findClass(String name) throws ClassNotFoundException {   
10.         byte[] classData = getClassData(name);   
11.         if (classData == null) {   
12.             throw new ClassNotFoundException();   
13.         }   
14.         else {   
15.             return defineClass(name, classData, 0, classData.length);   
16.         }   
17.     }   
18.   
19.     private byte[] getClassData(String className) {   
20.         String path = classNameToPath(className);   
21.         try {   
22.             InputStream ins = new FileInputStream(path);   
23.             ByteArrayOutputStream baos = new ByteArrayOutputStream();   
24.             int bufferSize = 4096;   
25.             byte[] buffer = new byte[bufferSize];   
26.             int bytesNumRead = 0;   
27.             while ((bytesNumRead = ins.read(buffer)) != -1) {   
28.                 baos.write(buffer, 0, bytesNumRead);   
29.             }   
30.             return baos.toByteArray();   
31.         } catch (IOException e) {   
32.             e.printStackTrace();   
33.         }   
34.         return null;   
35.     }   
36.   
37.     private String classNameToPath(String className) {   
38.         return rootDir + File.separatorChar   
39.                 + className.replace('.', File.separatorChar) + ".class";   
40.     }   
41. }  

类 FileSystemClassLoader 继承自类java.lang.ClassLoader，一般来说，自己开发的类加载器只需要覆写findClass(String name) 方法即可。java.lang.ClassLoader 类的方法 loadClass() 封装了前面提到的代理模式的实现。该方法会首先调用findLoadedClass() 方法来检查该类是否已经被加载过；如果没有加载过的话，会调用父类加载器的loadClass() 方法来尝试加载该类；如果父类加载器无法加载该类的话，就调用 findClass() 方法来查找该类。因此，为了保证类加载器都正确实现代理模式，在开发自己的类加载器时，最好不要覆写 loadClass() 方法，而是覆写 findClass() 方法。

类 FileSystemClassLoader 的 findClass() 方法首先根据类的全名在硬盘上查找类的字节代码文件（.class 文件），然后读取该文件内容，最后通过 defineClass() 方法来把这些字节代码转换成 java.lang.Class 类的实例。

5.  预先加载与依需求加载

Java 运行环境为了优化系统，提高程序的执行速度，在 JRE 运行的开始会将 Java 运行所需要的基本类采用预先加载（ pre-loading ）的方法全部加载要内存当中，因为这些单元在 Java 程序运行的过程当中经常要使用的，主要包括 JRE 的 rt.jar 文件里面所有的 .class 文件。

当 java.exe 虚拟机开始运行以后，它会找到安装在机器上的 JRE 环境，然后把控制权交给 JRE ， JRE 的类加载器会将 lib 目录下的 rt.jar 基础类别文件库加载进内存，这些文件是 Java 程序执行所必须的，所以系统在开始就将这些文件加载，避免以后的多次 IO 操作，从而提高程序执行效率。

相对于预先加载，我们在程序中需要使用自己定义的类的时候就要使用依需求加载方法（ load-on-demand ），就是在 Java 程序需要用到的时候再加载，以减少内存的消耗，因为 Java 语言的设计初衷就是面向嵌入式领域的。

在这里还有一点需要说明的是， JRE 的依需求加载究竟是在什么时候把类加载进入内部的呢？

我们在定义一个类实例的时候，比如 TestClassAtestClassA ，这个时候 testClassA 的值为 null ，也就是说还没有初始化，没有调用 TestClassA 的构造函数，只有当执行 testClassA= new TestClassA() 以后， JRE 才正真把 TestClassA 加载进来。

 

6.  隐式加载和显示加载

Java 的加载方式分为隐式加载（ implicit ）和显示加载（ explicit ）。所谓隐式加载就是我们在程序中用 new 关键字来定义一个实例变量， JRE 在执行到 new 关键字的时候就会把对应的实例类加载进入内存。隐式加载的方法很常见，用的也很多， JRE 系统在后台自动的帮助用户加载，减少了用户的工作量，也增加了系统的安全性和程序的可读性。

相对于隐式加载的就是我们不经常用到的显示加载。所谓显示加载就是有程序员自己写程序把需要的类加载到内存当中，下面我们看一段程序：

[java] view plaincopy

1. package com.mytestcodes.classloader;  
2.   
3. class TestClass  
4. {  
5.     public void method()  
6.     {  
7.         System.out.println("TestClass-method");  
8.     }  
9. }  
10.   
11. public class CLTest  
12. {  
13.     public static void main(String args[])  
14.     {  
15.         try  
16.         {  
17.             Class<?> c = Class.forName("com.mytestcodes.classloader.TestClass");  
18.             TestClass object = (TestClass) c.newInstance();  
19.             object.method();  
20.         } catch (Exception e)  
21.         {  
22.             e.printStackTrace();  
23.         }  
24.     }  
25. }  

7.  类加载器与OSGI

OSGi™是 Java 上的动态模块系统。它为开发人员提供了面向服务和基于组件的运行环境，并提供标准的方式用来管理软件的生命周期。OSGi 已经被实现和部署在很多产品上，在开源社区也得到了广泛的支持。Eclipse 就是基于 OSGi 技术来构建的。

OSGi中的每个模块（bundle）都包含 Java 包和类。模块可以声明它所依赖的需要导入（import）的其它模块的 Java 包和类（通过 Import-Package），也可以声明导出（export）自己的包和类，供其它模块使用（通过 Export-Package）。也就是说需要能够隐藏和共享一个模块中的某些 Java 包和类。这是通过 OSGi 特有的类加载器机制来实现的。OSGi 中的每个模块都有对应的一个类加载器。它负责加载模块自己包含的 Java 包和类。当它需要加载 Java 核心库的类时（以 java 开头的包和类），它会代理给父类加载器（通常是启动类加载器）来完成。当它需要加载所导入的 Java 类时，它会代理给导出此 Java 类的模块来完成加载。模块也可以显式的声明某些 Java 包和类，必须由父类加载器来加载。只需要设置系统属性org.osgi.framework.bootdelegation 的值即可。

假设有两个模块bundleA 和bundleB，它们都有自己对应的类加载器 classLoaderA 和 classLoaderB。在 bundleA 中包含类 com.bundleA.Sample，并且该类被声明为导出的，也就是说可以被其它模块所使用的。bundleB 声明了导入 bundleA 提供的类com.bundleA.Sample，并包含一个类com.bundleB.NewSample 继承自 com.bundleA.Sample。在 bundleB 启动的时候，其类加载器 classLoaderB 需要加载类 com.bundleB.NewSample，进而需要加载类com.bundleA.Sample。由于bundleB 声明了类com.bundleA.Sample 是导入的，classLoaderB 把加载类 com.bundleA.Sample 的工作代理给导出该类的 bundleA 的类加载器 classLoaderA。classLoaderA 在其模块内部查找类com.bundleA.Sample 并定义它，所得到的类 com.bundleA.Sample 实例就可以被所有声明导入了此类的模块使用。对于以 java 开头的类，都是由父类加载器来加载的。如果声明了系统属性org.osgi.framework.bootdelegation=com.example.core.*，那么对于包 com.example.core中的类，都是由父类加载器来完成的。

OSGi模块的这种类加载器结构，使得一个类的不同版本可以共存在 Java 虚拟机中，带来了很大的灵活性。不过它的这种不同，也会给开发人员带来一些麻烦，尤其当模块需要使用第三方提供的库的时候。

如果一个类库被多个模块共用，可以为这个类库单独的创建一个模块，把其它模块需要用到的 Java 包声明为导出的。其它模块声明导入这些类。

如果类库提供了 SPI 接口，并且利用线程上下文类加载器来加载 SPI 实现的 Java 类，有可能会找不到 Java 类。如果出现了NoClassDefFoundError 异常，首先检查当前线程的上下文类加载器是否正确。通过Thread.currentThread().getContextClassLoader() 就可以得到该类加载器。该类加载器应该是该模块对应的类加载器。如果不是的话，可以首先通过 class.getClassLoader()来得到模块对应的类加载器，再通过Thread.currentThread().setContextClassLoader() 来设置当前线程的上下文类加载器。