JAVA技巧：Java类别载入器分析（3）

会计考友 · 发表于 2012-8-4 12:28:23

三个载入器的层次关系可通过运行下面的例子察看：
public class Test
{
public static void main(String[] args)
{
ClassLoader cl1 = Test.class.getClassLoader();
System.out.println(cl1);
ClassLoader cl2 = cl1.getParent();
System.out.println(cl2);
ClassLoader cl3 = cl2.getParent();
System.out.println(cl3);
}
}
运行结果：
////////////////////////////////////////////////////////////
sun.misc.Launcher$AppClassLoader@1a0c10f
sun.misc.Launcher$ExtClassLoader@e2eec8
null
//////////////////////////////////////////////////////////
如果在上述程式中，如果您使用程式码:
cl1.getClass.getClassLoader()及cl2.getClass.getClassLoader()，您会发现印出的都是null，
这代表它们都是由Bootstrap Loader 所载入。这里也再次强调，类别载入器由谁载入(这句话有点
诡异，类别载入器也要由类别载入器载入，这是因为除了Bootstrap Loader 之外，其余的类别载
入器皆是由Java 撰写而成)，和它的Parent 是谁没有关系，Parent 的存在只是为了某些特殊目的，
这个目的我们将在稍後作解释。
在此要请大家注意的是，AppClassLoader 和ExtClassLoader 都是URLClassLoader 的子类别。
由於它们都是URLClassLoader 的子类别，所以它们也应该有URL 作为搜寻类别档的参考，由原始码
中我们可以得知，AppClassLoader 所参考的URL 是从系统参数java.class.path 取出的字串所决定，
而java.class.path 则是由我们在执行java.exe 时，利用–cp 或-classpath 或CLASSPATH 环境变
数所决定。
用如下示例测试：
public class AppLoader
{
public static void main(String[] args)
{
String s = System.getProperty("java.class.path");
System.out.println(s);
}
}
/////////////////////////////////////////////////////////////////
D:\myapp\classload>java AppLoader
.;D:\myjava\Tomcat5.0\webapps\axis\WEB-INF\lib\axis.jar;D:\myjava\Tomcat5.0\weba
pps\axis\WEB-INF\lib\commons-logging.jar;D:\myjava\Tomcat5.0\webapps\axis\WEB-IN
F\lib\commons-discovery.jar;C:\oracle\ora81\jdbc\lib\classes12.zip;D:\myjava\JDB
CforSQLserver\lib\mssqlserver.jar;D:\myjava\JDBCforSQLserver\lib\msbase.jar;D:\m
yjava\JDBCforSQLserver\lib\msutil.jar;D:\myjava\Tomcat5.0\common\lib\servlet-api
.jar;D:\myjava\j2sdk1.4.2_04\jre\lib\rt.jar;C:\sun\appserver\lib\j2ee.jar;D:\myj
ava\j2sdk1.4.2_04\lib\jaxp.jar;D:\myjava\j2sdk1.4.2_04\lib\sax.jar;
D:\myapp\classload>java -classpath .;d:\myapp AppLoader
.;d:\myapp
/////////////////////////////////////////////////////////////////
从这个输出结果，我们可以看出，在预设情况下，AppClassLoader 的搜寻路径为”.”(目前所在目
录)，如果使用-classpath 选项(与-cp 等效)，就可以改变AppClassLoader 的搜寻路径，如果没有
指定-classpath 选项，就会搜寻环境变数CLASSPATH。如果同时有CLASSPATH 的环境设定与
-classpath 选项，则以-classpath 选项的内容为主，CLASSPATH 的环境设定与-classpath 选项两者
的内容不会有加成的效果。
至於ExtClassLoader 也有相同的情形，不过其搜寻路径是参考系统参数java.ext.dirs。
系统参数java.ext.dirs 的内容，会指向java.exe 所选择的JRE 所在位置下的\lib\ext 子目录。Java.exe使用的JRE是在系统变量path里指定的，可以通过修改path从而修改ExtCLassLoader的搜寻路径，也可以如下命令参数来更改，
java –Djava.ext.dirs=c:\winnt\ AppLoader //注意 =号两边不能有空格。-D也不能和java分开。
////////////////////////////////////////////////////////////////
D:\myapp\classload>java ExtLoader
D:\myjava\j2sdk1.4.2_04\jre\lib\ext
D:\myapp\classload>java -Djava.ext.dirs=c:\winnt\ ExtLoader
c:\winnt\
////////////////////////////////////////////////////////////////

会计考友 · 发表于 2012-8-4 12:28:24

