深入类别载入器 forName() loadClass()

转自：http://kevin_yang.itpub.net/post/172/31025

 1.java执行

java.exe 是利用几个基本原则来寻找Java

Runtime Environment(JRE)，然后把类别档(.class)直接转交给JRE 执行之后，java.exe   就功成身退。类别加载器也是构成JRE 的其中一个重要成员，所以最后类别加载器就会自动从所在之JRE 目录底下的librt.jar 载入基础类别函式库。所以在上图里，一定是因为java.exe 定位到c:j2sdk1.4.0jre，所以才会有此输出结果。

2．预先加载与依需求加载

像基础类别函式库这样的加载方法我们叫做预先加载(pre-loading)，这是因为基础类别函式库里头的类别大多是Java 程序执行时所必备的类别，所以为了不要老是做浪费时间的I/O 动作(读取档案系统，然后将类别文件加载内存之中)，预先加载这些类别会让Java 应用程序在执行时速度稍微快一些。相对来说，我们自己所撰写的类别之加载方式，叫做依需求加载(load-on-demand)，也就是Java 程序真正用到该类别的时候，才真的把类别文件从档案系统之中加载内存

 

3．Java 提供两种方法来达成动态性

一种是隐式的(implicit)，另一种是显式的(explicit)。

隐式的(implicit)方法我们已经谈过了，也就是当程序设计师用到new 这个Java 关键词时，会让类别加载器依需求加载您所需要的类别，这种方式使用了隐式的(implicit)方法。显式的方法，又分成两种方式，一种是藉由java.lang.Class 里的forName()方法，另一种则是藉由java.lang.ClassLoader 里的loadClass()方法。

4．forName方法

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);initialized的用法:true,表示载入实例的同时也载入静态初始化区块；false，那么就只会命令类别加载器加载该类别，但不会叫用其静态初始化区块，只有等到整个程序第一次实体化某个类别时，静态初始化区块才会被调用。

档案:Office.java

public class Office

{

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

{

Office off = new Office() ;

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

Class c =

Class.forName(args[0],false,off.getClass().getClassLoader()) ;

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

Object o = c.newInstance() ;

Object o2 = c.newInstance() ;

}

}

则输出变成:

 

5．用显式的方法来达成动态性:直接使用类别加载器

这种情形与使用Class 类别的forName()方法时，第二个参数传入false

几乎是相同的结果。

档案:Office.java

public class Office

{

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

{

Office off = new Office() ;

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

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

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

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

Object o = c.newInstance() ;

Object o2 = c.newInstance() ;

}

}

执行

java Office Word

6．自己建立类别加载器来加载类别

档案:Office.java

import java.net.* ;

public class Office

{

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

{

URL u = new URL("file:/d:/my/lib/") ;

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

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

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

asm.start() ;

}

}

7．类别被哪个类别载入器载入

我们将上述的程序代码稍作修改，修改后的程序代码如下:

档案:Office.java

import java.net.* ;

public class Office

{

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

{

URL u = new URL("file:/d:/my/lib/") ;

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

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

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

asm.start() ;

URL u1 = new URL("file:/d:/my/lib/") ;

URLClassLoader ucl1 = new URLClassLoader(new URL[]{ u1 }) ;

Class c1 = ucl1.loadClass(args[0]) ;

Assembly asm1 = (Assembly) c1.newInstance() ;

asm1.start() ;

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

System.out.println(u.getClass().getClassLoader()) ;

System.out.println(ucl.getClass().getClassLoader()) ;

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

System.out.println(asm.getClass().getClassLoader()) ;

System.out.println(u1.getClass().getClassLoader()) ;

System.out.println(ucl1.getClass().getClassLoader()) ;

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

System.out.println(asm1.getClass().getClassLoader()) ;

}

}

执行后输出结果如下图:

从输出中我们可以得知，Office.class 由AppClassLoader(又称做System Loader，系统加载器)所加载，URL.class 与URLClassLoader.class 由Bootstrap Loader 所加载(注意:输出null 并非代表不是由类别载入器所载入。在Java 之中，所有的类别都必须由类别加载器加载才行，只不过Bootstrap Loader 并非由Java 所撰写而成，而是由C++实作而成，因此以Java 的观点来看，逻辑上并没有Bootstrap Loader 的类别实体)。而Word.class 分别由两个不同的URLClassLoader 实体加载。至于Assembly.class，本身应该是由AppClassLoader 加载，但是由于多型(Polymorphism)的关系，所指向的类别实体(Word.class)由特定的加载器所加载，导致打印在屏幕上的内容是其所参考的类别实体之类别加载器。Interface 这种型态本身无法直接使用new 来产生实体，所以在执行getClassLoader()的时候，叫用的一定是所参考的类别实体的getClassLoader()，要知道Interface 本身由哪个类别加载器加载，您必须使用底下程序代码:Assembly.class.getClassLoader()

 

