原文地址：http://www.ibm.com/developerworks/cn/java/j-lo-hotswapcls/index.html
在本文中，我們將不對 Java ClassLoader 的細節進行過於詳細的講解，而是關注於和構建在線升級系統相關的基礎概念。關於 ClassLoader 的詳細細節許多資料可以參考，有興趣的讀者可以自行研讀。
要構建在線升級系統，一個重要的技術就是能夠實現 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 類的既定加載過程，我們需要實現自己的類加載器，並在其中對類的加載過程進行完全的控制和管理。
爲了能夠完全掌控類的加載過程，我們的定製類加載器需要直接從 ClassLoader 繼承。首先我們來介紹一下 ClassLoader 類中和熱替換有關的的一些重要方法。
- findLoadedClass：每個類加載器都維護有自己的一份已加載類名字空間，其中不能出現兩個同名的類。凡是通過該類加載器加載的類，無論是直接的還是間接的，都保存在自己的名字空間中，該方法就是在該名字空間中尋找指定的類是否已存在，如果存在就返回給類的引用，否則就返回 null。這裏的直接是指，存在於該類加載器的加載路徑上並由該加載器完成加載，間接是指，由該類加載器把類的加載工作委託給其他類加載器完成類的實際加載。
- getSystemClassLoader：Java2 中新增的方法。該方法返回系統使用的 ClassLoader。可以在自己定製的類加載器中通過該方法把一部分工作轉交給系統類加載器去處理。
- defineClass：該方法是 ClassLoader 中非常重要的一個方法，它接收以字節數組表示的類字節碼，並把它轉換成 Class 實例，該方法轉換一個類的同時，會先要求裝載該類的父類以及實現的接口類。
- loadClass：加載類的入口方法，調用該方法完成類的顯式加載。通過對該方法的重新實現，我們可以完全控制和管理類的加載過程。
- resolveClass：鏈接一個指定的類。這是一個在某些情況下確保類可用的必要方法，詳見 Java 語言規範中“執行”一章對該方法的描述。
瞭解了上面的這些方法，下面我們來實現一個定製的類加載器來完成這樣的加載流程：我們爲該類加載器指定一些必須由該類加載器直接加載的類集合，在該類加載器進行類的加載時，如果要加載的類屬於必須由該類加載器加載的集合，那麼就由它直接來完成類的加載，否則就把類加載的工作委託給系統的類加載器完成。
在給出示例代碼前，有兩點內容需要說明一下：1、要想實現同一個類的不同版本的共存，那麼這些不同版本必須由不同的類加載器進行加載，因此就不能把這些類的加載工作委託給系統加載器來完成，因爲它們只有一份。2、爲了做到這一點，就不能採用系統默認的類加載器委託規則，也就是說我們定製的類加載器的父加載器必須設置爲 null。該定製的類加載器的實現代碼如下：
清單 1. 定製的類加載器的實現代碼
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 進行類的加載時，如果該類沒有加載過，並且不屬於必須由該類加載器加載之列都委託給系統加載器進行加載。理解了這個實現，距離實現類的熱替換就只有一步之遙了，我們在下一小節對此進行詳細的講解
在本小節中，我們將結合前面講述的類加載器的特性，並在上小節實現的自定義類加載器的基礎上實現 Java 類的熱替換。首先我們把上小節中實現的類加載器的類名 CustomCL 更改爲 HotswapCL，以明確表達我們的意圖。
現在來介紹一下我們的實驗方法，爲了簡單起見，我們的包爲默認包，沒有層次，並且省去了所有錯誤處理。要替換的類爲 Foo，實現很簡單，僅包含一個方法 sayHello：
清單 2. 待替換的示例類
public class Foo{
public void sayHello() {
System.out.println("hello world! (version one)");
}
}
|
在當前工作目錄下建立一個新的目錄 swap，把編譯好的 Foo.class 文件放在該目錄中。接下來要使用我們前面編寫的 HotswapCL 來實現該類的熱替換。具體的做法爲：我們編寫一個定時器任務，每隔 2 秒鐘執行一次。其中，我們會創建新的類加載器實例加載 Foo 類，生成實例，並調用 sayHello 方法。接下來，我們會修改 Foo 類中 sayHello 方法的打印內容，重新編譯，並在系統運行的情況下替換掉原來的 Foo.class，我們會看到系統會打印出更改後的內容。定時任務的實現如下（其它代碼省略，請讀者自行補齊）：
清單 3. 實現定時任務的部分代碼
public void run(){
try {
// 每次都創建出一個新的類加載器
HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});
Class cls = 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 方法呢？這樣不是更清晰明瞭嗎？下面我們來解釋一下原因，並給出一種更好的方法。
如果我們採用轉型的方法，代碼會變成這樣：Foo foo = (Foo)cls.newInstance(); 讀者如果跟隨本文進行試驗的話，會發現這句話會拋出 ClassCastException 異常，爲什麼嗎？因爲在 Java 中，即使是同一個類文件，如果是由不同的類加載器實例加載的，那麼它們的類型是不相同的。在上面的例子中 cls 是由 HowswapCL 加載的，而 foo 變量類型聲名和轉型裏的 Foo 類卻是由
run 方法所屬的類的加載器（默認爲 AppClassLoader）加載的，因此是完全不同的類型，所以會拋出轉型異常。
那麼通過接口調用是不是就行了呢？我們可以定義一個 IFoo 接口，其中聲名 sayHello 方法，Foo 實現該接口。也就是這樣：IFoo foo = (IFoo)cls.newInstance(); 本來該方法也會有同樣的問題的，因爲外部聲名和轉型部分的 IFoo 是由 run 方法所屬的類加載器加載的，而 Foo 類定義中 implements IFoo 中的 IFoo 是由 HotswapCL 加載的，因此屬於不同的類型轉型還是會拋出異常的，但是由於我們在實例化
HotswapCL 時是這樣的：
HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});
其中僅僅指定 Foo 類由 HotswapCL 加載，而其實現的 IFoo 接口文件會委託給系統類加載器加載，因此轉型成功，採用接口調用的代碼如下：
清單 4. 採用接口調用的代碼
public void run(){
try {
HowswapCL cl = new HowswapCL("../swap", new String[]{"Foo"});
Class cls = cl.loadClass("Foo");
IFoo foo = (IFoo)cls.newInstance();
foo.sayHello();
} catch(Exception ex) {
ex.printStackTrace();
}
}
|
確實，簡潔明瞭了很多。在我們的實驗中，每當定時器調度到 run 方法時，我們都會創建一個新的 HotswapCL 實例，在產品代碼中，無需如此，僅當需要升級替換時纔去創建一個新的類加載器實例。
在上小節中，我們給出了一個 Java 類熱替換的實例，掌握了這項技術，就具備了實現在線升級系統的基礎。但是，對於一個真正的產品系統來說，升級本省就是一項非常複雜的工程，如果要在線升級，就會更加複雜。其中，實現類的熱替換隻是最後一步操作，在線升級的要求會對系統的整體設計帶來深遠的影響。下面我們來談談在線升級系統設計方面的一些原則：
-
在系統設計一開始，就要考慮系統的哪些部分是需要以後在線升級的，哪些部分是穩定的。
雖然我們可以把系統設計成任何一部分都是可以在線升級的，但是其成本是非常高昂的，也沒有必要。因此，明確地界定出系統以後需要在線升級的部分是明智之舉。這些部分常常是系統業務邏輯規則、算法等等。
-
設計出規範一致的系統狀態轉換方法。
替換一個類僅僅是在線升級系統所要做的工作中的一個步驟，爲了使系統能夠在升級後正常運行，就必須保持升級前後系統狀態的一致性。因此，在設計時要考慮需要在線升級的部分所涉及的系統狀態有哪些，把這些狀態設計成便於獲取、設置和轉換的，並用一致的方式來進行。
-
明確出系統的升級控制協議。
這個原則是關於系統在線升級的時機和流程控制的，不考慮系統的當前運行狀態就貿然進行升級是一項非常危險的活動。因此在系統設計中， 就要考慮並預留出系統在線升級的控制點， 並定義清晰、明確的升級協議來協調、控制多個升級實體的升級次序，以確保系統在升級的任何時刻都處在一個確定的狀態下。
-
考慮到升級失敗時的回退機制。
即使我們做了非常縝密細緻的設計，還是難以從根本上保證系統升級一定是成功的，對於大型分佈式系統來說尤其如此。因此在系統設計時，要考慮升級失敗後的回退機制。
好了，本小節我們簡單介紹了在線升級系統設計時的幾個重要的原則，下一小節我們將給出一個簡單的實例，來演示一下如何來實現一個在線升級系統。
