技术分析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中首先找到它的路径。
　　　技术分析Java类加载内幕具体讲解二(图)（图二）

　　图4. 在类路径中samepath测试排在最前面的version 2
　　
　　根据以上例子可以很明显地看出，类加载器加载在类路径中被首先找到的元素。假如我们在v1和v2中删除了version.Version，做一个非version.Version形式的.jar文件，如myextension.jar，把它放到对应java.ext.dirs的路径下，再次执行后看到version.Version不再被AppClassLoader加载，而是被扩展类加载器加载。如图5所示。
　　　技术分析Java类加载内幕具体讲解二(图)（图三）

　　图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执行一次，这个单一的代码版本在服务端多次生成了许多实例，并执行任务。
　　　技术分析Java类加载内幕具体讲解二(图)（图四）

　　图6. 执行引擎服务器控制台
　　
　　图6显示了服务端的控制台，加载并执行两个不同的客户端的请求，如图７，８所示。需要注重的是，代码只被加载了一次（从静态初始化块的日志中也可以明显看出），但对于客户端的调用这个方法被执行了两次。
　　　技术分析Java类加载内幕具体讲解二(图)（图五）

　　图７. 执行引擎客户端 1控制台
　　
　　图７中，客户端VM加载了含有client.TaskImpl.class.getClassLoader(v1)的日志内容的类TaskImpl的代码，并提供给服务端的执行引擎。图8的客户端VM加载了另一个TaskImpl的代码，并发送给服务端。
　　　技术分析Java类加载内幕具体讲解二(图)（图六）

　　图8. 执行引擎客户端 2控制台
　　
　　在客户端的VM中，类client.TaskImpl被分别加载，初始化，并发送到服务端执行。图6还揭示了client.TaskImpl的代码只在服务端的VM中加载了一次，但这“唯一的一次”却在服务端创造了许多实例并执行。或许客户端1该不兴奋了因为并不是它的client.TaskImpl(v1)的方法调用被服务端执行了，而是其他的一些代码。