8．一切都是由Bootstrap Loader 开始 : 类别载入器的阶层体系

当我们在命令列输入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，代表其父加载器为Bootstrap

Loader。然后Bootstrap Loader 再要求加载定义于sun.misc 命名空间底下的Launcher.java 之中的AppClassLoader(因为是inner class，所以编译之后会变成Launcher$AppClassLoader.class)，并设定其Parent 为之前产生的ExtClassLoader 实体。这里要请大家注意的是，Launcher$ExtClassLoader.class 与Launcher$AppClassLoader.class 都是由Bootstrap Loader 所加载，所以Parent 和由哪个类别加载器加载没有关系。我们可以用下图来表示:

 

这个由Bootstrap Loader   ExtClassLoader   AppClassLoader，就是我们所谓「类别载入

器的阶层体系」。

在此要请大家注意的是，AppClassLoader 和ExtClassLoader 都是URLClassLoader 的子类别。由于它们都是URLClassLoader 的子类别，所以它们也应该有URL 作为搜寻类别档的参考，由原始码中我们可以得知，AppClassLoader 所参考的URL 是从系统参数java.class.path 取出的字符串所决定，而java.class.path 则是由我们在执行java.exe 时，利用 –cp 或-classpath 或CLASSPATH 环境变量所决定。我们可以用底下程序代码测试之:

档案:test.java

public class test

{

public static void main(String args[])

{

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

System.out.println(s) ;

}

}

输出结果如下:

从这个输出结果，我们可以看出，在预设情况下，AppClassLoader 的搜寻路径为”.”(目前所在目录)，如果使用-classpath 选项(与-cp 等效)，就可以改变AppClassLoader 的搜寻路径，如果没有指定-classpath 选项，就会搜寻环境变量CLASSPATH。如果同时有CLASSPATH 的环境设定与-classpath 选项，则以-classpath 选项的内容为主，CLASSPATH 的环境设定与-classpath 选项两者的内容不会有加成的效果。

至于ExtClassLoader 也有相同的情形，不过其搜寻路径是参考系统参数 java.ext.dirs。我们可以用底下程序代码测试:

档案:test.java

public class test

{

public static void main(String args[])

{

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

System.out.println(s) ;

}

}

输出结果如下:

输出结果告诉我们，系统参数java.ext.dirs 的内容，会指向java.exe 所选择的JRE 所在位置下的

libext 子目录。系统参数java.ext.dirs 的内容可以在一开始下命列的时候来更改，如下:

最后一个类别加载器是Bootstrap Loader ， 我们可以经由查询由系统参数

sun.boot.class.path 得知Bootstrap Loader 用来搜寻类别的路径。请使用底下的程序代码测试之:

档案:test.java

public class test

{

public static void main(String args[])

{

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

System.out.println(s) ;

}

}

输出结果如下:

系统参数sun.boot.class.path 的内容可以在一开始下命列的时候来更改，如下:

 

从这三个类别加载器的搜寻路径所参考的系统参数的名字中，其实还透漏了一个讯息。请回头看到java.class.path 与sun.boot.class.path，也就是说，AppClassLoader 与Bootstrap Loader会搜寻它们所指定的位置(或JAR 文件)，如果找不到就找不到了，AppClassLoader 与Bootstrap Loader不会递归式地搜寻这些位置下的其它路径或其它没有被指定的JAR 檔。反观ExtClassLoader，所参考的系统参数是java.ext.dirs，意思是说，他会搜寻底下的所有JAR 文件以及classes 目录，作为其搜寻路径(所以您会发现上面我们在测试的时候，如果加入 -Dsun.boot.class.path=c:winnt选项时，程序的起始速度会慢了些，这是因为c:winnt 目录下的档案很多，必须花额外的时间来列举JAR 檔)。

在命令列下参数时，使用 –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 完全无关。如果您手边有原始码， 以JDK 1.4.x 为例， 请参考< 原始码根目录>hotspotsrcsharevmruntimeos.cpp 这个档案里头的os::set_boot_path 方法，您将看到程序代码片段:

static const char classpathFormat[] =

"%/lib/rt.jar:"

"%/lib/i18n.jar:"

"%/lib/sunrsasign.jar:"

"%/lib/jsse.jar:"

"%/lib/jce.jar:"

"%/lib/charsets.jar:"

"%/classes";

JDK 1.4.x 比JDK 1.3.x 新增了一些核心类别函式库(例如jsse.jar 与jce.jar)，所以如果您测试时用的是1.4.x 版的JDK，sun.boot.class.path 内容应该如下:

 

9. 委派模型

如果您对整个类别加载的方式仍有所疑问，请容笔者重新解释一下之前程序

档案:Office.java

import java.net.* ;

public class Office

{

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

{