ClassLoader详解

ClassLoader详解

目录

1.什么是C LASS L OADER (2)

2.C LASS L OADER的层次 (2)

3.C LASS L OADER加载C LASS的过程 (5)

4.类加载器的顺序 (5)

5.JVM是如何来建立类加载器的结构 (6)

6.如何实现在运行时的动态载入和更新 (9)

7.为什么要扩展C LASS L OADER (14)

8.C LASS L OADER树和委托模型 (14)

9.U NLOADING?R ELOADING? (15)

10.由名字空间引发的 (16)

11.类的查询 (18)

12.一些重要的方法 (20)

13.怎么组装这些方法 (21)

14.J AV A 2中C LASS L OADER 的变动 (21)

15.类与数据 (22)

16.类加载器如何工作? (23)

17.名词解释 (27)

18.T IPS (27)

19.类加载原则概括： (29)

20.问题 (29)

21.其他 (34)

1.什么是ClassLoader

与普通程序不同的是，Java程序（class文件）并不是本地的可执行程序。当运行Java程序时，首先运行JVM（Java虚拟机），然后再把Java class加载到JVM 里头运行，负责加载Java class的这部分就叫做Class Loader。

JVM本身包含了一个ClassLoader称为Bootstrap ClassLoader，和JVM一样，Bootstrap ClassLoader是用本地代码实现的，它负责加载核心Java Class（即所有java.*开头的类）。另外JVM还会提供两个ClassLoader，它们都是用Java语言编写的，由Bootstrap ClassLoader加载；其中Extension ClassLoader负责加载扩展的Java class（例如所有javax.*开头的类和存放在JRE的ext目录下的类），Application ClassLoader负责加载应用程序自身的类。

术语“类加载”指的是找出一个给定类名的字节所在的位置并且将这些字节转换成Java类实例的过程。

2.ClassLoader的层次

bootstrap classloader

|

extension classloader

|

app classloader

app classloader 的parent是extension classloader，extension classloader的parent 是bootstrap classloader，bootstrap classloader的parent 是Null。

继承结构：

Bootstrap ClassLoader

|__URLClassLoader

|__ExtClassLoader

|__AppClassLoader

Bootstrap classloader：引导（也称为原始）类加载器，它负责加载Java的核心类。在Sun的JVM中，在执行java的命令中使用-Xbootclasspath选项或使用- D 选项指定sun.boot.class.path系统属性值可以指定附加的类。这个加载器的是非常特殊的，它实际上不是https://www.360docs.net/doc/0d5408465.html,ng.ClassLoader的子类，而是由JVM自身实现的。大家可以通过执行以下代码来获得bootstrap classloader加载了那些核心类库：

URL[] urls=https://www.360docs.net/doc/0d5408465.html,uncher.getBootstrapClassPath().getURLs();

for (int i = 0; i < urls.length; i++) {

System.out.println(urls[i].toExternalForm());

}

在我的计算机上的结果为：

file:/D:/jre1.5.0_06/lib/rt.jar

file:/D:/jre1.5.0_06/lib/i18n.jar

file:/D:/jre1.5.0_06/lib/sunrsasign.jar

file:/D:/jre1.5.0_06/lib/jsse.jar

file:/D:/jre1.5.0_06/lib/jce.jar

file:/D:/jre1.5.0_06/lib/charsets.jar

file:/D:/jre1.5.0_06/classes

这时大家知道了为什么我们不需要在系统属性CLASSPA TH中指定这些类库了吧，因为JVM在启动的时候就自动加载它们了。

Extension classloader：扩展类加载器，它负责加载JRE的扩展目录（JA V A_HOME/jre/lib/ext或者由java.ext.dirs系统属性指定的）中JAR的类包。这为引入除Java核心类以外的新功能提供了一个标准机制。因为默认的扩展目录对所有从同一个JRE中启动的JVM都是通用的，所以放入这个目录的JAR 类包对所有的JVM和app classloader都是可见的。在这个实例上调用方法getParent()总是返回空值null，因为引导加载器bootstrap classloader不是一个真

正的ClassLoader实例。所以当大家执行以下代码时：

System.out.println(System.getProperty("java.ext.dirs"));

