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
racleora81jdbclibclasses12.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 目录，作为其搜寻路径。
[复制链接]
|( 京ICP备09078825号 )
发表于 2016-9-25 11:17:22
收藏
楼主