您的位置: 首页 > 软件教程 > Java教程专题 > Java类别载入器

Java类别载入器

8.1分
出处:网络 时间:2011-04-25

您可能感兴趣的话题: Java  

核心提示:Java的动态特性有两种,一是隐式的;另一种是显示的。

  1 Java的动态特性

Java的动态特性有两种,一是隐式的;另一种是显示的。隐式的(implicit)方法就是当程式设计师用到new 这个Java 关键字时,会让类别载入器依需求载入您所需要的类别,这种方式使用了隐式的(implicit)方法。显式的方法,又分成两种方式,一种是藉由java.lang.Class 里的forName()方法,另一种则

是藉由java.lang.ClassLoader 里的loadClass()方法。您可以任意选用其中一种方法。

  2 隐式的动态特性

在执行java文件时,只有单独的变量声明是不会载入相应的类的,只有在用new生成实例时才载入

如示例所示:

public class Main

public static void main(String args[])

{

A a1 = new A() ;

B b1 ;

}

类A和B相同,如下:

public class A

{

public void print(“using A”);

}

编译后,可用java –verbose:class Main运行,察看输出结果。可以看到JVM只载入了A,而没有载入B.

另外,类的载入只在执行到new一个类时,才载入,如果没有执行到new语句,则不载入。

如://类Office

public class Office

{

public static void main(String[] args)

{

Word myword=null;

Excel myexcel=null;

if (args[0].equals("Word"))

{

myword = new Word();

myword.start();

}

if (args[0].equals("Excel"))

{

myexcel = new Excel();

myexcel.start();

}

}

}

//类Word和Excel基本相同,如下

public class Word

{

public void start()

{

System.out.println("using word");

}

}

在dos命令提示符下,输入java –verbose Office Excel可以看到JVM只载入Excel类,而不载入Word类。

3 显示的动态特性

3.1 java.lang.Class里的forName()方法

在上一个Office示例中,进行如下修改:

一 加入Assembly类

public interface Assembly

{

public void start();

}

二 让Word和Excel类实现该接口

public class Word implements Assembly

{

public void start()

{

System.out.println("using word");

}

}

三 Office 类如下所示

public class Office

{

public static void main(String[] args) throws Exception

{

java.lang.Class c = java.lang.Class.forName(args[0]);

Object o = c.newInstance();

Assembly a = (Assembly)o;

a.start();

}

}

  在命令提示符下输入java –verbose Office Word 输出入下:

通过上图你可以看到,interface 如同class 一般,会由编译器产生一个独立的类别档(.class),当类别载入器载入类别时,如果发现该类别继承了其他类别,或是实作了其他介面,就会先载入代表该介面的类别档,也会载入其父类别的类别档,如果父类别也有其父类别,也会一并优先载入。换句话说,类别载入器会依继承体系最上层的类别往下依序载入,直到所有的祖先类别都载入了,才轮到自己载入。

下面介绍一下 forName 函数, 如果您亲自搜寻Java 2 SDK 说明档内部对於Class 这个类别的说明,您可以发现其实有两个forName()方法,一个是只有一个参数的(就是之前程式之中所使用的):

public static Class forName(String className)

另外一个是需要三个参数的:

public static Class forName(String name, boolean initialize,ClassLoader loader)

这两个方法,最後都是连接到原生方法forName0(),其宣告如下:

private static native Class forName0(String name, boolean initialize, ClassLoader loader)

throws ClassNotFoundException;

只有一个参数的forName()方法,最後叫用的是:

forName0(className, true, ClassLoader.getCallerClassLoader());

而具有三个参数的forName()方法,最後叫用的是:

forName0(name, initialize, loader);

这里initialize参数指,在载入类之后是否进行初始化,对于该参数的作用可用如下示例察看:

类里的静态初始化块在类第一次被初始化时才被呼叫,且仅呼叫一次。在Word类里,加入静态初始化块

public class Word implements Assembly

{

static

{

System.out.println("word static initialization ");

}

public void start()

{

System.out.println("using word");

}

}

将类Office作如下改变:

public class Office

{

public static void main(String[] args) throws Exception

{

Office off= new Office();

System.out.println("类别准备载入");

java.lang.Class c = java.lang.Class.forName(args[0],true,off.getClass().getClassLoader());

System.out.println("类别准备实体化");

Object o = c.newInstance();

Object o2 = c.newInstance();

}

}

  如果第二个参数为true 则输出入下

如果为false ,则输出入下:

可见,类里的静态初始化块仅在初始化时才执行,且不过初始化几次,它仅执行一次(这里有一个条件,那就是只有它是被同一个类别载入器多次载入时,才是这样,如果被不同的载入器,载入多次,则静态初始化块会执行多次)。

关于第三个参数请见下节介绍

3.2 直接使用类别载入器 java.lang.ClassLoader

