要較好地控制類的加載，就要實(shí)現(xiàn)定制的類加載器。所有自定義的類加載器都應(yīng)繼承自java.lang.ClassLoader。而且在構(gòu)造方法中，我們也應(yīng)該設(shè)置父類加載器。然后重寫findClass()方法。differentversionspush文件夾包含了一個(gè)叫做FileSystemClassLoader的自訂制的類加載器。其結(jié)構(gòu)如圖9所示。

　　圖9. 定制類加載器關(guān)系

　　以下是在common.FileSystemClassLoader實(shí)現(xiàn)的主方法:

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();
        }
    }

　　這個(gè)類供客戶端把client.TaskImpl(v1)轉(zhuǎn)換成字節(jié)數(shù)組，之后此字節(jié)數(shù)組被發(fā)送到RMI服務(wù)端。在服務(wù)端，一個(gè)同樣的類用來(lái)把字節(jié)數(shù)組的內(nèi)容轉(zhuǎn)換回代碼。客戶端代碼如下:

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);
    }
}

　　在執(zhí)行引擎中，從客戶端收到的代碼被送到定制的類加載器中。定制的類加載器把其從字節(jié)數(shù)組定義成類，實(shí)例化并執(zhí)行。需要指出的是，對(duì)每一個(gè)客戶請(qǐng)求，我們用類FileSystemClassLoader的不同實(shí)例來(lái)定義客戶端提交的client.TaskImpl。而且，client.TaskImpl并不在服務(wù)端的類路徑中。這也就意味著當(dāng)我們?cè)贔ileSystemClassLoader調(diào)用findClass()方法時(shí)，findClass()調(diào)用內(nèi)在的defineClass()方法。類client.TaskImpl被特定的類加載器實(shí)例所定義。因此，當(dāng)FileSystemClassLoader的一個(gè)新的實(shí)例被使用，類又被重新定義為字節(jié)數(shù)組。因此，對(duì)每個(gè)客戶端請(qǐng)求類client.TaskImpl被多次定義，我們就可以在相同執(zhí)行引擎JVM中執(zhí)行不同的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文件夾下。服務(wù)端和客戶端的控制臺(tái)界面分別如圖10，11，12所示:

　　圖10. 定制類加載器執(zhí)行引擎

　　圖10顯示的是定制的類加載器控制臺(tái)。我們可以看到client.TaskImpl的代碼被多次加載。實(shí)際上針對(duì)每一個(gè)客戶端，類都被加載并初始化。

　　圖11. 定制類加載器，客戶端1

　　圖11中，含有client.TaskImpl.class.getClassLoader(v1)的日志記錄的類TaskImpl的代碼被客戶端的VM加載，然后送到服務(wù)端。圖12 另一個(gè)客戶端把包含有client.TaskImpl.class.getClassLoader(v1)的類代碼加載并送往服務(wù)端。

　　圖12. 定制類加載器，客戶端1

　　這段代碼演示了我們?nèi)绾卫貌煌念惣虞d器實(shí)例來(lái)在同一個(gè)VM上執(zhí)行不同版本的代碼。

　　J2EE的類加載器

　　J2EE的服務(wù)器傾向于以一定間隔頻率，丟棄原有的類并重新載入新的類。在某些情況下會(huì)這樣執(zhí)行，而有些情況則不。同樣，對(duì)于一個(gè)web服務(wù)器如果要丟棄一個(gè)servlet實(shí)例，可能是服務(wù)器管理員的手動(dòng)操作，也可能是此實(shí)例長(zhǎng)時(shí)間未相應(yīng)。當(dāng)一個(gè)JSP頁(yè)面被首次請(qǐng)求，容器會(huì)把此JSP頁(yè)面翻譯成一個(gè)具有特定形式的servlet代碼。一旦servlet代碼被創(chuàng)建，容器就會(huì)把這個(gè)servlet翻譯成class文件等待被使用。對(duì)于提交給容器的每次請(qǐng)求，容器都會(huì)首先檢查這個(gè)JSP文件是否剛被修改過(guò)。是的話就重新翻譯此文件，這可以確保每次的請(qǐng)求都是及時(shí)更新的。企業(yè)級(jí)的部署方案以.ear, .war, .rar等形式的文件，同樣需要重復(fù)加載，可能是隨意的也可能是依照某種配置方案定期執(zhí)行。對(duì)所有的這些情況——類的加載、卸載、重新加載……全部都是建立在我們控制應(yīng)用服務(wù)器的類加載機(jī)制的基礎(chǔ)上的。實(shí)現(xiàn)這些需要擴(kuò)展的類加載器，它可以執(zhí)行由其自身所定義的類。Brett Peterson已經(jīng)在他的文章 Understanding J2EE Application Server Class Loading Architectures給出了J2EE應(yīng)用服務(wù)器的類加載方案的詳細(xì)說(shuō)明，詳見網(wǎng)站TheServerSide.com。

　　結(jié)要

　　本文探討了類載入到虛擬機(jī)是如何進(jìn)行唯一標(biāo)識(shí)的，以及類如果存在同樣的類名和包名時(shí)所產(chǎn)生的問(wèn)題。因?yàn)闆](méi)有一個(gè)直接可用的類版本管理機(jī)制，所以如果我們要按自己的意愿來(lái)加載類時(shí)，需要自己訂制類加載器來(lái)擴(kuò)展其行為。我們可以利用許多J2EE服務(wù)器所提供的“熱部署”功能來(lái)重新加載一個(gè)新版本的類，而不改動(dòng)服務(wù)器的VM。即使不涉及應(yīng)用服務(wù)器，我們也可以利用定制類加載器來(lái)控制java應(yīng)用程序載入類時(shí)的具體行為。Ted Neward的書Server-Based Java Programming中詳細(xì)闡述java的類加載，J2EE的API以及使用他們的最佳途徑。