類的熱替換是Java在線升級系統設計中的基礎技術，從文中給出的實例來看，構建在線升級系統不僅僅是一個技術問題，還牽扯到很多管理方面的因素，比如：如何管理、部署系統中的可在線升級部分和不可在線升級部分以降低系統的管理、維護成本等。

對于許多關鍵性業務或者龐大的Java系統來說，如果必須暫停系統服務才能進行系統升級，既會大大影響到系統的可用性，同時也增加了系統的管理和維護成本。因此，如果能夠方便地在不停止系統業務的情況下進行系統升級，則可以很好地解決上述問題。

JavaClassLoader技術剖析

要構建在線升級系統，一個重要的技術就是能夠實現Java類的熱替換——也就是在不停止正在運行的系統的情況下進行類（對象）的升級替換。而Java的ClassLoader正是實現這項技術的基礎。

在Java中，類的實例化流程分為兩個部分：類的加載和類的實例化。類的加載又分為顯式加載和隱式加載。大家使用new關鍵字創建類實例時，其實就隱式地包含了類的加載過程。對于類的顯式加載來說，比較常用的是Class.forName。其實，它們都是通過調用ClassLoader類的loadClass方法來完成類的實際加載工作的。直接調用ClassLoader的loadClass方法是另外一種不常用的顯式加載類的技術。

圖1.Java類加載器層次結構圖

ClassLoader在加載類時有一定的層次關系和規則。在Java中，有四種類型的類加載器，分別為：BootStrapClassLoader、ExtClassLoader、AppClassLoader以及用戶自定義的ClassLoader。這四種類加載器分別負責不同路徑的類的加載，并形成了一個類加載的層次結構。

BootStrapClassLoader處于類加載器層次結構的最高層，負責sun.boot.class.path路徑下類的加載，默認為jre/lib目錄下的核心API或-Xbootclasspath選項指定的jar包。ExtClassLoader的加載路徑為java.ext.dirs，默認為jre/lib/ext目錄或者-Djava.ext.dirs指定目錄下的jar包加載。AppClassLoader的加載路徑為java.class.path，默認為環境變量CLASSPATH中設定的值。也可以通過-classpath選型進行指定。用戶自定義ClassLoader可以根據用戶的需要定制自己的類加載過程，在運行期進行指定類的動態實時加載。

這四種類加載器的層次關系圖如圖1所示。一般來說，這四種類加載器會形成一種父子關系，高層為低層的父加載器。在進行類加載時，首先會自底向上挨個檢查是否已經加載了指定類，如果已經加載則直接返回該類的引用。如果到最高層也沒有加載過指定類，那么會自頂向下挨個嘗試加載，直到用戶自定義類加載器，如果還不能成功，就會拋出異常。Java類的加載過程如圖2所示。

圖2.Java類的加過程

每個類加載器有自己的名字空間，對于同一個類加載器實例來說，名字相同的類只能存在一個，并且僅加載一次。不管該類有沒有變化，下次再需要加載時，它只是從自己的緩存中直接返回已經加載過的類引用。

我們編寫的應用類默認情況下都是通過AppClassLoader進行加載的。當我們使用new關鍵字或者Class.forName來加載類時，所要加載的類都是由調用new或者Class.forName的類的類加載器（也是AppClassLoader）進行加載的。要想實現Java類的熱替換，首先必須要實現系統中同名類的不同版本實例的共存，通過上面的介紹我們知道，要想實現同一個類的不同版本的共存，我們必須要通過不同的類加載器來加載該類的不同版本。另外，為了能夠繞過Java類的既定加載過程，我們需要實現自己的類加載器，并在其中對類的加載過程進行完全的控制和管理。 #p#

編寫自定義的ClassLoader

為了能夠完全掌控類的加載過程，我們的定制類加載器需要直接從ClassLoader繼承。首先我們來介紹一下ClassLoader類中和熱替換有關的的一些重要方法。

◆findLoadedClass：每個類加載器都維護有自己的一份已加載類名字空間，其中不能出現兩個同名的類。凡是通過該類加載器加載的類，無論是直接的還是間接的，都保存在自己的名字空間中，該方法就是在該名字空間中尋找指定的類是否已存在，如果存在就返回給類的引用，否則就返回null。這里的直接是指，存在于該類加載器的加載路徑上并由該加載器完成加載，間接是指，由該類加載器把類的加載工作委托給其他類加載器完成類的實際加載。

◆getSystemClassLoader：Java2中新增的方法。該方法返回系統使用的ClassLoader。可以在自己定制的類加載器中通過該方法把一部分工作轉交給系統類加載器去處理。

◆defineClass：該方法是ClassLoader中非常重要的一個方法，它接收以字節數組表示的類字節碼，并把它轉換成Class實例，該方法轉換一個類的同時，會先要求裝載該類的父類以及實現的接口類。

