译 Java类加载机制（二）

译：ayi 译文疏漏，请多多指点

原文：http://www.onjava.com/pub/a/onjava/2005/01/26/classloading.html

 

注：因内容太多，分为一、二两篇文章,建议下载附件查看

 

为什么我们要使用我们自己的类加载器？

 

    开发者编写自己的类加载器的一个理由是控制JVM的行为。在java中区分一个类是通过包名加类名。对于实现了java.io.Serializable接口的类，serialVersionUID 将在类的版本化中担当一个重要角色。这种流唯一标志（ stream-unique identifier ）是一个由类名、接口名、方法以及字段生成的一个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)在log 语句中；而在v2中，是Version.fx(2)。在相同的路径下，这两个不同版本的类仅有这点区别。现在执行Test 如下：

set CLASSPATH=.;%CURRENT_ROOT%\v1;%CURRENT_ROOT%\v2  %JAVA_HOME%\bin\java Test

在图3中，我们将看到控制台的输出，Version.fx(1) 被加载了，因为ClassLoader在classpath中首先找到了v1中的类。

 

 

图3 在版本1的test类的路径放在前面

我们稍微改变一下classpath中个路径的先后顺序，再次运行一次：

set CLASSPATH=.;%CURRENT_ROOT%\v2;%CURRENT_ROOT%\v1  %JAVA_HOME%\bin\java Test

控制台的输出改变了，如图4。现在，Version.fx(2) 被执行了，因为class loader 先找到了这个版本的类。

 

图4 在版本2的test类的路径放在前面

从上面的可以看出，class loader 会加载在classpath中先找到的类。如果我们不这样，从v1、v2中删除version.Version ，而把它们打包在一个myextension.jar的.jar文件中，并把它们放到java.ext.dirs目录下面，重新测试，我们将看到，它将不再被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的log语句中执行的是getClassLoader(v1) 是 execute(1)，在client2的log语句中执行的是getClassLoader(v2) 是 execute(2)。而且，在启动RMI服务器引擎的脚本中，我们不妨把client2路径放在前面：

CLASSPATH=%CURRENT_ROOT%\common;%CURRENT_ROOT%\server;      %CURRENT_ROOT%\client2;%CURRENT_ROOT%\client1  %JAVA_HOME%\bin\java server.Server

在图6、7、8的屏幕截屏中展示了这时的情况。这时，在两个客户虚拟机中，单独的client.TaskImpl类，被加载、初始化，并传递到了服务器端虚拟机的执行引擎中。从服务器端的控制台可以看出，client.TaskImpl仅被加载了一次。这个单独“版本”的代码在服务器端

被用来产生许多client.TaskImpl 实例，来执行任务。

图6 服务器端控制台输出

图6展示了服务器端引擎控制台的输出，它加载、执行两个各自的客户请求（如图7、8所示）。要指出的是，在这里代码仅被执行了一次（很明显，从静态初始化语句块中的log语句来看），但是这个方法被执行了两次，每个客户的一次调用。

图7 客户1的控制台

在图7中，服务器端提供的类TaskImpl 包括语句client.TaskImpl.class.getClassLoader(v1) 被加载入了客户虚拟机。在图8中，客户虚拟机加载了不同的,包含client.TaskImpl.class.getClassLoader(v2)的，TaskImpl 类代码。

图8 客户2的控制台

这里，各自的client.TaskImpl 类被加载、初始化，并且交给服务器端虚拟机来执行。再次看一下图6所展示的服务器端的控制台，显示了client.TaskImpl 加载且仅被加载了一次。这个单独的代码将被用来在服务器端生成client.TaskImpl 实例。Client1将不高兴了，因为它的语句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)为byte[]。这个byte[]将被传递给服务器端执行引擎。在服务器端，相同的类将被用来从字节数组逆转定义这个类。客户端代码如下：

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类并不在服务器端的classpath范围内。这就意味着，当我们在FileSystemClassLoader中调用findClass() 时，findClass()会从内部调用defineClass(), client.TaskImpl将被各自的类加载器实例加载。 当有一个新的FileSystemClassLoader 实例来加载时，照样从逆定义类开始重新做一遍。所以，对每个客户调用，类client.TaskImpl 都被重新定义了，使我们能够在同一个虚拟机中执行“不同版本”的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 下的examples。服务器和客户端控制台输出，如图10 、11、12中所示：

图10 服务器端的Custom class loader 的执行结果

图10 展示了客户类加载器的虚拟机控制台。我们可以看到client.TaskImpl 被执行了不只一次。事实上，对每个客户执行上下文环境，这个类被新加载和初始化一次。

图11 客户类加载器引擎 Client 1

在图11中，包含了语句client.TaskImpl.class.getClassLoader(v1) 的TaskImpl类的这些代码在客户端被加载，然后被放到服务器端执行。图12，包含了语句client.TaskImpl.class.getClassLoader(v2) 的TaskImpl的不同类在客户端2的加载情况，并在服务器端执行。

图12 客户类加载引擎 ，client2

 

这例子向我们展示了，当在同一个JVM中有“不同版本”的代码时，我们怎样使用各自的类加载器实例来实现一一对应的边对边执行。

类加载器在J2EE中

在j2ee中，类加载器倾向于在不同的时间段移除和重新加载类。这种情况在某些实现中存在，在某些中没有。web服务器可能会移除以前的一个已经加载的servlet实例，可能因为是管理员明确地要这么做，也可能是这个servlet已经空闲的很长一段时间。当第一次请求一个jsp（假设这个jsp还没有被初次编译），JSP引擎将转译这个jsp为一个页面实现类，切实一个标准的servlet类。只要这个页面实现类servlet一创建，它将被JSP引擎编译为一个class文件、备用。每当客户请求这个jsp时，编译器将首先会检查这个jsp是否被修改了。如果是的话，JSP引擎将把它重新转译，以确保给客户端的响应是最新的jsp页面实现所生成的。以.ear, .war, .rar形式的企业应用程序部署单元，也需要在需要的时候或配置策略改变时，被加载或重新加载。对所有的情况来说，都有可能被加载、移除以及重新加载，除非我们已经控制了应用程序服务器的类加载策略。这通过扩展类加载器可以做到，因为它能执行在它范围内的代码。

Brett Peterson已经在发表在 TheServerSide.com的"Understanding J2EE Application Server Class Loading Architectures"上给出了J2EE application server 的类加载模式的解释。

总结

这篇文章讲述了怎样把类加载到JVM并唯一标识，和具有相同类名和包名时的一些限制。

因为没有直接的类版本结构，如果我们想按我们自己得到想法来加载类时，我们不得不使用客户类加载器来扩展实现。许多J2EE应用程序服务器有“热部署”的能力，能够使我们以一个新的类定义来重新加载应用程序，而不需要关闭服务器。这些应用程序服务器利用了客户类加载器。尽管我们不使用应用程序服务器，我们可以创建和使用客户类加载器来更好的控制java应用程序的类加载。 Ted Neward的书Server-Based Java Programming

非常好的描述了java类加载的详细细节，并告诉了我们一些在 J2EE APIs中没有提到的东西以及怎样更好的去使用它们。

 

 

参考

Sample code for this article 

JDK 1.5 API Docs 

The Java language specification 

"Understanding Extension Class Loading " in the Java tutorial 

"Inside Class Loaders" from ONJava 

"Inside Class Loaders: Debugging" from ONJava 

"What version is your Java code?" from JavaWorld 

"Understanding J2EE Applicatio