技术分析Java类加载内幕详细讲解二(图)

　　 
　　图3显示了控制台输出。我们可以看到对应着Version.fx(1)的代码被执行了，因为类加载器在classpath首先看到此版本的代码。
　　

　Java类加载内幕详细讲解二(图)（图一）" />

　　图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
　　
　　这段代码演示了我们如

原文转自：http://www.ltesting.net