Class Loading －－－（类装载机制，开发者不得不知道的故事）－

我们是否需要自定义的ClassLoader?

    理由之一：如果我们自定义了ClassLoader，那我们便可以控制JVM的加载动作了。

   上面说一个class标识是由于package+classname组成得。对于所有实现java.io.Serializable接口得类，由serialVersionUID管理这些类得版本(RMI,JNDI,Security里都有这样一个ID) 。它用64位的Hash来表示 (由于classname,filed,method组成)。从技术上讲如果classname,field,mehtod所构成的Hash都一样，那就会认为是同一个版本。

假设有这样一个情况，我们要写一个java 执行引擎（比如：用一个RMI 发布一个Server端程序，执行client的接口），既然要能执行，那引擎肯定要实现有Client所特定任务的接口（这里为TaskIntf）。一但任务提交给执行引擎，Server要做的第一件事情就是要装载所有要执行的代码。假设不同的终端递交了不同的代码。而偏偏又都是同样的包名，和同样的类名。那服务器能否会辨别到底是那个Client提交过来的执行请求？

现在出个问题：如果在服务器端一个执行程序执行两个客户端提交同一个版本得代码，如何才让客户端会得到预期的执行结果？

别以为这个很简单，下面我先建个RMI玩玩。看看结果会是怎样。

答案就在本文得代码里（这时候我也想知道：）

本地文件如下图。

图 2 程序目录结构（本文中含代码）。

在samepath目录下，有着两个version.Version.class，他们得包名类名都一样，唯一不同的是。

v1目录中的方法是：

    public void fx(){
        log("this = " + this + "; Version.fx(1).");
    }

v2目录中的方法是：

    public void fx(){
        log("this = " + this + "; Version.fx(2).");
    }

执行一下看看：

set CLASSPATH=.;%CURRENT_ROOT%/v1;%CURRENT_ROOT%/v2
%JAVA_HOME%/bin/java Test 结果如下图

图 3. classPath得目录设为v1

切换到

set CLASSPATH=.;%CURRENT_ROOT%/v2;%CURRENT_ROOT%/v1
%JAVA_HOME%/bin/java Test
结果如下图：

图 4. classpath目录设为v2

很明显，上面的例子中能从classpath中找到先后次序。如果我们把v1,v2的version.Version。都删调。而把他们打成一个myextension.jar包，放到java.ext.dirs目录下。。这时候就通过ExtClassLoader来装载了，而不是AppClassLoader.

那结果会是下面得：

图 5. AppClassLoader and ExtClassLoader

注意看 sun.misc.Launcher$ExtClassLoader@a9c85c 这下是有ExtClassLoader 加载了。

继续往下看，另外一个例子。在differentversions 目录下的例子，里面包含了RMI的ServerImpl这样一个执行引擎。Client实现了common.TaskIntf接口。两个 client.TaskImpl分别如下：

    static{
        log("client.TaskImpl.class.getClassLoader
        (v1) : " + TaskImpl.class.getClassLoader());
    }

    public void execute(){
        log("this = " + this + "; execute(1)");
    }

另一个则是：

     static{
        log("client.TaskImpl.class.getClassLoader
        (v1) : " + TaskImpl.class.getClassLoader());
    }

    public void execute(){
        log("this = " + this + "; execute(2)");
    }

这样子来执行（顺序随便，这里把 %CURRENT_ROOT%/client2放在前面）：

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

先启动Server..

分别把两个client提交给服务器执行， (即便执行程序中得client1.bat 和 client2.bat server监控屏幕如图6所示。)

图 6. Execution Engine Server console

在来看下面两个图（图7和图8），分别是client端得执行反映。

图 7. Execution Engine Client 1 console

图 8. Execution Engine Client 2 console

纵观上面三次执行结果，发现由于服务器启动得时候使用了AppClassLoader.所以无论怎么样都是载入得是client2(因为client2的classpath次序比较在前)，

这里client1 很郁闷，它在自己那执行明明是 execute(1) 通过 RMI 发送给服务器端执行就成了 execute(2)..

值得注意的是：在client1,client2分别发送给服务器执行之后，服务器端显示的记录是：
client.TaskImpl.class.getClassLoader(v2):sun.misc.lancuher@AppClassLoader@xxxx zhiz只执行了一次。而this=client.TaskImpl@xxxxx execute(2);执行了两次

上面已经讲到过了，对于一个ClassLoader来讲同样的page+className 只能定义一个 class,而不同的ClassLoader即便加载同一个page.className 也会定义不同的class

到这里，我才发现，解决上面提出得那个问题似乎并不容易。：（。

那如何解决呢？答案就是－－－使用自定义得classLoader ..

如果各位等不急的话，先请看（目录中 differentversionspush 里面的代码）