|
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 目录，作为其搜寻路径。
|
发表于 2016-9-25 11:17:22
