Java程式類載入完全揭密

類載入是java語言提供的最強大的機制之一。儘管類載入並不是討論的熱點話題，但所有的編程人員都應該瞭解其工作機制，明白如何做才能讓其滿足我們的需要。這能有效節省我們的編碼時間，從不斷調試ClassNotFoundException, ClassCastException的工作中解脫出來。 

　　這篇文章從基礎講起，比如代碼與資料的不同之處是什麼，他們是如何構成一個執行個體或對象的。然後深入探討java虛擬機器（JVM）是如何利用類載入器讀取代碼，以及java中類載入器的主要類型。接著用一個類載入的基本演算法看一下類載入器如何載入一個內部類。本文的下一節示範一段代碼來說明擴充和開發屬於自己的類載入器的必要性。緊接著解釋如何使用定製的類載入器來完成一個一般意義上的任務，使其可以載入任意遠端客戶的代碼，在JVM中定義，執行個體化並執行它。本文包括了J2EE關於類載入的規範??事實上這已經成為了J2EE的標準之一。

　　類與資料

　　一個類代表要執行的代碼，而資料則表示其相關狀態。狀態時常改變，而代碼則不會。當我們將一個特定的狀態與一個類相對應起來，也就意味著將一個類案例化。儘管相同的類對應的執行個體其狀態千差萬別，但其本質都對應著同一段代碼。在JAVA中，一個類通常有著一個.class檔案，但也有例外。在JAVA的運行時環境中（Java runtime），每一個類都有一個以第一類(first-class)的Java對象所表現出現的代碼，其是java.lang.Class的執行個體。我們編譯一個JAVA檔案，編譯器都會嵌入一個public, static, final修飾的類型為java.lang.Class，名稱為class的域變數在其位元組碼檔案中。因為使用了public修飾，我們可以採用如下的形式對其訪問：
java.lang.Class klass = Myclass.class;

　　一旦一個類被載入JVM中，同一個類就不會被再次載入了（切記，同一個類）。這裡存在一個問題就是什麼是“同一個類”？正如一個對象有一個具體的狀態，即標識，一個對象始終和其代碼(類)相關聯。同理，載入JVM的類也有一個具體的標識，我們接下來看。

　　在Java中，一個類用其完全符合類名(fully qualified class name)作為標識，這裡指的完全符合類名包括包名和類名。但在JVM中一個類用其全名和一個載入類ClassLoader的執行個體作為唯一標識。因此，如果一個名為Pg的包中，有一個名為Cl的類，被類載入器KlassLoader的一個執行個體kl1載入，Cl的執行個體，即C1.class在JVM中表示為(Cl, Pg, kl1)。這意味著兩個類載入器的執行個體(Cl, Pg, kl1) 和 (Cl, Pg, kl2)是不同的，被它們所載入的類也因此完全不同，互不相容的。那麼在JVM中到底有多少種類載入器的執行個體？下一節我們揭示答案。

　　類載入器

　　在JVM中，每一個類都被java.lang.ClassLoader的一些執行個體來載入.類ClassLoader是在包中java.lang裡，開發人員可以自由地繼承它並添加自己的功能來載入類。

　　無論何時我們鍵入java MyMainClass來開始運行一個新的JVM，“引導類載入器(bootstrap class loader)”負責將一些關鍵的Java類，如java.lang.Object和其他一些運行時代碼先載入進記憶體中。運行時的類在JRE/lib/rt.jar包檔案中。因為這屬於系統底層執行動作，我們無法在JAVA文檔中找到引導類載入器的工作細節。基於同樣的原因，引導類載入器的行為在各JVM之間也是大相徑庭。
同理，如果我們按照如下方式：
log(java.lang.String.class.getClassLoader());

　　來擷取java的核心運行時類的載入器，就會得到null。

　　接下來介紹java的擴充類載入器。擴充庫提供比java運行代碼更多的特性，我們可以把擴充庫儲存在由java.ext.dirs屬性提供的路徑中。

　　(編輯註：java.ext.dirs屬性指的是系統屬性下的一個key，所有的系統屬性可以通過System.getProperties()方法獲得。在編者的系統中，java.ext.dirs的value是” C:/Program Files/Java/jdk1.5.0_04/jre/lib/ext”。下面將要談到的如java.class.path也同屬系統屬性的一個key。)

　　類ExtClassLoader專門用來載入所有java.ext.dirs下的.jar檔案。開發人員可以通過把自己的.jar檔案或庫檔案加入到擴充目錄的classpath，使其可以被擴充類載入器讀取。

　　從開發人員的角度，第三種同樣也是最重要的一種類載入器是AppClassLoader。這種類載入器用來讀取所有的對應在java.class.path系統屬性的路徑下的類。