ClassLoader extensionClassloader=ClassLoader.getSystemClassLoader().getParent(); System.out.println("the parent of extension classloader : "+extensionClassloader.getParent());

结果为：

D:\jre1.5.0_06\lib\ext

The parent of extension classloader : null

extension classloader是app classloader的parent，而bootstrap classloader是extension classloader的parent，但它不是一个实际的classloader，所以为null。App classloader：应用（也称为系统）类加载器，它负责在JVM被启动时，加载来自在命令java中的-classpath或者java.class.path系统属性或者CLASSPA TH 操作系统属性所指定的JAR类包和类路径。总能通过静态方法ClassLoader.getSystemClassLoader()找到该类加载器。如果没有特别指定，则用户自定义的任何类加载器都将该类加载器作为它的父加载器。执行以下代码即

可获得：

System.out.println(System.getProperty("java.class.path"));

输出结果则为用户在系统属性里面设置的CLASSPA TH。

classloader 加载类用的是全盘负责委托机制。所谓全盘负责，即是当一个classloader加载一个Class的时候，这个Class所依赖的和引用的所有Class也由这个classloader负责载入，除非是显式的使用另外一个classloader载入；委托机制则是先让parent（父）类加载器(而不是super，它与parent classloader类不是继承关系)寻找，只有在parent找不到的时候才从自己的类路径中去寻找。此外类加载还采用了cache机制，也就是如果cache中保存了这个Class就直接返回

它，如果没有才从文件中读取和转换成Class，并存入cache，这就是为什么我们修改了Class但是必须重新启动JVM才能生效的原因。

3.ClassLoader加载Class的过程

1.检测此Class是否载入过（即在cache中是否有此Class），如果有到8,如果没

有到2。

2.如果parent classloader不存在（没有parent，那parent一定是bootstrap classloader

了），到4。

3.请求parent classloader载入，如果成功到8，不成功到5。

4.请求jvm从bootstrap classloader中载入，如果成功到8。

5.寻找Class文件（从与此classloader相关的类路径中寻找）。如果找不到则到7。

6.从文件中载入Class，到8。

7.抛出ClassNotFoundException。

8.返回Class.。

其中5、6步我们可以通过覆盖ClassLoader的findClass方法来实现自己的载入策略。甚至覆盖loadClass方法来实现自己的载入过程。

4.类加载器的顺序

先是bootstrap classloader，然后是extension classloader，最后才是app classloader。大家会发现加载的Class越是重要的越在靠前面。这样做的原因是出于安全性的考虑，试想如果app classloader“亲自”加载了一个具有破坏性的

“https://www.360docs.net/doc/0d5408465.html,ng.System”类的后果吧。这种委托机制保证了用户即使具有一个这样的

类，也把它加入到了类路径中，但是它永远不会被载入，因为这个类总是由

bootstrap classloader来加载的。大家可以执行一下以下的代码：

System.out.println(System.class.getClassLoader());

将会看到结果是null，这就表明https://www.360docs.net/doc/0d5408465.html,ng.System是由bootstrap classloader加载的，因为bootstrap classloader不是一个真正的ClassLoader实例，而是由JVM实现的，正如前面已经说过的。

5.JVM是如何来建立类加载器的结构

https://www.360docs.net/doc/0d5408465.html,uncher，顾名思义，当你执行java命令的时候，JVM会先使用bootstrap classloader载入并初始化一个Launcher，执行下来代码：

