理解Java ClassLoader机制

waterlooz — Sun, 20 Aug 2006 12:12:00 GMT

java.lang.NoClassDefFoundError: com/sun/tools/javac/Main
最�q�在使用java的动态编译的时候出现的问题,主要是由于在使用�c�com.sun.tool.javac.Main�?��L��出现NoClassDefFoundError的错�?后来扑ֈ�如下的文�?分析,可能是由于对于包tools.jar的加载问�?虽然我在classpath中声明了�q�个�?但在eclipse环境�?始终都还是出现运行时异常,对于�~�译时正��?�q�行时异常的情况,eclipse一般都是由于其自��n的加载机刉��成�?在eclipse�?对于一般的java工程,只要讄��了系�l�的classpath,在其中添加了tools.jar�?卛_��;对于plugin工程,我是��tools.jar�?直接拯��到本工程�?�q�在property中引�?而且在META-INF/MANIFEST.MF文�g中的Runtime��늚�classpath中添加了�q�个tool.jar�?�q�样在运行时��没有异�怺�,可以正常�~�译�?

当JVM�Q�Java虚拟机）启动�Ӟ��会�Ş成由三个�c�d��载器�l�成的初始类加蝲器层�ơ结构：

bootstrap classloader
|
extension classloader
|
system classloader