◆loadClass：加載類的入口方法，調用該方法完成類的顯式加載。通過對該方法的重新實現，我們可以完全控制和管理類的加載過程。

◆resolveClass：鏈接一個指定的類。這是一個在某些情況下確保類可用的必要方法，詳見Java語言規范中“執行”一章對該方法的描述。

了解了上面的這些方法，下面我們來實現一個定制的類加載器來完成這樣的加載流程：我們為該類加載器指定一些必須由該類加載器直接加載的類集合，在該類加載器進行類的加載時，如果要加載的類屬于必須由該類加載器加載的集合，那么就由它直接來完成類的加載，否則就把類加載的工作委托給系統的類加載器完成。

在給出示例代碼前，有兩點內容需要說明一下：1、要想實現同一個類的不同版本的共存，那么這些不同版本必須由不同的類加載器進行加載，因此就不能把這些類的加載工作委托給系統加載器來完成，因為它們只有一份。2、為了做到這一點，就不能采用系統默認的類加載器委托規則，也就是說我們定制的類加載器的父加載器必須設置為null。該定制的類加載器的實現代碼如下：

class CustomCL extends ClassLoader {   
 
 private String basedir; // 需要該類加載器直接加載的類文件的基目錄  
    private HashSet dynaclazns; // 需要由該類加載器直接加載的類名  
 
    public CustomCL(String basedir, String[] clazns) {   
        super(null); // 指定父類加載器為 null   
        this.basedir = basedir;   
        dynaclazns = new HashSet();   
        loadClassByMe(clazns);   
    }   
 
    private void loadClassByMe(String[] clazns) {   
        for (int i = 0; i < clazns.length; i++) {   
            loadDirectly(clazns[i]);   
            dynaclazns.add(clazns[i]);   
        }   
    }   
 
    private Class loadDirectly(String name) {   
        Class cls = null;   
        StringBuffer sb = new StringBuffer(basedir);   
        String classname = name.replace('.', File.separatorChar) + ".class";  
        sb.append(File.separator + classname);   
        File classF = new File(sb.toString());   
        cls = instantiateClass(name,new FileInputStream(classF),  
            classF.length());   
        return cls;   
    }       
 
    private Class instantiateClass(String name,InputStream fin,long len){   
        byte[] raw = new byte[(int) len];   
        fin.read(raw);   
        fin.close();   
        return defineClass(name,raw,0,raw.length);   
    }   
      
 protected Class loadClass(String name, boolean resolve)   
            throws ClassNotFoundException {   
        Class cls = null;   
        cls = findLoadedClass(name);   
        if(!this.dynaclazns.contains(name) && cls == null)   
            cls = getSystemClassLoader().loadClass(name);   
        if (cls == null)   
            throw new ClassNotFoundException(name);   
        if (resolve)   
            resolveClass(cls);   
        return cls;   
    }   
 
}  

在該類加載器的實現中，所有指定必須由它直接加載的類都在該加載器實例化時進行了加載，當通過loadClass進行類的加載時，如果該類沒有加載過，并且不屬于必須由該類加載器加載之列都委托給系統加載器進行加載。#p#

實現Java類的熱替換

現在來介紹一下我們的實驗方法，為了簡單起見，我們的包為默認包，沒有層次，并且省去了所有錯誤處理。要替換的類為Foo，實現很簡單，僅包含一個方法sayHello：

public class Foo{   
    public void sayHello() {   
        System.out.println("hello world! (version one)");   
    }   
}  

在當前工作目錄下建立一個新的目錄swap，把編譯好的Foo.class文件放在該目錄中。接下來要使用我們前面編寫的HotswapCL來實現該類的熱替換。具體的做法為：我們編寫一個定時器任務，每隔2秒鐘執行一次。其中，我們會創建新的類加載器實例加載Foo類，生成實例，并調用sayHello方法。接下來，我們會修改Foo類中sayHello方法的打印內容，重新編譯，并在系統運行的情況下替換掉原來的Foo.class，我們會看到系統會打印出更改后的內容。定時任務的實現如下（其它代碼省略，請讀者自行補齊）：

public void run(){   
    try {   
        // 每次都創建出一個新的類加載器  
        HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});   
        Class clcls = cl.loadClass("Foo");   
        Object foo = cls.newInstance();   
 
        Method m = foo.getClass().getMethod("sayHello", new Class[]{});   
        m.invoke(foo, new Object[]{});   
      
    }  catch(Exception ex) {   
        ex.printStackTrace();   
    }   
}  

編譯、運行我們的系統，會出現如下的打印：

圖3.熱替換前的運行結果

好，現在我們把Foo類的sayHello方法更改為：

