Java程序类加载完全揭密

 　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以及使用他们的最佳途径。

上一页  [1] [2]