bootstrap classloader �Q�引��|��也称为原始）�c�d��载器�Q�它负责加蝲Java的核心类。在Sun的JVM中，在执行java的命令中使用-Xbootclasspath选项或��? D选项指定sun.boot.class.path�pȝ��属性值可以指定附加的�c�R��这个加载器的是非常�Ҏ��的，它实际上不是 java.lang.ClassLoader的子�c�，而是由JVM自��n实现的。大家可以通过执行以下代码来获得bootstrap classloader加蝲了那些核心类库：
URL[] urls=sun.misc.Launcher.getBootstrapClassPath().getURLs();
for (int i = 0; i < urls.length; i++) {
System.out.println(urls.toExternalform());
}
在我的计��机上的�l�果为：
文�g:/C:/j2sdk1.4.1_01/jre/lib/endorsed/dom.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/endorsed/sax.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xalan-2.3.1.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xercesImpl-2.0.0.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xml-apis.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/endorsed/xsltc.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/rt.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/i18n.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/sunrsasign.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/jsse.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/jce.jar
文�g:/C:/j2sdk1.4.1_01/jre/lib/charsets.jar
文�g:/C:/j2sdk1.4.1_01/jre/classes
�q�时大家知道了�ؓ什么我们不需要在�pȝ��属性CLASSPATH中指定这些类库了吧，因�ؓJVM在启动的时候就自动加蝲它们了�?br />
extension classloader �Q�扩展类加蝲器，它负责加载JRE的扩展目录（JAVA_HOME/jre/lib/ext或者由java.ext.dirs�pȝ��属性指定的�Q�中JAR的类包。这为引入除Java核心�c�M��外的新功能提供了一个标准机制。因为默认的扩展目录�Ҏ��有从同一个JRE中启动的JVM都是通用的，所以放入这个目录的 JAR�c�d��Ҏ��有的JVM和system classloader都是可见的。在�q�个实例上调用方法getParent()��L��q�回�I�值null�Q�因为引导加载器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());
�l�果为：
C:\j2sdk1.4.1_01\jre\lib\ext
the parent of extension classloader : null
extension classloader是system classloader的parent�Q�而bootstrap classloader是extension classloader的parent�Q�但它不是一个实际的classloader�Q�所以�ؓnull�?br />
system classloader �Q�系�l�（也称为应用）�c�d��载器�Q�它负责在JVM被启动时�Q�加载来自在命��ojava中的-classpath或者java.class.path�pȝ��属性或�?CLASSPATH操作�pȝ��属性所指定的JAR�c�d��和类路径。总能通过静态方法ClassLoader.getSystemClassLoader()扑ֈ�该类加蝲器。如果没有特别指定，则用戯��定义的�Q何类加蝲器都��该�c�d��载器作�ؓ它的父加载器。执行以下代码即可获得：
System.out.println(System.getProperty("java.class.path"));
输出�l�果则�ؓ用户在系�l�属性里面设�|�的CLASSPATH�?br />classloader 加蝲�cȝ��的是全盘负责委托机制。所谓全盘负责，��x��当一个classloader加蝲一个Class的时候，�q�个Class所依赖的和引用的所�?Class也由�q�个classloader负责载入�Q�除非是昑ּ�的��用另外一个classloader载入�Q�委托机制则是先让parent�Q�父�Q�类加蝲�?(而不是super�Q�它与parent classloader�c�M��是��承关�p?��L��Q�只有在parent找不到的时候才从自��q��c��\径中��d��找。此外类加蝲�q�采用了cache机制�Q�也��是如果 cache中保存了�q�个Class��q��接返回它�Q�如果没有才从文件中��d��和�{换成Class�Q��ƈ存入cache�Q�这��是��Z��么我们修改了Class但是必须重新启动JVM才能生效的原因�?br />

每个ClassLoader加蝲Class的过�E�是�Q?br />1.��此Class是否载入�q�（卛_��cache中是否有此Class�Q�，如果有到8,如果没有�?
2.如果parent classloader不存在（没有parent�Q�那parent一定是bootstrap classloader了）�Q�到4
3.��h��parent classloader载入�Q�如果成功到8�Q�不成功�?
4.��h��jvm从bootstrap classloader中蝲入，如果成功�?
5.��L��Class文�g�Q�从与此classloader相关的类路径中寻找）。如果找不到则到7.
6.从文件中载入Class�Q�到8.
7.抛出ClassNotFoundException.
8.�q�回Class.

其中5.6步我们可以通过覆盖ClassLoader的findClass�Ҏ��来实现自��q��载入�{�略。甚臌��盖loadClass�Ҏ��来实现自��q��载入�q�程�?br />
�c�d��载器的顺序是�Q?br />先是bootstrap classloader�Q�然后是extension classloader�Q�最后才是system classloader。大家会发现加蝲的Class��是重要的越在靠前面。这样做的原因是��Z��安全性的考虑�Q�试惛_��果system classloader“亲自”加载了一个具有破坏性的“java.lang.System”类的后果吧。这�U�委托机制保证了用户即��h��一个这��L��c�，也把它加入到了类路径中，但是它永�q�不会被载入�Q�因��个类��L��由bootstrap classloader来加载的。大家可以执行一下以下的代码�Q?br /> System.out.println(System.class.getClassLoader());
��会看到�l�果是null�Q�这��p��明java.lang.System是由bootstrap classloader加蝲的，因�ؓbootstrap classloader不是一个真正的ClassLoader实例�Q�而是由JVM实现的，正如前面已经说过的�?br />
下面��p��我们来看看JVM是如何来为我们来建立�c�d��载器的结构的�Q?br />sun.misc.Launcher�Q�顾名思义�Q�当你执行java命��o的时候，JVM会先使用bootstrap classloader载入�q�初始化一个Launcher�Q�执行下来代码：
System.out.println("the Launcher's classloader is "+sun.misc.Launcher.getLauncher().getClass().getClassLoader());
�l�果为：
the Launcher's classloader is null (因�ؓ是用bootstrap classloader加蝲,所以class loader为null)
Launcher 会根据系�l�和命��o讑֮�初始化好class loader�l�构�Q�JVM��q��它来获得extension classloader和system classloader,�q�蝲入所有的需要蝲入的Class�Q�最后执行java命��o指定的带有静态的main�Ҏ��的Class。extension classloader实际上是sun.misc.Launcher$ExtClassLoader�cȝ��一个实例，system classloader实际上是sun.misc.Launcher$AppClassLoader�cȝ��一个实例。�ƈ且都�?java.net.URLClassLoader的子�c�R�?br />
让我们来看看Launcher初试化的�q�程的部分代码�?br />
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�Q�parent是extension classloader
loader = AppClassLoader.getAppClassLoader(extclassloader);
} catch(IOException ioexception1) {
throw new InternalError("Could not create application class loader");
}
//��system classloader讄��成当前线�E�的context classloader�Q�将在后面加以介�l�）
Thread.currentThread().setContextClassLoader(loader);
......
}
public ClassLoader getClassLoader() {
//�q�回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() {
//获得�pȝ��属性“java.ext.dirs�?br /> 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;
}
}