System.out.println("the Launcher's classloader is

"+https://www.360docs.net/doc/0d5408465.html,uncher.getLauncher().getClass().getClassLoader());

结果为：

the Launcher's classloader is null (因为是用bootstrap classloader加载,所以class loader为null)

Launcher 会根据系统和命令设定初始化好class loader结构，JVM就用它来获得extension classloader和app classloader,并载入所有的需要载入的Class，最后执行java命令指定的带有静态的main方法的Class。extension classloader实际上是https://www.360docs.net/doc/0d5408465.html,uncher$ExtClassLoader类的一个实例，app classloader实际上是https://www.360docs.net/doc/0d5408465.html,uncher$AppClassLoader类的一个实例。并且都是https://www.360docs.net/doc/0d5408465.html,.URLClassLoader的子类。

让我们来看看Launcher初试化的过程的部分代码。

Launcher的部分代码：

public class Launcher {

public Launcher() {

ExtClassLoader extclassloader;

try {

//初始化extension classloader

extclassloader = ExtClassLoader.getExtClassLoader();

} catch(IOException ioexception) {

throw new InternalError("Could not create extension class loader");

}

try {

//初始化system classloader，parent是extension classloader

loader = AppClassLoader.getAppClassLoader(extclassloader);

} catch(IOException ioexception1) {

throw new InternalError("Could not create application class loader");

}

//将system classloader设置成当前线程的context classloader（将在后面加以介绍）

Thread.currentThread().setContextClassLoader(loader);

......

}

public ClassLoader getClassLoader() {

//返回system classloader

return loader;

}

}

Extension classloader的部分代码：

static class Launcher$ExtClassLoader extends URLClassLoader {

public static Launcher$ExtClassLoader getExtClassLoader()

throws IOException {

File afile[] = getExtDirs();

return

(Launcher$ExtClassLoader)AccessController.doPrivileged(new

Launcher$1(afile));

}

private static File[] getExtDirs() {

//获得系统属性“java.ext.dirs”

String s = System.getProperty("java.ext.dirs");

File afile[];

if(s != null) {

StringTokenizer stringtokenizer = new StringTokenizer(s, File.pathSeparator);

int i = stringtokenizer.countTokens();

afile = new File;

for(int j = 0; j < i; j++)

afile[j] = new File(stringtokenizer.nextToken());

} else {

afile = new File[0];

}

return afile;

}

}

App classloader的部分代码：

static class Launcher$AppClassLoader extends URLClassLoader

{

public static ClassLoader getAppClassLoader(ClassLoader classloader)

throws IOException {

//获得系统属性“java.class.path”

String s = System.getProperty("java.class.path");

File afile[] = s != null ? Launcher.access$200(s) : new File[0];

return

(Launcher$AppClassLoader)AccessController.doPrivileged(new

Launcher$2(s, afile, classloader));

}

}

Extension classloader是使用系统属性“java.ext.dirs”设置类搜索路径的，并且没有parent。app classloader是使用系统属性“java.class.path”设置类搜索路径的，并且有一个parent classloader。Launcher初始化extension classloader，app classloader，并将app classloader设置成为context classloader，但是仅仅返回app classloader给JVM。

这里怎么又出来一个context classloader呢？它有什么用呢？我们在建立一个线程Thread的时候，可以为这个线程通过setContextClassLoader方法来指定一个合适的classloader作为这个线程的context classloader，当此线程运行的时候，我们可以通过getContextClassLoader方法来获得此context classloader，就可以用它来载入我们所需要的Class。默认的是app classloader。利用这个特性，我们可以“打破”classloader委托机制了，父classloader可以获得当前线程的context classloader，而这个context classloader可以是它的子classloader或者其他的classloader，那么父classloader就可以从其获得所需的Class，这就打破了只能向父classloader请求的限制了。这个机制可以满足当我们的classpath是在运行时才确定,并由定制的classloader加载的时候,由app classloader(即在jvm classpath中)加载的class可以通过context classloader获得定制的classloader并加载入特定的class(通常是抽象类和接口,定制的classloader中是其实现),例如web 应用中的servlet就是用这种机制加载的。

6.如何实现在运行时的动态载入和更新

只要我们能够动态改变类搜索路径和清除classloader的cache中已经载入的Class就行了，有两个方案，一是我们继承一个classloader，覆盖loadclass方法，动态的寻找Class文件并使用defineClass方法；另一个则非常简单实用，只

要重新使用一个新的类搜索路径来new一个classloader就行了，这样即更新了类搜索路径以便来载入新的Class，也重新生成了一个空白的cache(当然,类搜索路径不一定必须更改)。噢，太好了，我们几乎不用做什么工作，https://www.360docs.net/doc/0d5408465.html,URLClassLoader正是一个符合我们要求的classloader！我们可以直接使用或者继承它就可以了！

这是j2se1.4 API的doc中URLClassLoader的两个构造器的描述：

URLClassLoader(URL[] urls)

Constructs a new URLClassLoader for the specified URLs using the default delegation parent ClassLoader.

URLClassLoader(URL[] urls, ClassLoader parent)

Constructs a new URLClassLoader for the given URLs.

其中URL[] urls就是我们要设置的类搜索路径，parent就是这个classloader 的parent classloader，默认的是app classloader。

好，现在我们能够动态的载入Class了，这样我们就可以利用newInstance 方法来获得一个Object。但我们如何将此Object造型呢？可以将此Object造型成它本身的Class吗？

首先让我们来分析一下java源文件的编译，运行吧！javac命令是调用“JA V A_HOME/lib/tools.jar”中的“com.sun.tools.javac.Main”的compile方法来编译：

public static int compile(String as[]);

public static int compile(String as[], PrintWriter printwriter);

返回0表示编译成功，字符串数组as则是我们用javac命令编译时的参数，以空格划分。例如：

javac -classpath c:\foo\bar.jar;. -d c:\ c:\Some.java

则字符串数组as为{"-classpath","c:\\foo\\bar.jar;.","-d","c:\\","c:\\Some.java"}，如果带有PrintWriter参数，则会把编译信息出到这个指定的printWriter中。默认的输出是System.err。

其中Main是由JVM使用Launcher初始化的app classloader载入的，根据全盘负责原则[1]，编译器在解析这个java源文件时所发现的它所依赖和引用的所有Class也将由app classloader载入，如果app classloader不能载入某个Class 时，编译器将抛出一个“cannot resolve symbol”错误。

所以首先编译就通不过，也就是编译器无法编译一个引用了不在CLASSPA TH中的未知Class的java源文件，而由于拼写错误或者没有把所需类库放到CLASSPA TH中，大家一定经常看到这个“cannot resolve symbol”这个编译错误吧！

其次，就是我们把这个Class放到编译路径中，成功的进行了编译，然后在运行的时候不把它放入到CLASSPA TH中而利用我们自己的classloader来动态载入这个Class，这时候也会出现“https://www.360docs.net/doc/0d5408465.html,ng.NoClassDefFoundError”的违例，为什么呢？

我们再来分析一下，首先调用这个造型语句的可执行的Class一定是由JVM 使用Launcher初始化的app classloader载入的，根据全盘负责原则，当我们进行造型的时候，JVM也会使用app classloader来尝试载入这个Class来对实例进行造型，自然在app classloader寻找不到这个Class时就会抛出“https://www.360docs.net/doc/0d5408465.html,ng.NoClassDefFoundError”的违例。

OK，现在让我们来总结一下，java文件的编译和Class的载入执行，都是使用Launcher初始化的app classloader作为类载入器的，我们无法动态的改变

app classloader，更无法让JVM使用我们自己的classloader来替换app classloader，根据全盘负责原则，就限制了编译和运行时，我们无法直接显式的使用一个app classloader寻找不到的Class，即我们只能使用Java核心类库，扩展类库和CLASSPA TH中的类库中的Class。

还不死心！再尝试一下这种情况，我们把这个Class也放入到CLASSPA TH 中，让app classloader能够识别和载入。然后我们通过自己的classloader来从指定的class文件中载入这个Class（不能够委托parent载入，因为这样会被app classloader从CLASSPA TH中将其载入），然后实例化一个Object，并造型成这个Class，这样JVM也识别这个Class（因为app classloader能够定位和载入这个Class从CLASSPA TH中），载入的也不是CLASSPA TH中的这个Class，而是从CLASSPA TH外动态载入的，这样总行了吧！十分不幸的是，这时会出现“https://www.360docs.net/doc/0d5408465.html,ng.ClassCastException”违例。

为什么呢？我们也来分析一下，不错，我们虽然从CLASSPA TH外使用我们自己的classloader动态载入了这个Class，但将它的实例造型的时候是JVM会使用app classloader来再次载入这个Class，并尝试将使用我们的自己的classloader载入的Class的一个实例造型为app classloader载入的这个Class（另外的一个）。大家发现什么问题了吗？也就是我们尝试将从一个classloader载入的Class的一个实例造型为另外一个classloader载入的Class，虽然这两个Class 的名字一样，甚至是从同一个class文件中载入。但不幸的是JVM 却认为这个两个Class是不同的，即JVM认为不同的classloader载入的相同的名字的Class （即使是从同一个class文件中载入的）是不同的！这样做的原因我想大概也是主要出于安全性考虑，这样就保证所有的核心Java类都是app classloader载入的，

我们无法用自己的classloader载入的相同名字的Class的实例来替换它们的实例。

看到这里，聪明的读者一定想到了该如何动态载入我们的Class，实例化，造型并调用了吧！

那就是利用面向对象的基本特性之一的多形性。我们把我们动态载入的Class 的实例造型成它的一个app classloader所能识别的父类就行了！这是为什么呢？我们还是要再来分析一次。当我们用我们自己的classloader来动态载入Class的时候，发现它有一个父类Class，在载入它之前JVM先会载入这个父类Class，这个父类Class是app classloader所能识别的，根据委托机制，它将由app classloader载入，然后我们的classloader再载入这个Class，创建一个实例，造型为这个父类Class，注意了，造型成这个父类Class的时候（也就是上溯）是面向对象的java语言所允许的并且JVM也支持的，JVM就使用app classloader 再次载入这个父类Class，然后将此实例造型为这个父类Class。大家可以从这个过程发现这个父类Class都是由app classloader载入的，也就是同一个class loader载入的同一个Class，所以造型的时候不会出现任何异常。而根据多形性，调用这个父类的方法时，真正执行的是这个Class（非父类Class）的覆盖了父类方法的方法。这些方法中也可以引用app classloader不能识别的Class，因为根据全盘负责原则，只要载入这个Class的classloader即我们自己定义的classloader能够定位和载入这些Class就行了。

这样我们就可以事先定义好一组接口或者基类并放入CLASSPA TH中，然后在执行的时候动态的载入实现或者继承了这些接口或基类的子类。还不明白吗？让我们来想一想Servlet吧，web application server能够载入任何继承了

Servlet的Class并正确的执行它们，不管它实际的Class是什么，就是都把它们实例化成为一个Servlet Class，然后执行Servlet的init，doPost，doGet和destroy 等方法的,而不管这个Servlet是从web- inf/lib和web-inf/classes下由app classloader的子classloader(即定制的classloader)动态载入。说了这么多希望大家都明白了。在applet,ejb等容器中,都是采用了这种机制。

7.为什么要扩展ClassLoader

似乎JVM自身的ClassLoader已经足够了，为什么我们还需要创建自己的ClassLoader呢？

因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class 文件。应用程序定义新的ClassLoader通常出于以下两种原因：

1. 自定义和扩展JVM加载类的方式。例如，增加对新的类库(网络、加密文件

等)的支持。

2. 划分JVM名称空间，避免名称冲突。例如，可以利用划分技术同时运行同

一应用程序的多个版本(基于空间的划分)。此项技术在应用服务器(如W ebLogic Server)内的另一个重要用途是启用应用程序热重新部署，即在不重新启动JVM的情况下启动应用程序的新版本(基于时间的划分)。

8.ClassLoader树和委托模型

当你决定创建你自己的ClassLoader时，需要继承https://www.360docs.net/doc/0d5408465.html,ng.ClassLoader或者它的子类。在实例化每个ClassLoader对象时，需要指定一个父对象；如果没有指定的话，系统自动指定ClassLoader.getSystemClassLoader ()为父对象。如下图：

在Java 1.2后，java class的加载采用所谓的委托模型（Delegation Modle），当调用一个ClassLoader.loadClass()加载一个类的时候，将遵循以下的步骤：1）检查这个类是否已经被加载进来了？

2）如果还没有加载，调用父对象加载该类

3）如果父对象无法加载，调用本对象的findClass()取得这个类。

所以当创建自己的Class Loader时，只需要重载findClass()这个方法。

9.Unloading? Reloading?

当一个java class被加载到JVM之后，它有没有可能被卸载呢？我们知道Win32有FreeLibrary()函数，Posix有dlclose()函数可以被调用来卸载指定的动态连接库，但是Java并没有提供一个UnloadClass()的方法来卸载指定的类。

在Java中，java class的卸载仅仅是一种对系统的优化，有助于减少应用对内存的占用。既然是一种优化方法，那么就完全是JVM自行决定如何实现，对Java开

发人员来说是完全透明的。

在什么时候一个java class/interface会被卸载呢？Sun公司的原话是这么说的：

"class or interface may be unloaded if and only if its class loader is unreachable. Classes loaded by the bootstrap loader may not be unloaded."

事实上我们关心的不是如何卸载类的，我们关心的是如何更新已经被加载了的类从而更新应用的功能。JSP则是一个非常典型的例子，如果一个JSP文件被更改了，应用服务器则需要把更改后的JSP重新编译，然后加载新生成的类来响应后继的请求。

其实一个已经加载的类是无法被更新的，如果你试图用同一个ClassLoader再次加载同一个类，就会得到异常（https://www.360docs.net/doc/0d5408465.html,ng.LinkageError: duplicate class definition），我们只能够重新创建一个新的ClassLoader实例来再次加载新类。至于原来已经加载的类，开发人员不必去管它，因为它可能还有实例正在被使用，只要相关的实例都被内存回收了，那么JVM就会在适当的时候把不会再使用的类卸载。

10.由名字空间引发的

类加载器名字空间（namespace）。我们注意到每一个类加载器（或者说类加载

器子类的实例）都定义了唯一、独立的名字空间。

对于一个名字为N的给定类，只有一个类N的实例可以在一个给定的类加载

器中存在。但是同一个类可以被两个不同的类加载器加载。在这种情况下，JVM会认为每一个类由加载它的类加载器实例而进一步限定。实际上，类的全称由其完全的类名加上它的类加载器组成。

重复加载类会带来一些微妙的、令人沮丧的错误。比如说，如果两个不同的类加载器加载com.acme.Dynamite，那么就会有两个实例，每一个都会拥有它自己的

独立的静态数据。任何将对象从一个类转到另外一个类的尝试都会导致一个ClassCastException异常。举例来说，一个既有Enterprise JavaBean（EJB）、又有web 模块的应用程序，并且在这个EJB模块的EJBObject接口（“Cart”）在W eb模块W AR文件中是重复的。当W eb模块中的servlet使用“Java Naming and Directory Interface”（JNDI）来查询EJB时，在它转向Cart接口时便得到一个ClassCastException 异常。

与其他的加载器不同，产生该异常的原因是W eb模块的加载器要首先在本地查找。这样，它得到本地打包的Cart接口，而由JNDI从EJB加载器返回的EJB就会具有Cart接口。各个类加载器之间的关系。类加载器以这样一种方式紧紧地被联系在一起：对于任何定位一个类的意图，都会有一个特定的类加载器序列被用来实现这一查询。每一个加载器都有一个相关联的父类加载器。利用这种关系，一个类加载器层次体系可以表现为一种树形结构，其复杂程度不等。从简单的链表到复杂的多分支树。这些树的一个重要特性就是，它们只能通过一种方式被查询：沿着其父辈向上查询。

这种层次结构的结果就是一种嵌套式的名字空间--在名字空间中类的可见性是由一个类加载器在该树中的位置安排所决定的：各节点沿着树“下行（down）”可以看见其每一个父节点的内容，但是父节点却不能看见其子节点的内容。答案就是框架显然必须找到一个具有合适的可见性的类加载器，并利用它来加载该实现。Java2提供一个简单但是很重要的机制来处理这种情况。每个Java线程可以存储一个独立的类加载器实例称为“相关类加载器（context classloader）”，它可以通过调用方法Thread.currentThread().getContextClassLoader()来得到。该实例可以通过该环境来设置以便提供任何需要的可见性。缺省状态下，该相关类加载器被设置成能获得调用

ClassLoader.getSystemClassLoader()的结果。

这种划分方案有时候会带来一些问题。比如说，一个框架，它动态地加载实现代码（使用Class.frName()方法），在这里，该实现预计是由第三方增加的。通常第三方代码处于树中的位置要比框架本身低。在这种情况下，框架怎样才能扩展它的范围并获得对这个代码的可视性呢？

答案就是框架显然必须找到一个具有合适的可见性的类加载器，并利用它来加载该实现。Java2提供一个简单但是很重要的机制来处理这种情况。每个Java线程可以存储一个独立的类加载器实例称为“相关类加载器（context classloader）”，它可以通过调用方法Thread.currentThread().getContextClassLoader()来得到。该实例可以通过该环境来设置以便提供任何需要的可见性。缺省状态下，该相关类加载器被设置成能获得调用ClassLoader.getSystemClassLoader()的结果。

11.类的查询

我们已经讨论了各个类加载器之间的关系，现在让我们看看JVM实际上如何实现查询。类加载器使用一种简单的授权模型来查询类。每一个类加载器实例都有一个相关的父类以及用于以前已加载的类的缓存。当被调用来加载一个类时，类加载器首先在其缓存中寻找，然后，如果没有找到，它就授权其父类去寻找。如果它的父类也未能找到该类，那么该加载器就力图自己去查找该类。在类加载器树中，这是一个递归的过程，其终点是树的最高层。

查询过程的第一步就是找到一个初始的类加载器。初始的类加载器就是在执行上面所描述的查询过程时所使用的第一个加载器。注意：初始加载器并不一定是真实的加载器。初始加载器的选择是非常重要的一个步骤，它或者是隐式的或者是显示的，如下所述。

隐式的选择也是最通常的情况，并且会在下述情况中使用：

●对象示例说明：当类A调用new操作符来产生一个B类的实例时，VM（虚拟机）就会选择A的类加载器作为初始类加载器。

●依赖性解析：如果类A依赖于类B，那么当VM需要加载类B的时候，它就会选择A的类加载器。这个过程是递归的，因此如果B依赖于C，VM就会选择B的类加载器来加载C。注意：对于每一个类来说，可能调用不同的类加载器。

●动态加载：Class.forName()方法超载；一个版本携带类加载器参数而另一个没有。当没有类加载器被传递过来时，JVM（Java虚拟机）就会搜寻调用堆栈以找寻第一个非空的类加载器对象。如果什么都没有找到，则使用ClassLoader.getSystemClassLoader()。

●对象的无序化：ObjectInputStream.resolveClass()方法调用堆栈的方式类似于Class.forNmae()的方法。

显示的选择尽管不大普遍被采用，但是当应用程序代码使用调用如下方法所得到的结果时，这种选择也会采用：

●一个类的实例上的getClassLoader()；

●ClassLoader.getSystemClassLoader()；

●Thread.currentThread().getContextClassLoader()；

●获得一个类加载器的一种应用程序特定的方法

12.一些重要的方法

A)方法loadClass

