Java程序中类加载完全揭密

Java 程序中类加载完全揭密 (1) 类加载是 java 语言提供的最强大的机制之一。尽管类加载并不是讨论的热点话 题，但所有的编程人员都应该了解其工作机制，明白如何做才能让其满足我们的 需要。这能有效节省我们的编码时间，从不断调试 ClassNotFoundException, ClassCastException 的工作中解脱出来。 这篇文章从基础讲起，比如代码与数据的不同之处是什么，他们是如何构成一个 实例或对象的。然后深入探讨 java 虚拟机（JVM）是如何利用类加载器读取代 码，以及 java 中类加载器的主要类型。接着用一个类加载的基本算法看一下类 加载器如何加载一个内部类。本文的下一节演示一段代码来扩展和开发属于 自己的类加载器的必要性。紧接着解释如何使用定制的类加载器来完成一个一般 意义上的任务，使其可以加载任意远端客户的代码，在 JVM 中定义，实例化并 执行它。本文包括了 J2EE 关于类加载的规范——事实上这已经成为了 J2EE 的 标准之一。 类与数据 一个类代表要执行的代码，而数据则表示其相关状态。状态时常改变，而代码则 不会。当我们将一个特定的状态与一个类相对应起来，也就意味着将一个类事例 化。尽管相同的类对应的实例其状态千差万别，但其本质都对应着同一段代码。 在 JAVA 中，一个类通常有着一个.class 文件，但也有例外。在 JAVA 的运行时 环境中（Java runtime），每一个类都有一个以第一类(first-class)的 Java 对象所表 现出现的代码，其是 java.lang.Class 的实例。我们编译一个 JAVA 文件，编译器 都会嵌入一个 public, static, final 修饰的类型为 java.lang.Class，名称为 class 的域 变量在其字节码文件中。因为使用了 public 修饰，我们可以采用如下的形式对其 访问： java.lang.Class klass = Myclass.class; 一旦一个类被载入 JVM 中，同一个类就不会被再次载入了（切记，同一个类）。 这里存在一个问题就是什么是“同一个类”？正如一个对象有一个具体的状态，即 标识，一个对象始终和其代码(类)相关联。同理，载入 JVM 的类也有一个具体 的标识，我们接下来看。 在 JAVA 中，一个类用其完全匹配类名(fully qualified class name)作为标识，这里 指的完全匹配类名包括包名和类名。但在 JVM 中一个类用其全名和一个加载类 ClassLoader 的实例作为唯一标识。因此，如果一个名为 Pg 的包中，有一个名为 Cl 的类，被类加载器 KlassLoader 的一个实例 kl1 加载，Cl 的实例，即 C1.class 在 JVM 中表示为(Cl, Pg, kl1)。这意味着两个类加载器的实例(Cl, Pg, kl1) 和 (Cl, Pg, kl2)是不同的，被它们所加载的类也因此完全不同，互不兼容的。那么在 JVM 中到底有多少种类加载器的实例？下一节我们揭示答案。 类加载器 在 JVM 中，每一个类都被 java.lang.ClassLoader 的一些实例来加载.类 ClassLoader 是在包中 java.lang 里，开发者可以自由地继承它并添加自己的功能来加载类。 无论何时我们键入 java MyMainClass 来开始运行一个新的 JVM，“引导类加载器 (bootstrap class loader)”负责将一些关键的 Java 类，如 java.lang.Object 和其他一些 运行时代码先加载进内存中。运行时的类在 JRE\lib\rt.jar 包文件中。因为这属于 系统底层执行动作，我们无法在 JAVA 文档中找到引导类加载器的工作细节。基 于同样的原因，引导类加载器的行为在各 JVM 之间也是大相径庭。 同理，如果我们按照如下方式： log(java.lang.String.class.getClassLoader()); 来获取 java 的核心运行时类的加载器，就会得到 null。 接下来介绍 java 的扩展类加载器。扩展库提供比 java 运行代码更多的特性，我 们可以把扩展库保存在由 java.ext.dirs 属性提供的路径中。 (编辑注：java.ext.dirs 属性指的是系统属性下的一个 key，所有的系统属性可以 通过 System.getProperties()获得。在编者的系统中，java.ext.dirs 的 value 是” C:\Program Files\Java\jdk1.5.0_04\jre\lib\ext”。下面将要谈到的如 java.class.path 也 同属系统属性的一个 key。) 类 ExtClassLoader 专门用来加载所有 java.ext.dirs 下的.jar 文件。开发者可以通过 把自己的.jar 文件或库文件加入到扩展目录的 classpath，使其可以被扩展类加载 器读取。 从开发者的角度，第三种同样也是最重要的一种类加载器是 AppClassLoader。这 种类加载器用来读取所有的对应在 java.class.path 系统属性的路径下的类。 Sun 的 java 指南中，文章“理解扩展类加载”（Understanding Extension Class Loading）对以上三个类加载器路径有更详尽的解释，这是其他几个 JDK 中的类 加载器 ●java.net.URLClassLoader ●java.security.SecureClassLoader ●java.rmi.server.RMIClassLoader ●sun.applet.AppletClassLoader java.lang.Thread，包含了 public ClassLoader getContextClassLoader()方法，这一方 法返回针对一具体线程的上下文环境类加载器。此类加载器由线程的创建者提供， 以供此线程中运行的代码在需要加载类或资源时使用。如果此加载器未被建立， 缺省是其父线程的上下文类加载器。原始的类加载器一般由读取应用程序的类加 载器建立。 类加载器如何工作？ 除了引导类加载器，所有的类加载器都有一个父类加载器，不仅如此，所有的类 加载器也都是 java.lang.ClassLoader 类型。以上两种类加载器是不同的，而且对 于开发者自订制的类加载器的正常运行也至关重要。最重要的方面是正确设置父 类加载器。任何类加载器，其父类加载器是加载该类加载器的类加载器实例。（记 住，类加载器本身也是一个类！） 使用 loadClass()方法可以从类加载器中获得该类。我们可以通过 java.lang.ClassLoader 的源代码来了解该方法工作的细节，如下： protected synchronized Class loadClass (String name, boolean resolve) throws ClassNotFoundException{ // First check if the class is already loaded Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClass0(name); } } catch (ClassNotFoundException e) { // If still not found, then invoke // findClass to find the class. c = findClass(name); } } if (resolve) { resolveClass(c); } return c; } 我们可以使用 ClassLoader 的两种构造方法来设置父类加载器： public class MyClassLoader extends ClassLoader{ public MyClassLoader(){ super(MyClassLoader.class.getClassLoader()); } } 或 public class MyClassLoader extends ClassLoader{ public MyClassLoader(){ super(getClass().getClassLoader()); } } 第一种方式较为常用，因为通常不建议在构造方法里调用 getClass()方法，因为 对象的初始化只是在构造方法的出口处才完全完成。因此，如果父类加载器被正 确建立，当要示从一个类加载器的实例获得一个类时，如果它不能找到这个类， 它应该首先去访问其父类。如果父类不能找到它(即其父类也不能找不这个类， 等等)，而且如果 findBootstrapClass0()方法也失败了，则调用 findClass()方法。 findClass()方法的缺省实现会抛出 ClassNotFoundException，当它们继承 java.lang.ClassLoader 来订制类加载器时开发者需要实现这个方法。findClass()的 缺省实现方式如下： protected Class findClass(String name) throws ClassNotFoundException { throw new ClassNotFoundException(name); } 在 findClass()方法内部，类加载器需要获取任意来源的字节码。来源可以是文件 系统，URL，数据库，可以产生字节码的另一个应用程序，及其他类似的可以产 生 java 规范的字节码的来源。你甚至可以使用 BCEL (Byte Code Engineering Library：字节码库)，它提供了运行时创建类的捷径。BCEL 已经被成功地 使用在以下方面：编译器，优化器，混淆器，代码产生器及其他工具。一旦 字节码被检索，此方法就会调用 defineClass()方法，此行为对不同的类加载实例 是有差异的。因此，如果两个类加载实例从同一个来源定义一个类，所定义的结 果是不同的。 JAVA 语言规范（Java language specification）详细解释了 JAVA 执行引擎中的类 或接口的加载（loading），链接（linking）或初始化（initialization）过程。 图一显示了一个主类称为 MyMainClass 的应用程序。依照之前的阐述， MyMainClass.class 会被 AppClassLoader 加载。 MyMainClass 创建了两个类加载 器的实例：CustomClassLoader1 和 CustomClassLoader2,他们可以从某数据源（比 如网络）获取名为 Target 的字节码。这表示类 Target 的类定义不在应用程序类 路径或扩展类路径。在这种情况下，如果 MyMainClass 想要用自定义的类加载 器加载 Target 类，CustomClassLoader1 和 CustomClassLoader2 会分别独立地加载 并定义 Target.class 类。这在 java 中有重要的意义。如果 Target 类有一些静态的 初始化代码，并且假设我们只希望这些代码在 JVM 中只执行一次，而这些代码 在我们目前的步骤中会执行两次——分别被不同的 CustomClassLoaders 加载并 执行。如果类 Target 被两个 CustomClassLoaders 加载并创建两个实例 Target1 和 Target2，如图一显示，它们不是类型兼容的。换句话说，在 JVM 中无法执行以 下代码： Target target3 = (Target) target2; 以上代码会抛出一个 ClassCastException。这是因为 JVM 把他们视为分别不同的 类，因为他们被不同的类加载器所定义。这种情况当我们不是使用两个不同的类 加载器 CustomClassLoader1 和 CustomClassLoader2，而是使用同一个类加载器 CustomClassLoader 的不同实例时，也会出现同样的错误。这些会在本文后边用 具体代码说明。 图 1. 在同一个 JVM 中多个类加载器加载同一个目标类 关于类加载、定义和链接的更多解释，请参考 Andreas Schaefer 的"Inside Class Loaders." 为什么我们需要我们自己的类加载器 原因之一为开发者写自己的类加载器来控制 JVM 中的类加载行为，java 中的类 靠其包名和类名来标识，对于实现了 java.io.Serializable 接口的类， serialVersionUID 扮演了一个标识类版本的重要角色。这个唯一标识是一个类名、 接口名、成员方法及属性等组成的一个 64 位的哈希字段，而且也没有其他快捷 的方式来标识一个类的版本。严格说来，如果以上的都匹配，那么则属于同一个 类。 但是让我们思考如下情况：我们需要开发一个通用的执行引擎。可以执行实现某 一特定接口的任何任务。当任务被提交到这个引擎，首先需要加载这个任务的代 码。假设不同的客户对此引擎提交了不同的任务，凑巧，这些所有的任务都有一 个相同的类名和包名。现在面临的问题就是这个引擎是否可以针对不同的用户所 提交的信息而做出不同的反应。这一情况在下文的参考一节有可供下载的代码样 例，samepath 和 differentversions，这两个目录分别演示了这一概念。 图 2 显示了文件目录结构，有三个子目录 samepath, differentversions, 和 differentversionspush，里边是例子： 图 2. 文件夹结构组织示例 在 samepath 中，类 version.Version 保存在 v1 和 v2 两个子目录里，两个类具有同样的类名和包名，唯一不 同的是下边这行： public void fx(){ log("this = " + this + "; Version.fx(1)."); } V1 中，日志记录中有 Version.fx(1)，而在 v2 中则是 Version.fx(2)。把这个两个存在细微不同的类放在一个 classpath 下，然后运行 Test 类： set CLASSPATH=.;%CURRENT_ROOT%\v1;%CURRENT_ROOT%\v2 %JAVA_HOME%\bin\java Test 图 3 显示了控制台输出。我们可以看到对应着 Version.fx(1)的代码被执行了，因为类加载器在 classpath 首 先看到此版本的代码。 图 3. 在类路径中 samepath 测试排在最前面的 version 1 再次运行，类路径做如下微小改动。 set CLASSPATH=.;%CURRENT_ROOT%\v2;%CURRENT_ROOT%\v1 %JAVA_HOME%\bin\java Test 控制台的输出变为图4。对应着Version.fx(2)的代码被加载，因为类加载器在 classpath中首先找到它的路径。 图 4. 在类路径中 samepath 测试排在最前面的 version 2 根据以上例子可以很明显地看出，类加载器加载在类路径中被首先找到的元素。 如果我们在v1和v2中删除了 version.Version，做一个非 version.Version形式的.jar 文件，如 myextension.jar，把它放到对应 java.ext.dirs 的路径下，再次执行后看到 version.Version 不再被 AppClassLoader 加载，而是被扩展类加载器加载。如图 5 所示。 图 5. AppClassLoader 及 ExtClassLoader 继续这个例子，文件夹 differentversions 包含了一个 RMI 执行引擎，客户端可以 提供给执行引擎任何实现了 common.TaskIntf 接口的任务。子文件夹 client1 和 client2 包含了类 client.TaskImpl 有个细微不同的两个版本。两个类的区别在以下 几行： static{ log("client.TaskImpl.class.getClassLoader (v1) : " + TaskImpl.class.getClassLoader()); } public void execute(){ log("this = " + this + "; execute(1)"); } 在 client1 和 client2 里分别有 getClassLoader(v1) 与 execute(1)和 getClassLoader(v2) 与 execute(2)的的 log 语句。并且，在开始执行引擎 RMI 服 务器的代码中，我们随意地将 client2 的任务实现放在类路径的前面。 CLASSPATH=%CURRENT_ROOT%\common;%CURRENT_ROOT%\server; %CURRENT_ROOT%\client2;%CURRENT_ROOT%\client1 %JAVA_HOME%\bin\java server.Server 如图 6，7，8 的屏幕截图，在客户端 VM，各自的 client.TaskImpl 类被加载、实 例化，并发送到服务端的 VM 来执行。从服务端的控制台，可以明显看到 client.TaskImpl 代码只被服务端的 VM 执行一次，这个单一的代码版本在服务端 多次生成了许多实例，并执行任务。 图 6. 执行引擎服务器控制台 图 6 显示了服务端的控制台，加载并执行两个不同的客户端的请求，如图７，８ 所示。需要注意的是，代码只被加载了一次（从静态初始化块的日志中也可以明 显看出），但对于客户端的调用这个方法被执行了两次。 图７. 执行引擎客户端 1 控制台 图７中，客户端 VM 加载了含有 client.TaskImpl.class.getClassLoader(v1)的日志内 容的类 TaskImpl 的代码，并提供给服务端的执行引擎。图 8 的客户端 VM 加载 了另一个 TaskImpl 的代码，并发送给服务端。 图 8. 执行引擎客户端 2 控制台 在客户端的 VM 中，类 client.TaskImpl 被分别加载，初始化，并发送到服务端执 行。图 6 还揭示了 client.TaskImpl 的代码只在服务端的 VM 中加载了一次，但这 “唯一的一次”却在服务端创造了许多实例并执行。或许客户端 1 该不高兴了因为 并不是它的 client.TaskImpl(v1)的方法调用被服务端执行了，而是其他的一些代 码。如何解决这一问题？答案就是实现定制的类加载器。 定制类加载器 要较好地控制类的加载，就要实现定制的类加载器。所有自定义的类加载器都应 继承自 java.lang.ClassLoader。而且在构造方法中，我们也应该设置父类加载器。 然后重写 findClass()方法。differentversionspush 文件夹包含了一个叫做 FileSystemClassLoader 的自订制的类加载器。其结构如图 9 所示。 图 9. 定制类加载器关系 以下是在 common.FileSystemClassLoader 实现的主方法： public byte[] findClassBytes(String className){ try{ String pathName = currentRoot + File.separatorChar + className. replace('.', File.separatorChar) + ".class"; FileInputStream inFile = new FileInputStream(pathName); byte[] classBytes = new byte[inFile.available()]; inFile.read(classBytes); return classBytes; } catch (java.io.IOException ioEx){ return null; } } public Class findClass(String name)throws ClassNotFoundException{ byte[] classBytes = findClassBytes(name); if (classBytes==null){ throw new ClassNotFoundException(); } else{ return defineClass(name, classBytes, 0, classBytes.length); } } public Class findClass(String name, byte[] classBytes)throws ClassNotFoundException{ if (classBytes==null){ throw new ClassNotFoundException( "(classBytes==null)"); } else{ return defineClass(name, classBytes, 0, classBytes.length); } } public void execute(String codeName, byte[] code){ Class klass = null; try{ klass = findClass(codeName, code); TaskIntf task = (TaskIntf) klass.newInstance(); task.execute(); } catch(Exception exception){ exception.printStackTrace(); } } 这个类供客户端把 client.TaskImpl(v1)转换成字节数组，之后此字节数组被发送 到 RMI 服务端。在服务端，一个同样的类用来把字节数组的内容转换回代码。 客户端代码如下： public class Client{ public static void main (String[] args){ try{ byte[] code = getClassDefinition ("client.TaskImpl"); serverIntf.execute("client.TaskImpl", code); } catch(RemoteException remoteException){ remoteException.printStackTrace(); } } private static byte[] getClassDefinition (String codeName){ String userDir = System.getProperties(). getProperty("BytePath"); FileSystemClassLoader fscl1 = null; try{ fscl1 = new FileSystemClassLoader (userDir); } catch(FileNotFoundException fileNotFoundException){ fileNotFoundException.printStackTrace(); } return fscl1.findClassBytes(codeName); } } 在执行引擎中，从客户端收到的代码被送到定制的类加载器中。定制的类加载器 把其从字节数组定义成类，实例化并执行。需要指出的是，对每一个客户请求， 我们用类 FileSystemClassLoader 的不同实例来定义客户端提交的 client.TaskImpl。 而且，client.TaskImpl 并不在服务端的类路径中。这也就意味着当我们在 FileSystemClassLoader调用 findClass()方法时，findClass()调用内在的defineClass() 方法。类 client.TaskImpl 被特定的类加载器实例所定义。因此，当 FileSystemClassLoader 的一个新的实例被使用，类又被重新定义为字节数组。因 此，对每个客户端请求类 client.TaskImpl 被多次定义，我们就可以在相同执行引 擎 JVM 中执行不同的 client.TaskImpl 的代码。 public void execute(String codeName, byte[] code)throws RemoteException{ FileSystemClassLoader fileSystemClassLoader = null; try{ fileSystemClassLoader = new FileSystemClassLoader(); fileSystemClassLoader.execute(codeName, code); } catch(Exception exception){ throw new RemoteException(exception.getMessage()); } } 示例在 differentversionspush 文件夹下。服务端和客户端的控制台界面分别如图 10，11，12 所示： 图 10. 定制类加载器执行引擎 图 10 显示的是定制的类加载器控制台。我们可以看到 client.TaskImpl 的代码被 多次加载。实际上针对每一个客户端，类都被加载并初始化。 图 11. 定制类加载器，客户端 1 图 11 中，含有 client.TaskImpl.class.getClassLoader(v1)的日志记录的类 TaskImpl 的代码被客户端的 VM 加载，然后送到服务端。图 12 另一个客户端把包含有 client.TaskImpl.class.getClassLoader(v1)的类代码加载并送往服务端。 图 12. 定制类加载器，客户端 1 这段代码演示了我们如何利用不同的类加载器实例来在同一个 VM 上执行不同 版本的代码。 J2EE 的类加载器 J2EE 的服务器倾向于以一定间隔频率，丢弃原有的类并重新载入新的类。在某 些情况下会这样执行，而有些情况则不。同样，对于一个 web 服务器如果要丢 弃一个 servlet 实例，可能是服务器管理员的手动操作，也可能是此实例长时间 未相应。当一个 JSP 页面被首次请求，容器会把此 JSP 页面翻译成一个具有特定 形式的 servlet 代码。一旦 servlet 代码被创建，容器就会把这个 servlet 翻译成 class 文件等待被使用。对于提交给容器的每次请求，容器都会首先检查这个 JSP 文件 是否刚被修改过。是的话就重新翻译此文件，这可以确保每次的请求都是及时更 新的。企业级的部署以.ear, .war, .rar 等形式的文件，同样需要重复加载，可 能是随意的也可能是依照某种配置方案定期执行。对所有的这些情况——类的加 载、卸载、重新加载……全部都是建立在我们控制应用服务器的类加载机制的基 础上的。实现这些需要扩展的类加载器，它可以执行由其自身所定义的类。Brett Peterson 已经在他的文章 Understanding J2EE Application Server Class Loading Architectures 给出了 J2EE 应用服务器的类加载方案的详细说明，详见网站 TheServerSide.com。 结要 本文探讨了类载入到虚拟机是如何进行唯一标识的，以及类如果存在同样的类名 和包名时所产生的问题。因为没有一个直接可用的类版本管理机制，所以如果我 们要按自己的意愿来加载类时，需要自己订制类加载器来扩展其行为。我们可以 利用许多 J2EE 服务器所提供的“热部署”功能来重新加载一个新版本的类，而不 改动服务器的 VM。即使不涉及应用服务器，我们也可以利用定制类加载器来控 制 java 应用程序载入类时的具体行为。Ted Neward 的书 Server-Based Java Programming 中详细阐述 java 的类加载，J2EE 的 API以及使用他们的最佳途径。 Java 程序中类加载完全揭密 (2) 为了深入了解 Java 的 ClassLoader 机制，我们先来做以下实验： package java.lang; public class Test { public static void main(String[] args) { char[] c = "1234567890".toCharArray(); String s = new String(0, 10, c); } } String 类有一个 Package 权限的构造函数 String（int offset， int length， char[] array），按照默认的访问权限，由于 Test 属于 java.lang 包，因此理论上应该可 以访问 String 的这个构造函数。编译通过！执行时结果如下： Exception in thread "main" java.lang.SecurityException: Prohibited package name: java.lang at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.defineClass(Unknown Source) at java.net.URLClassLoader.access$100(Unknown Source) at java.net.URLClassLoader$1.run(Unknown Source) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClassInternal(Unknown Source) 奇怪吧？要弄清为什么会有 SecurityException，就必须搞清楚 ClassLoader 的机制。 Java 的 ClassLoader 就是用来动态装载 class 的，ClassLoader 对一个 class 只 会装载一次，JVM 使用的 ClassLoader 一共有 4 种： 启动类装载器，标准扩展类装载器，类路径装载器和网络类装载器。 这 4 种 ClassLoader 的优先级依次从高到低，使用所谓的“双亲委派模型”。 确切地说，如果一个网络类装载器被请求装载一个 java.lang.Integer，它会首先把 请求发送给上一级的类路径装载器，如果返回已装载，则网络类装载器将不会装 载这个 java.lang.Integer，如果上一级的类路径装载器返回未装载，它才会装载 java.lang.Integer. 类似的，类路径装载器收到请求后（无论是直接请求装载还是下一级的 ClassLoader 上传的请求），它也会先把请求发送到上一级的标准扩展类装载器， 这样一层一层上传，于是启动类装载器优先级最高，如果它按照自己的方式找到 了 java.lang.Integer，则下面的 ClassLoader 都不能再装载 java.lang.Integer，尽管 你自己写了一个 java.lang.Integer，试图取代核心库的 java.lang.Integer 是不可能 的，因为自己写的这个类根本无法被下层的 ClassLoader 装载。 再说说 Package 权限。Java 语言规定，在同一个包中的 class，如果没有修饰 符，默认为 Package 权限，包内的 class 都可以访问。但是这还不够准确。确切 的说，只有由同一个 ClassLoader 装载的 class 才具有以上的 Package 权限。比如 启动类装载器装载了 java.lang.String，类路径装载器装载了我们自己写的 java.lang.Test，它们不能互相访问对方具有 Package 权限的方法。这样就阻止了 恶意代码访问核心类的 Package 权限方法。