最後一个类别载入器是Bootstrap Loader ，我们可以经由查询由系统参数sun.boot.class.path 得知Bootstrap Loader 用来搜寻类别的路径。该路径的修改与ExtClassLoader的相同。但修改后不影响Bootstrap的搜寻路径。
在命令列下参数时，使用–classpath / -cp / 环境变数CLASSPATH 来更改AppClassLoader
的搜寻路径，或者用–Djava.ext.dirs 来改变ExtClassLoader 的搜寻目录，两者都是有意义的。
可是用–Dsun.boot.class.path 来改变Bootstrap Loader 的搜寻路径是无效。这是因为
AppClassLoader 与ExtClassLoader 都是各自参考这两个系统参数的内容而建立，当您在命令列下
变更这两个系统参数之後， AppClassLoader 与ExtClassLoader 在建立实体的时候会参考这两个系
统参数，因而改变了它们搜寻类别档的路径;而系统参数sun.boot.class.path 则是预设与
Bootstrap Loader 的搜寻路径相同，就算您更改该系统参与，与Bootstrap Loader 完全无关。
改变java.exe所使用的jre会改变Bootstrap Loader的搜寻路径。
Bootstrap Loader的搜寻路径一般如下：
///////////////////////////////////////////////////////////////////////////////////
D:\myjava\j2sdk1.4.2_04\jre\lib\rt.jar;D:\myjava\j2sdk1.4.2_04\jre\lib\i18n.jar;
D:\myjava\j2sdk1.4.2_04\jre\lib\sunrsasign.jar;D:\myjava\j2sdk1.4.2_04\jre\lib\j
sse.jar;D:\myjava\j2sdk1.4.2_04\jre\lib\jce.jar;D:\myjava\j2sdk1.4.2_04\jre\lib\
charsets.jar;D:\myjava\j2sdk1.4.2_04\jre\classes
///////////////////////////////////////////////////////////////////////////////////////
更重要的是，AppClassLoader 与ExtClassLoader 在整个虚拟机器之中只会存有一份，一旦建
立了，其内部所参考的搜寻路径将不再改变，也就是说，即使我们在程式里利用System.setProperty()
来改变系统参数的内容，仍然无法更动AppClassLoader 与ExtClassLoader 的搜寻路径。因此，执
行时期动态更改搜寻路径的设定是不可能的事情。如果因为特殊需求，有些类别的所在路径并非在
一开始时就能决定，那麽除了产生新的类别载入器来辅助我们载入所需的类别之外，没有其他方法了。
下面我们将看一下载入器的委派模型
所谓的委派模型，用简单的话来讲，就是「类别载入器有载入类别的需求时，会先请示其Parent 使用其搜寻路径帮忙载入，如果Parent 找不到，那麽才由自己依照自己的搜寻路径搜寻类别」。
下面我们看一下小的示例：
public class Test
{
public static void main(String[] args)
{
System.out.println(Test.class.getClassLoader());
TestLib tl = new TestLib();
tl.start();
}
}
public class TestLib
{
public void start()
{
System.out.println(this.getClass().getClassLoader());
}
}
如果这两个类仅放在dos命令提示符的当前目录下，则输出结果如下：
//////////////////////////////////////////////////////
sun.misc.Launcher$AppClassLoader@1a0c10f
sun.misc.Launcher$AppClassLoader@1a0c10f
//////////////////////////////////////////////////////
如果这两个类同时又放在\lib\ext\classes 底下（在我的机器上是：D:\myjava\j2sdk1.4.2_04\jre\lib\ext\classes，classes没有，需要自己建），输出结果如下：
/////////////////////////////////
sun.misc.Launcher$ExtClassLoader@e2eec8
sun.misc.Launcher$ExtClassLoader@e2eec8
////////////////////////////////////
最后如果在\classes下放入这两个类，则输出结果为
/////////////////////////////////
null
null
////////////////////////////////////
如果把\classes下的TestLib删去，则输出入下：
//////////////////////////////////////
null
Exception in thread "main" java.lang.NoClassDefFoundError: TestLib
at Test.main(Test.java:7)
//////////////////////////////////////
这是因为Test的classLoader是Bootstrap Loader ,因此TestLib的也默认为是Bootstrap Loader。Bootstrap Loader搜寻路径下的TestLib被删去了，Bootstrap Loader又没有parent，所以提示找不到。
其他的情况可以自己逐个添加或删除文件，然后执行java Test进行测试，察看输出结果。
AppClassLoader 与Bootstrap Loader会搜寻它们所指定的位置(或JAR 档)，如果找不到就找不到了，AppClassLoader 与Bootstrap Loader不会递回式地搜寻这些位置下的其他路径或其他没有被指定的JAR 档。反观ExtClassLoader，所参考的系统参数是java.ext.dirs，意思是说，他会搜寻底下的所有JAR 档以及classes 目录，作为其搜寻路径。

		自动登录	找回密码
密码			立即注册

[其他] JAVA技巧：Java类别载入器分析（3）

JAVA技巧：Java类别载入器分析（3）