在Java 之中,每个类别最後的老祖宗都是Object,而Object 里有一个名为getClass()的方法,就是用来取得某特定实体所属类别的参考,这个参考,指向的是一个名为Class 类别(Class.class) 的实体,您无法自行产生一个Class 类别的实体,因为它的建构式被宣告成private,这个Class 类别的实体是在类别档(.class)第一次载入记忆体时就建立的,往後您在程式中产生任何该类别的实体,这些实体的内部都会有一个栏位记录着这个Class 类别的所在位置。

基本上,我们可以把每个Class 类别的实体,当作是某个类别在记忆体中的代理人。每次我们需要

查询该类别的资料(如其中的field、method 等)时,就可以请这个实体帮我们代劳。事实上,Java的Reflection 机制,就大量地利用Class 类别。去深入Class 类别的原始码,我们可以发现Class类别的定义中大多数的方法都是原生方法(native method)。

在Java 之中,每个类别都是由某个类别载入器(ClassLoader 的实体)来载入,因此,Class 类别的实体中,都会有栏位记录着载入它的ClassLoader 的实体(注意:如果该栏位是null,并不代表它不是由类别载入器所载入,而是代表这个类别由靴带式载入器(bootstrap loader,也有人称rootloader)所载入,只不过因为这个载入器并不是用Java 所写成,是用C++写的,所以逻辑上没有实体)。

系统里同时存在多个ClassLoader 的实体,而且一个类别载入器不限於只能载入一个类别,类别载入器可以载入多个类别。所以,只要取得Class 类别实体的参考,就可以利用其getClassLoader()方法篮取得载入该类别之类别载入器的参考。getClassLoader()方法最後会呼叫原生方法getClassLoader0(),其宣告如下:private native ClassLoader getClassLoader0();

最後,取得了ClassLoader 的实体,我们就可以叫用其loadClass()方法帮我们载入我们想要的类别,因此上面的Office类可做如下修改:

public class Office

{

public static void main(String[] args) throws Exception

{

Office off= new Office();

System.out.println("类别准备载入");

ClassLoader loader = off.getClass().getClassLoader();

java.lang.Class c = loader.loadClass(args[0]);

System.out.println("类别准备实体化");

Object o = c.newInstance();

Object o2 = c.newInstance();

}

}

  其输出结果同forName方法的第二个参数为false时相同。可见载入器载入类时只进行载入,不进行初始化。

获取ClassLoader还可以用如下的方法:

public class Office

{

public static void main(String[] args) throws Exception

{

java.lang.Class cb = Office.class;

System.out.println("类别准备载入");

ClassLoader loader = cb.getClassLoader();

java.lang.Class c = loader.loadClass(args[0]);

System.out.println("类别准备实体化");

Object o = c.newInstance();

Object o2 = c.newInstance();

}

}

在此之前,当我们谈到使用类别载入器来载入类别时,都是使用既有的类别载入器来帮我们载

入我们所指定的类别。那麽,我们可以自己产生类别载入器来帮我们载入类别吗? 答案是肯定的。

利用Java 本身提供的java.net.URLClassLoader 类别就可以做到。

public class Office

{

public static void main(String[] args) throws Exception

{

URL u = new URL("file:/d:/myapp/classload/");

URLClassLoader ucl = new URLClassLoader(new URL[]{u});

java.lang.Class c = ucl.loadClass(args[0]);

Assembly asm = (Assembly)c.newInstance();

asm.start();

}

}

在这个范例中,我们自己产生java.net.URLClassLoader 的实体来帮我们载入我们所需要的类别。但是载入前,我们必须告诉URLClassLoader 去哪个地方寻找我们所指定的类别才行,所以我们必须给它一个URL 类别所构成的阵列,代表我们希望它去搜寻的所有位置。URL 可以指向网际网路上的任何位置,也可以指向我们电脑里的档案系统(包含JAR 档)。在上述范例中,我们希望URLClassLoader 到d:mylib 这个目录下去寻找我们需要的类别, 所以指定的URL为”file:/d:/my/lib/”。其实,如果我们请求的位置是主要类别(有public static void main(String args[])方法的那个类别)的相对目录,我们可以在URL 的地方只写”file:lib/”,代表相对於目前的目录。

  下面我们来看一下系统为我们提供的3个类别载入器:

java.exe 是利用几个基本原则来寻找Java Runtime Environment(JRE),然後把类别档(.class)直接转交给JRE 执行之後,java.exe 就功成身退。类别载入器也是构成JRE 的其中一个重要成员,所以最後类别载入器就会自动从所在之JRE 目录底下的lib t.jar 载入基础类别函式库。