public void sayHello() {   
    System.out.println("hello world! (version two)");   
}  

在系統仍在運行的情況下，編譯，并替換掉swap目錄下原來的Foo.class文件，我們再看看屏幕的打印，奇妙的事情發生了，新更改的類在線即時生效了，我們已經實現了Foo類的熱替換。屏幕打印如下：

圖4.熱替換后的運行結果

敏銳的讀者可能會問，為何不用把foo轉型為Foo，直接調用其sayHello方法呢？這樣不是更清晰明了嗎？下面我們來解釋一下原因，并給出一種更好的方法。如果我們采用轉型的方法，代碼會變成這樣：Foofoo=(Foo)cls.newInstance();讀者如果跟隨本文進行試驗的話，會發現這句話會拋出ClassCastException異常，為什么嗎？因為在Java中，即使是同一個類文件，如果是由不同的類加載器實例加載的，那么它們的類型是不相同的。在上面的例子中cls是由HowswapCL加載的，而foo變量類型聲名和轉型里的Foo類卻是由run方法所屬的類的加載器（默認為AppClassLoader）加載的，因此是完全不同的類型，所以會拋出轉型異常。

那么通過接口調用是不是就行了呢？我們可以定義一個IFoo接口，其中聲名sayHello方法，Foo實現該接口。也就是這樣：IFoofoo=(IFoo)cls.newInstance();本來該方法也會有同樣的問題的，因為外部聲名和轉型部分的IFoo是由run方法所屬的類加載器加載的，而Foo類定義中implementsIFoo中的IFoo是由HotswapCL加載的，因此屬于不同的類型轉型還是會拋出異常的，但是由于我們在實例化HotswapCL時是這樣的：

HowswapCLcl=newHowswapCL("../swap",newString[]{"Foo"})； 

其中僅僅指定Foo類由HotswapCL加載，而其實現的IFoo接口文件會委托給系統類加載器加載，因此轉型成功，采用接口調用的代碼如下：

public void run(){   
    try {   
        HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});   
        Class clcls = cl.loadClass("Foo");   
        IFoo foo = (IFoo)cls.newInstance();   
        foo.sayHello();   
    } catch(Exception ex) {   
        ex.printStackTrace();   
    }   
}  

確實，簡潔明了了很多，在我們的實驗中，每當定時器調度到run方法時，我們都會創建一個新的HotswapCL實例，在產品代碼中，無需如此，僅當需要升級替換時才去創建一個新的類加載器實例。 #p#

在線升級系統的設計原則

在上小節中，我們給出了一個Java類熱替換的實例，掌握了這項技術，就具備了實現在線升級系統的基礎。但是，對于一個真正的產品系統來說，升級本省就是一項非常復雜的工程，如果要在線升級，就會更加復雜。其中，實現類的熱替換只是最后一步操作，在線升級的要求會對系統的整體設計帶來深遠的影響。下面我們來談談在線升級系統設計方面的一些原則：

◆在系統設計一開始，就要考慮系統的哪些部分是需要以后在線升級的，哪些部分是穩定的

雖然我們可以把系統設計成任何一部分都是可以在線升級的，但是其成本是非常高昂的，也沒有必要。因此，明確地界定出系統以后需要在線升級的部分是明智之舉。這些部分常常是系統業務邏輯規則、算法等等。

◆設計出規范一致的系統狀態轉換方法

替換一個類僅僅是在線升級系統所要做的工作中的一個步驟，為了使系統能夠在升級后正常運行，就必須保持升級前后系統狀態的一致性。因此，在設計時要考慮需要在線升級的部分所涉及的系統狀態有哪些，把這些狀態設計成便于獲取、設置和轉換的，并用一致的方式來進行。

◆明確出系統的升級控制協議

這個原則是關于系統在線升級的時機和流程控制的，不考慮系統的當前運行狀態就貿然進行升級是一項非常危險的活動。因此在系統設計中，就要考慮并預留出系統在線升級的控制點，并定義清晰、明確的升級協議來協調、控制多個升級實體的升級次序，以確保系統在升級的任何時刻都處在一個確定的狀態下。

◆考慮到升級失敗時的回退機制

即使我們做了非常縝密細致的設計，還是難以從根本上保證系統升級一定是成功的，對于大型分布式系統來說尤其如此。因此在系統設計時，要考慮升級失敗后的回退機制。

在線升級系統實例

首先，我們來簡單介紹一下這個實例的結構組成和要完成的工作。在我們的例子中，主要有三個實體，一個是升級控制實體，兩個是工作實體，都基于ActiveObject實現，通過命令消息進行通信（關于ActiveObject的詳細信息，可以參見作者的另外一篇文章“構建Java并發模型框架”）。