　　Sun的java指南中，文章“理解擴充類載入”（Understanding Extension Class Loading）對以上三個類載入器路徑有更詳盡的解釋，這是其他幾個JDK中的類載入器

　　●java.net.URLClassLoader 

　　●java.security.SecureClassLoader 

　　●java.rmi.server.RMIClassLoader 

　　●sun.applet.AppletClassLoader 

　　java.lang.Thread，包含了public ClassLoader getContextClassLoader()方法，這一方法返回針對一具體線程的上下文環境類載入器。此類載入器由線程的建立者提供，以供此線程中啟動並執行代碼在需要載入類或資源時使用。如果此載入器未被建立，預設是其父線程的上下文類載入器。原始的類載入器一般由讀取應用程式的類載入器建立。
類載入器如何工作？

　　除了引導類載入器，所有的類載入器都有一個父類載入器，不僅如此，所有的類載入器也都是java.lang.ClassLoader類型。以上兩種類載入器是不同的，而且對於開發人員自訂製的類載入器的正常運行也至關重要。最重要的方面是正確設定父類載入器。任何類載入器，其父類載入器是載入該類載入器的類載入器執行個體。（記住，類載入器本身也是一個類！）

　　使用loadClass()方法可以從類載入器中獲得該類。我們可以通過java.lang.ClassLoader的原始碼來瞭解該方法工作的細節，如下：
protected synchronized Class<?> loadClass (String name, boolean resolve) throws ClassNotFoundException{　// First check if the class is already loaded 　Class c = findLoadedClass(name); 　if (c == null) 　{　　try 　　{　　　if (parent != null)　　　{　　　　c = parent.loadClass(name, false);　　　} else {　　　　c = findBootstrapClass0(name);　　　}　　} catch (ClassNotFoundException e) { 　　　// If still not found, then invoke // findClass to find the class. 　　　c = findClass(name);　　}　}　if (resolve) 　{　　resolveClass(c);　}　return c;}

　　我們可以使用ClassLoader的兩種構造方法來設定父類載入器：
public class MyClassLoader extends ClassLoader{　public MyClassLoader()　{　　super(MyClassLoader.class.getClassLoader());　}}

　　或
public class MyClassLoader extends ClassLoader{　public MyClassLoader()　{　　super(getClass().getClassLoader());　}}

　　第一種方式較為常用，因為通常不建議在構造方法裡調用getClass()方法，因為對象的初始化只是在構造方法的出口處才完全完成。因此，如果父類載入器被正確建立，當要示從一個類載入器的執行個體獲得一個類時，如果它不能找到這個類，它應該首先去訪問其父類。如果父類不能找到它(即其父類也不能找不這個類，等等)，而且如果findBootstrapClass0()方法也失敗了，則調用findClass()方法。findClass()方法的預設實現會拋出ClassNotFoundException，當它們繼承java.lang.ClassLoader來訂製類載入器時開發人員需要實現這個方法。findClass()的預設實現方式如下：
protected Class<?> findClass(String name) throws ClassNotFoundException { throw new ClassNotFoundException(name); }

　　在findClass()方法內部，類載入器需要擷取任意來源的位元組碼。來源可以是檔案系統，URL，資料庫，可以產生位元組碼的另一個應用程式，及其他類似的可以產生java規範的位元組碼的來源。你甚至可以使用BCEL (Byte Code Engineering Library：位元組碼工程庫)，它提供了運行時建立類的捷徑。BCEL已經被成功地使用在以下方面：編譯器，最佳化器，混淆器，代碼產生器及其他分析工具。一旦位元組碼被檢索，此方法就會調用defineClass()方法，此行為對不同的類載入執行個體是有差異的。因此，如果兩個類載入執行個體從同一個來源定義一個類，所定義的結果是不同的。

　　JAVA語言規範（Java language specification）詳細解釋了JAVA執行引擎中的類或介面的載入（loading），連結（linking）或初始化（initialization）過程。

　　圖一顯示了一個主類稱為MyMainClass的應用程式。依照之前的闡述，MyMainClass.class會被AppClassLoader載入。 MyMainClass建立了兩個類載入器的執行個體：CustomClassLoader1 和 CustomClassLoader2,他們可以從某資料來源（比如網路）擷取名為Target的位元組碼。這表示類Target的類定義不在應用程式類路徑或擴充類路徑。在這種情況下，如果MyMainClass想要用自訂的類載入器載入Target類，CustomClassLoader1和CustomClassLoader2會分別獨立地載入並定義Target.class類。這在java中有重要的意義。如果Target類有一些靜態初始化代碼，並且假設我們只希望這些代碼在JVM中只執行一次，而這些代碼在我們目前的步驟中會執行兩次??分別被不同的CustomClassLoaders載入並執行。如果類Target被兩個CustomClassLoaders載入並建立兩個執行個體Target1和Target2，一顯示，它們不是類型相容的。換句話說，在JVM中無法執行以下代碼：
Target target3 = (Target) target2;

　　以上代碼會拋出一個ClassCastException。這是因為JVM把他們視為分別不同的類，因為他們被不同的類載入器所定義。這種情況當我們不是使用兩個不同的類載入器CustomClassLoader1 和 CustomClassLoader2，而是使用同一個類載入器CustomClassLoader的不同執行個體時，也會出現同樣的錯誤。這些會在本文後邊用具體代碼說明。
 圖1. 在同一個JVM中多個類載入器載入同一個目標類

為什麼我們需要我們自己的類載入器

　　原因之一為開發人員寫自己的類載入器來控制JVM中的類載入行為，java中的類靠其包名和類名來標識，對於實現了java.io.Serializable介面的類，serialVersionUID扮演了一個標識類版本的重要角色。這個唯一標識是一個類名、介面名、成員方法及屬性等組成的一個64位的雜湊欄位，而且也沒有其他快捷的方式來標識一個類的版本。嚴格說來，如果以上的都匹配，那麼則屬於同一個類。

　　但是讓我們思考如下情況：我們需要開發一個通用的執行引擎。可以執行實現某一特定介面的任何任務。當任務被提交到這個引擎，首先需要載入這個任務的代碼。假設不同的客戶對此引擎提交了不同的任務，湊巧，這些所有的任務都有一個相同的類名和包名。現在面臨的問題就是這個引擎是否可以針對不同的使用者所提交的資訊而做出不同的反應。這一情況在下文的參考一節有可供下載的代碼範例，samepath 和 differentversions，這兩個目錄分別示範了這一概念。 圖2 顯示了檔案目錄結構，有三個子目錄samepath, differentversions, 和 differentversionspush，裡邊是例子：
 圖2. 檔案夾結構組織樣本

　　在samepath 中，類version.Version儲存在v1和v2兩個子目錄裡，兩個類具有同樣的類名和包名，唯一不同的是下邊這行：
public void fx(){ log("this = " + this + "; Version.fx(1)."); }

　　V1中，日誌記錄中有Version.fx(1)，而在v2中則是Version.fx(2)。把這個兩個存在細微不同的類放在一個classpath下，然後運行Test類：
set CLASSPATH=.;%CURRENT_ROOT%/v1;%CURRENT_ROOT%/v2%JAVA_HOME%/bin/java Test

　　圖3顯示了控制台輸出。我們可以看到對應著Version.fx(1)的代碼被執行了，因為類載入器在classpath首先看到此版本的代碼。
 圖3. 在類路徑中samepath測試排在最前面的version 1

　　再次運行，類路徑做如下微小改動。 
set CLASSPATH=.;%CURRENT_ROOT%/v2;%CURRENT_ROOT%/v1%JAVA_HOME%/bin/java Test

　　控制台的輸出變為圖4。對應著Version.fx(2)的代碼被載入，因為類載入器在classpath中首先找到它的路徑。
 圖4. 在類路徑中samepath測試排在最前面的version 2

　　根據以上例子可以很明顯地看出，類載入器載入在類路徑中被首先找到的元素。如果我們在v1和v2中刪除了version.Version，做一個非version.Version形式的.jar檔案，如myextension.jar，把它放到對應java.ext.dirs的路徑下，再次執行後看到version.Version不再被AppClassLoader載入，而是被擴充類載入器載入。5所示。
 圖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執行一次，這個單一的代碼版本在服務端多次產生了許多執行個體，並執行任務。
 圖6. 執行引擎伺服器控制台

　　圖6顯示了服務端的控制台，載入並執行兩個不同的用戶端的請求，7、8所示。需要注意的是，代碼只被載入了一次（從靜態初始化塊的日誌中也可以明顯看出），但對於用戶端的調用這個方法被執行了兩次。
 圖7. 執行引擎用戶端 1控制台　

　　圖7中，用戶端VM載入了含有client.TaskImpl.class.getClassLoader(v1)的日誌內容的類TaskImpl的代碼，並提供給服務端的執行引擎。圖8的用戶端VM載入了另一個TaskImpl的代碼，並發送給服務端。
 圖8. 執行引擎用戶端 2控制台　

　　在用戶端的VM中，類client.TaskImpl被分別載入，初始化，並發送到服務端執行。圖6還揭示了client.TaskImpl的代碼只在服務端的VM中載入了一次，但這“唯一的一次”卻在服務端創造了許多執行個體並執行。或許用戶端1該不高興了因為並不是它的client.TaskImpl(v1)的方法調用被服務端執行了，而是其他的一些代碼。如何解決這一問題？答案就是實現定製的類載入器。

定製類載入器

　　要較好地控制類的載入，就要實現定製的類載入器。所有自訂的類載入器都應繼承自java.lang.ClassLoader。而且在構造方法中，我們也應該設定父類載入器。然後重寫findClass()方法。differentversionspush檔案夾包含了一個叫做FileSystemClassLoader的自訂製的類載入器。其結構9所示。
 圖9. 定製類載入器關係

　　以下是在common.FileSystemClassLoader實現的主方法：
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();　}}