当我们在命令列输入java xxx.class 的时候,java.exe 根据我们之前所提过的逻辑找到了JRE(Java Runtime Environment),接着找到位在JRE 之中的jvm.dll(真正的Java 虚拟机器),最後载入这个动态联结函式库,启动Java 虚拟机器。虚拟机器一启动,会先做一些初始化的动作,比方说抓取系统参数等。一旦初始化动作完成之後,就会产生第一个类别载入器,即所谓的Bootstrap Loader,Bootstrap Loader 是由C++所撰写而成(所以前面我们说,以Java 的观点来看,逻辑上并不存在Bootstrap Loader 的类别实体,所以在Java 程式码里试图印出其内容的时候,我们会看到的输出为null),这个Bootstrap Loader 所

做的初始工作中,除了也做一些基本的初始化动作之外,最重要的就是载入定义在sun.misc 命名空间底下的Launcher.java 之中的ExtClassLoader(因为是inner class,所以编译之後会变成Launcher$ExtClassLoader.class),并设定其Parent 为null,代表其父载入器为BootstrapLoader。然後Bootstrap Loader 再要求载入定义於sun.misc 命名空间底下的Launcher.java 之中的AppClassLoader(因为是inner class,所以编译之後会变成Launcher$AppClassLoader.class),并设定其Parent 为之前产生的ExtClassLoader 实体。

这里要请大家注意的是,Launcher$ExtClassLoader.class 与Launcher$AppClassLoader.class 都可能是由Bootstrap Loader 所载入,所以Parent 和由哪个类别载入器载入没有关系。

三个载入器的层次关系可通过运行下面的例子察看:

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:myappclassload>java AppLoader

.;D:myjavaTomcat5.0webappsaxisWEB-INFlibaxis.jar;D:myjavaTomcat5.0weba

ppsaxisWEB-INFlibcommons-logging.jar;D:myjavaTomcat5.0webappsaxisWEB-IN

Flibcommons-discovery.jar;C:oracleora81jdbclibclasses12.zip;D:myjavaJDB

CforSQLserverlibmssqlserver.jar;D:myjavaJDBCforSQLserverlibmsbase.jar;D:m

yjavaJDBCforSQLserverlibmsutil.jar;D:myjavaTomcat5.0commonlibservlet-api

.jar;D:myjavaj2sdk1.4.2_04jrelib t.jar;C:sunappserverlibj2ee.jar;D:myj

avaj2sdk1.4.2_04libjaxp.jar;D:myjavaj2sdk1.4.2_04libsax.jar;

D:myappclassload>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 所在位置下的libext 子目录。Java.exe使用的JRE是在系统变量path里指定的,可以通过修改path从而修改ExtCLassLoader的搜寻路径,也可以如下命令参数来更改,

java –Djava.ext.dirs=c:winnt AppLoader //注意 =号两边不能有空格。-D也不能和java分开。

////////////////////////////////////////////////////////////////

D:myappclassload>java ExtLoader

D:myjavaj2sdk1.4.2_04jrelibext

D:myappclassload>java -Djava.ext.dirs=c:winnt ExtLoader

c:winnt

////////////////////////////////////////////////////////////////

最後一个类别载入器是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:myjavaj2sdk1.4.2_04jrelib t.jar;D:myjavaj2sdk1.4.2_04jrelibi18n.jar;

D:myjavaj2sdk1.4.2_04jrelibsunrsasign.jar;D:myjavaj2sdk1.4.2_04jrelibj

sse.jar;D:myjavaj2sdk1.4.2_04jrelibjce.jar;D:myjavaj2sdk1.4.2_04jrelib

charsets.jar;D:myjavaj2sdk1.4.2_04jreclasses

///////////////////////////////////////////////////////////////////////////////////////

更重要的是,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

//////////////////////////////////////////////////////

如果这两个类同时又放在<JRE 所在目录>libextclasses 底下(在我的机器上是:D:myjavaj2sdk1.4.2_04jrelibextclasses,classes没有,需要自己建),输出结果如下:

/////////////////////////////////

sun.misc.Launcher$ExtClassLoader@e2eec8

sun.misc.Launcher$ExtClassLoader@e2eec8

////////////////////////////////////

最后如果在<JRE 所在目录>classes下放入这两个类,则输出结果为

/////////////////////////////////

null

null

////////////////////////////////////

如果把<JRE 所在目录>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 目录,作为其搜寻路径。

网友评论
多特网友 2012-03-02 23:43:11 回复
都是英吉利是,怎么看得懂!擦
多特网友 2012-01-19 14:01:34 回复
没基础真的不能学习吗??看的我好晕哦!
多特网友 2012-01-19 14:01:34 回复
没基础真的不能学习吗??看的我好晕哦!
多特网友 2012-03-02 23:43:11 回复
都是英吉利是,怎么看得懂!擦
精品软件课程
更多 >
C++是一种静态数据类型检查的,支持多重编程... [详细]
C语言是一种面向过程的计算机程序设计语言。多... [详细]
Visual Basic是一种由微软公司开发... [详细]
Oracle Database,又名Orac... [详细]
Visual Basic.NET是从 Vis... [详细]
Visual C++微软公司的C++开发工具... [详细]