升級控制實體以RMI的方式對外提供了一個管理命令接口，用以接收外部的在線升級命令。工作實體有兩個消息隊列，一個用以接收分配給它的任務（我們用定時器定時給它發送任務命令消息），我們稱其為任務隊列；另一個用于和升級控制實體交互，協作完成升級過程，我們稱其為控制隊列。工作實體中的任務很簡單，就是使用我們前面介紹的Foo類簡單地打印出一個字符串，不過這次字符串作為狀態保存在工作實體中，動態設置給Foo類的實例的。升級的協議流程如下：

當升級控制實體接收到來自RMI的在線升級命令時，它會向兩個工作實體的任務隊列中發送一條準備升級消息，然后等待回應。當工作實體在任務隊列中收到準備升級消息時，會立即給升級控制實體發送一條準備就緒消息，然后切換到控制隊列等待進一步的升級指令。升級控制實體收齊這兩個工作實體發來的準備就緒消息后，就給這兩個工作實體的控制隊列各發送一條開始升級消息，然后等待結果。工作實體收到開始升級消息后，進行實際的升級工作，也就是我們前面講述的熱替換類。然后，給升級控制實體發送升級完畢消息。升級控制實體收到來自兩個工作實體的升級完畢消息后，會給這兩個工作實體的控制隊列各發送一條繼續工作消息，工作實體收到繼續工作消息后，切換到任務隊列繼續工作，升級過程結束。主要的代碼片段如下（略去命令消息的定義和執行細節）：

// 升級控制實體關鍵代碼  
class UpgradeController extends ActiveObject{   
    int nready  = 0;   
    int nfinished = 0;   
    Worker[] workers;   
    ......   
    // 收到外部升級命令消息時，會觸發該方法被調用  
    public void askForUpgrade() {   
        for(int i=0; i<workers.length; i++)   
            workers[i].getTaskQueue().enqueue(new PrepareUpgradeCmd(workers[i]));  
    }   
 
    // 收到工作實體回應的準備就緒命令消息時，會觸發該方法被調用  
    public void readyForUpgrade(String worker_name) {   
        nready++;          
        if(nready == workers.length){   
            for(int i=0; i<workers.length; i++)   
                workers[i].getControlQueue().enqueue(new   
                    StartUpgradeCmd(workers[i]));   
        }        
    }   
 
    // 收到工作實體回應的升級完畢命令消息時，會觸發該方法被調用  
    public void finishUpgrade(String worker_name) {   
        nfinished++;   
        if(nfinished == workers.length){   
            for(int i=0; i<workers.length; i++)   
                workers[i].getControlQueue().enqueue(new   
                    ContineWorkCmd(workers[i]));   
 
        }   
    }   
      
    ......   
 
}   
 
// 工作實體關鍵代碼  
class Worker extends ActiveObject{   
    UpgradeController ugc;   
    HotswapCL hscl;   
    IFoo foo;   
    String state = "hello world!";   
      
    ......   
     
    // 收到升級控制實體的準備升級命令消息時，會觸發該方法被調用  
    public void prepareUpgrade() {   
        switchToControlQueue();   
        ugc.getMsgQueue().enqueue(new ReadyForUpdateCMD(ugc,this));   
    }   
 
    // 收到升級控制實體的開始升級命令消息時，會觸發該方法被調用  
    public void startUpgrade(String worker_name) {   
        doUpgrade();   
        ugc.getMsgQueue().enqueue(new FinishUpgradeCMD(ugc,this));   
    }   
 
    // 收到升級控制實體的繼續工作命令消息時，會觸發該方法被調用  
    public void continueWork(String worker_name) {   
        switchToTaskQueue();   
    }   
 
    // 收到定時命令消息時，會觸發該方法被調用  
    public void doWork() {   
        foo.sayHello();      
    }   
 
    // 實際升級動作  
    private void doUpgrade() {   
        hscl = new HowswapCL("../swap", new String[]{"Foo"});   
        Class cls = hscl.loadClass("Foo");   
        foo = (IFoo)cls.newInstance();   
        foo.SetState(state);   
    }   
}   
 
//IFoo 接口定義  
interface IFoo {   
    void SetState(String);   
    void sayHello();   
}  

在Foo類第一個版本的實現中，只是把設置進來的字符串直接打印出來。在第二個版本中，會先把設置進來的字符串變為大寫，然后打印出來。例子很簡單，旨在表達規則或者算法方面的升級變化。另外，我們并沒有提及諸如：消息超時、升級失敗等方面的異常情況，這在實際產品開發中是必須要考慮的。

【編輯推薦】

1. 在Java類中靈活使用Static關鍵字
2. Java類中域和方法設置中的常見錯誤
3. 使用XML通過Java類定義Web服務
4. Java教程 Java類中的各種數據
5. Java教程 Java類中的包