system classloader的部分代码：
static class Launcher$AppClassLoader extends URLClassLoader
{

public static ClassLoader getAppClassLoader(ClassLoader classloader)
throws IOException
{
//获得�pȝ��属性“java.class.path�?br /> 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));
}
}

看了源代码大家就清楚了吧�Q�extension classloader是��用系�l�属性“java.ext.dirs”设�|�类搜烦路径的，�q�且没有parent。system classloader是��用系�l�属性“java.class.path”设�|�类搜烦路径的，�q�且有一个parent classloader。Launcher初始化extension classloader�Q�system classloader�Q��ƈ��system classloader讄��成�ؓcontext classloader�Q�但是仅仅返回system classloader�l�JVM�?br />
　　�q�里怎么又出来一个context classloader呢？它有什么用呢？我们在徏立一个线�E�Thread的时候，可以��个线�E�通过setContextClassLoader�Ҏ��来指定一个合适的classloader作�ؓ�q�个�U�程的context classloader�Q�当此线�E�运行的时候，我们可以通过getContextClassLoader�Ҏ��来获得此context classloader�Q�就可以用它来蝲入我们所需要的Class。默认的是system classloader。利用这个特性，我们可以“打破”classloader委托机制了，父classloader可以获得当前�U�程的context classloader�Q�而这个context classloader可以是它的子classloader或者其他的classloader�Q�那么父classloader��可以从其获得所需�?Class�Q�这��打破了只能向父classloader��h��的限制了。这个机制可以满��_��我们的classpath是在�q�行时才��定,�q�由定制�?classloader加蝲的时�?由system classloader(卛_��jvm classpath�?加蝲的class可以通过context classloader获得定制的classloader�q�加载入特定的class(通常是抽象类和接�?定制的classloader中是其实�?,例如web应用中的servlet��是用这�U�机制加载的.

好了�Q�现在我们了解了classloader的结构和工作原理�Q�那么我们如何实现在�q�行时的动态蝲入和更新呢？只要我们能够动态改变类搜烦路径和清除classloader的cache中已�l�蝲入的Class��p��了，有两个方案，一是我们��承一个classloader�Q�覆盖loadclass�Ҏ��Q�动态的��L��Class文�g�q��用defineClass�Ҏ��来；另一个则非常��单实用，只要重新使用一个新的类搜烦路径来new一个classloader��p��了，�q�样��x��C��c�L��索�\径以便来载入新的Class�Q�也重新生成了一个空白的cache(当然,�c�L��索�\径不一定必��L��?。噢�Q�太好了�Q�我们几乎不用做什么工作，java.netURLClassLoader正是一个符合我们要求的classloader�Q�我们可以直接��用或者��承它��可以了�Q?br />
�q�是j2se1.4 API的doc中URLClassLoader的两个构造器的描�q�ͼ�
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��是我们要设�|�的�c�L��索�\径，parent��是�q�个classloader的parent classloader�Q�默认的是system classloader�?br />

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

首先让我们来分析一下java源文件的�~�译�Q�运行吧�Q�javac命��o是调用“JAVA_HOME/lib/tools.jar”中的“com.sun.tools.javac.Main”的compile�Ҏ��来编译：

public static int compile(String as[]);

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

�q�回0表示�~�译成功�Q�字�W�串数组as则是我们用javac命��o�~�译时的参数�Q�以�I�格划分。例如：
javac -classpath c:\foo\bar.jar;. -d c:\ c:\Some.java
则字�W�串数组as为{"-classpath","c:\\foo\\bar.jar;.","-d","c:\\","c:\\Some.java"}�Q�如果带有PrintWriter参数�Q�则会把�~�译信息出到�q�个指定的printWriter中。默认的输出是System.err�?br />
其中 Main是由JVM使用Launcher初始化的system classloader载入的，�Ҏ��全盘负责原则�Q�编译器在解析这个java源文件时所发现的它所依赖和引用的所有Class也将由system classloader载入�Q�如果system classloader不能载入某个Class�Ӟ��~�译器将抛出一个“cannot resolve symbol”错误�?br />
所以首先编译就通不�q�，也就是编译器无法�~�译一个引用了不在CLASSPATH中的未知Class的java源文�Ӟ��而由于拼写错误或者没有把所需�c�d��攑ֈ�CLASSPATH中，大家一定经常看到这个“cannot resolve symbol”这个编译错误吧�Q?br />
其次�Q�就是我们把�q�个Class攑ֈ��~�译路径中，成功的进行了�~�译�Q�然后在�q�行的时候不把它攑օ�到CLASSPATH中而利用我们自��q�� classloader来动态蝲入这个Class�Q�这时候也会出现“java.lang.NoClassDefFoundError”的�q�例�Q��ؓ什么呢�Q?br />
我们再来分析一下，首先调用�q�个造型语句的可执行的Class一定是由JVM使用Launcher初始化的system classloader载入的，�Ҏ��全盘负责原则�Q�当我们�q�行造型的时候，JVM也会使用system classloader来尝试蝲入这个Class来对实例�q�行造型�Q�自然在system classloader��L��不到�q�个Class时就会抛出“java.lang.NoClassDefFoundError”的�q�例�?br />
OK�Q�现在让我们来�ȝ��一下，java文�g的编译和Class的蝲入执行，都是使用Launcher初始化的system classloader作�ؓ�c�蝲入器的，我们无法动态的改变system classloader�Q�更无法让JVM使用我们自己的classloader来替换system classloader�Q�根据全盘负责原则，��限制了�~�译和运行时�Q�我们无法直接显式的使用一个system classloader��L��不到的Class�Q�即我们只能使用Java核心�c�d��Q�扩展类库和CLASSPATH中的�c�d��中的Class�?br />
�q�不��d��Q�再��试一下这�U�情况，我们把这个Class也放入到CLASSPATH中，让system classloader能够识别和蝲入。然后我们通过自己的classloader来从指定的class文�g中蝲入这个Class�Q�不能够委托 parent载入�Q�因��样会被system classloader从CLASSPATH中将其蝲入）�Q�然后实例化一个Object�Q��ƈ造型成这个Class�Q�这样JVM也识别这个Class�Q�因�?system classloader能够定位和蝲入这个Class从CLASSPATH中）�Q�蝲入的也不是CLASSPATH中的�q�个Class�Q�而是�?CLASSPATH外动态蝲入的�Q�这��h��行了吧�Q�十分不�q�的是，�q�时会出现“java.lang.ClassCastException”违例�?br />
��Z��么呢�Q�我们也来分析一下，不错�Q�我们虽然从CLASSPATH外��用我们自��q��classloader动态蝲入了�q�个Class�Q�但��它的实例造型的时候是JVM会��用system classloader来再�ơ蝲入这个Class�Q��ƈ��试��用我们的自己的classloader载入的Class的一个实例造型为system classloader载入的这个Class�Q�另外的一个）。大家发��C��么问题了吗？也就是我们尝试将从一个classloader载入的Class的一个实例造型为另外一个classloader载入的Class�Q�虽然这两个Class的名字一��P��甚至是从同一个class文�g中蝲入。但不幸的是JVM 却认��个两个Class是不同的�Q�即JVM认�ؓ不同的classloader载入的相同的名字的Class�Q�即使是从同一个class文�g中蝲入的�Q�是不同的！�q�样做的原因我想大概也是主要��Z��安全性考虑�Q�这样就保证所有的核心Java�c�都是system classloader载入的，我们无法用自��q��classloader载入的相同名字的Class的实例来替换它们的实例�?br />
看到�q�里�Q�聪明的读者一定想��C��该如何动态蝲入我们的Class�Q�实例化�Q�造型�q�调用了吧！

那就是利用面向对象的基本�Ҏ��之一的多形性。我们把我们动态蝲入的Class的实例造型成它的一个system classloader所能识别的父类��p��了！�q�是��Z��么呢�Q�我们还是要再来分析一�ơ。当我们用我们自��q��classloader来动态蝲入这我们只要把这个Class的时候，发现它有一个父�c�Class�Q�在载入它之前JVM先会载入�q�个父类Class�Q�这个父�c�Class是system classloader所能识别的�Q�根据委托机�Ӟ��它将由system classloader载入�Q�然后我们的classloader再蝲入这个Class�Q�创��Z��个实例，造型��个父�c�Class�Q�注意了�Q�造型成这个父�c?Class的时候（也就是上溯）是面向对象的java语言所允许的�ƈ且JVM也支持的�Q�JVM��׃��用system classloader再次载入�q�个父类Class�Q�然后将此实例造型��个父�c�Class。大家可以从�q�个�q�程发现�q�个父类Class都是�?system classloader载入的，也就是同一个class loader载入的同一个Class�Q�所以造型的时候不会出��C�Q何异常。而根据多形性，调用�q�个父类的方法时�Q�真正执行的是这个Class�Q�非父类 Class�Q�的覆盖了父�c�L��法的�Ҏ��。这些方法中也可以引用system classloader不能识别的Class�Q�因为根据全盘负责原则，只要载入�q�个Class的classloader��x��们自己定义的 classloader能够定位和蝲入这些Class��p��了�?br />
�q�样我们��可以事先定义好一�l�接口或者基�c�dƈ攑օ�CLASSPATH中，然后在执行的时候动态的载入实现或者��承了�q�些接口或基�cȝ��子类。还不明白吗�Q�让我们来想一想Servlet吧，web application server能够载入��M��l�承了Servlet的Class�q�正��的执行它们�Q�不��它实际的Class是什么，��是都把它们实例化成��Z��个Servlet Class�Q�然后执行Servlet的init�Q�doPost�Q�doGet和destroy�{�方法的,而不��这个Servlet是从web- inf/lib和web-inf/classes下由system classloader的子classloader(卛_��制的classloader)动态蝲入。说了这么多希望大家都明白了。在applet,ejb�{�容器中,都是采用了这�U�机�?

对于以上各种情况�Q�希望大家实际编写一些example来实验一下�?br />
最后我再说点别的， classloader虽然�U�Cؓ�c�d��载器�Q�但�q�不意味着只能用来加蝲Class�Q�我们还可以利用它也获得囄��Q�音频文件等资源的URL�Q�当�Ӟ��q�些资源必须在CLASSPATH中的jar�c�d��中或目录下。我们来看API的doc中关于ClassLoader的两个寻找资源和Class的方法描�q�吧�Q?br />　　　　　　　　public URL getResource(String name)
　　　　　　　　用指定的名字来查找资源，一个资源是一些能够被class代码讉K��的在某种�E�度上依赖于代码位置的数据（囄��Q�音频，文本�{�等�Q��?br /> 一个资源的名字是以'/'号分隔确定资源的路径名的�?br /> �q�个�Ҏ��先��h��parent classloader搜烦资源�Q�如果没有parent�Q�则会在内置在虚拟机中的classloader�Q�即bootstrap classloader�Q�的路径中搜索。如果失败，�q�个�Ҏ��调用findResource(String)来寻找资源�?br />　　　　　　　　public static URL getSystemResource(String name)
从用来蝲入类的搜索�\径中查找一个指定名字的资源。这个方法��用system class loader来定位资源。即相当于ClassLoader.getSystemClassLoader().getResource(name)�?br />
例如�Q?br /> System.out.println(ClassLoader.getSystemResource("java/lang/String.class"));
的结果�ؓ�Q?br /> jar:文�g:/C:/j2sdk1.4.1_01/jre/lib/rt.jar!/java/lang/String.class
表明String.class文�g在rt.jar的java/lang目录中�?br />因此我们可以��图片等资源随同Class一同打包到jar�c�d��中（当然�Q�也可单独打包这些资源）�q�添加它们到class loader的搜索�\径中�Q�我们就可以无需兛_��q�些资源的具体位�|�，让class loader来帮我们��L��了！

waterlooz 2006-08-20 20:12 发表评论

51ⅴ精品国产91久久久久久,免费观看成年在线视频网站,亚洲美女久久久

理解Java ClassLoader机制