　　這個類供用戶端把client.TaskImpl(v1)轉換成位元組數組，之後此位元組數組被發送到RMI服務端。在服務端，一個同樣的類用來把位元組數組的內容轉換回代碼。用戶端代碼如下：
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);}}

　　在執行引擎中，從用戶端收到的代碼被送到定製的類載入器中。定製的類載入器把其從位元組數組定義成類，執行個體化並執行。需要指出的是，對每一個客戶請求，我們用類FileSystemClassLoader的不同執行個體來定義用戶端提交的client.TaskImpl。而且，client.TaskImpl並不在服務端的類路徑中。這也就意味著當我們在FileSystemClassLoader調用findClass()方法時，findClass()調用內在的defineClass()方法。類client.TaskImpl被特定的類載入器執行個體所定義。因此，當FileSystemClassLoader的一個新的執行個體被使用，類又被重新定義為位元組數組。因此，對每個用戶端請求類client.TaskImpl被多次定義，我們就可以在相同執行引擎JVM中執行不同的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檔案夾下。服務端和用戶端的控制台介面分別10，11，12所示：
 圖10. 定製類載入器執行引擎

　　圖10顯示的是定製的類載入器控制台。我們可以看到client.TaskImpl的代碼被多次載入。實際上針對每一個用戶端，類都被載入並初始化。
 圖11. 定製類載入器，用戶端1