ClassLoader.loadClass() 是ClassLoader 的入口点。该方法的定义如下：

Class loadClass( String name, boolean resolve );

name JVM 需要的类的名称，如Foo 或https://www.360docs.net/doc/0d5408465.html,ng.Object。

resolve 参数告诉方法是否需要解析类。在准备执行类之前，应考虑类解析。并不总是需要解析。如果JVM 只需要知道该类是否存在或找出该类的超类，那么就不需要解析。

B)方法defineClass

defineClass 方法是ClassLoader 的主要诀窍。该方法接受由原始字节组成的数组并把它转换成Class 对象。原始数组包含如从文件系统或网络装入的数据。

defineClass 管理JVM 的许多复杂、神秘和倚赖于实现的方面-- 它把字节码分析成运行时数据结构、校验有效性等等。不必担心，您无需亲自编写它。事实上，即使您想要这么做也不能覆盖它，因为它已被标记成final的。

C)方法findSystemClass

findSystemClass 方法从本地文件系统装入文件。它在本地文件系统中寻找类文件，如果存在，就使用defineClass 将原始字节转换成Class 对象，以将该文件转换成类。当运行Java 应用程序时，这是JVM 正常装入类的缺省机制。（Java 2 中ClassLoader 的变动提供了关于Java 版本1.2 这个过程变动的详细信息。）对于定制的ClassLoader，只有在尝试其它方法装入类之后，再使用findSystemClass。

原因很简单：ClassLoader 是负责执行装入类的特殊步骤，不是负责所有类。例如，即使ClassLoader 从远程的Web 站点装入了某些类，仍然需要在本地机器上装入