　　圖11中，含有client.TaskImpl.class.getClassLoader(v1)的日誌記錄的類TaskImpl的代碼被用戶端的VM載入，然後送到服務端。圖12 另一個用戶端把包含有client.TaskImpl.class.getClassLoader(v1)的類代碼載入並送往服務端。
 圖12. 定製類載入器，用戶端1

　　這段代碼示範了我們如何利用不同的類載入器執行個體來在同一個VM上執行不同版本的代碼。

　　J2EE的類載入器

　　J2EE的伺服器傾向於以一定間隔頻率，丟棄原有的類並重新載入新的類。在某些情況下會這樣執行，而有些情況則不。同樣，對於一個web伺服器如果要丟棄一個servlet執行個體，可能是伺服器管理員的手動操作，也可能是此執行個體長時間未相應。當一個JSP頁面被首次請求，容器會把此JSP頁面翻譯成一個具有特定形式的servlet代碼。一旦servlet代碼被建立，容器就會把這個servlet翻譯成class檔案等待被使用。對於提交給容器的每次請求，容器都會首先檢查這個JSP檔案是否剛被修改過。是的話就重新翻譯此檔案，這可以確保每次的請求都是及時更新的。企業級的部署方案以.ear, .war, .rar等形式的檔案，同樣需要重複載入，可能是隨意的也可能是依照某種配置方案定期執行。對所有的這些情況??類的載入、卸載、重新載入……全部都是建立在我們控制應用伺服器的類載入機制的基礎上的。實現這些需要擴充的類載入器，它可以執行由其自身所定義的類。Brett Peterson已經在他的文章 Understanding J2EE Application Server Class Loading Architectures給出了J2EE應用伺服器的類載入方案的詳細說明，詳見網站TheServerSide.com。

　　結束語

　　本文探討了類載入到虛擬機器是如何進行唯一標識的，以及類如果存在同樣的類名和包名時所產生的問題。因為沒有一個直接可用的類版本管理機制，所以如果我們要按自己的意願來載入類時，需要自己訂製類載入器來擴充其行為。我們可以利用許多J2EE伺服器所提供的“熱部署”功能來重新載入一個新版本的類，而不改動伺服器的VM。即使不涉及應用伺服器，我們也可以利用定製類載入器來控制java應用程式載入類時的具體行為。Ted Neward的書Server-Based Java Programming中詳細闡述java的類載入，J2EE的API以及使用他們的最佳途徑。

原文地址:
http://www.matrix.org.cn/resource/article/43/43875_Class_Loading.html