Jhonney的專欄

1.   系統類加載器或叫作應用類加載器 (system classloader or application classloader)
2.  當前類加載器
3.  當前線程類加載器

上面的問題指的是最后一種類加載器 . 哪種類加載器是正確的選擇呢 ?

第一種選擇可以很容易地排除 : 系統類加載器 (system classloader). 這個類加載器處理 -classpath 下的類加載工作 , 可以通過 ClassLoader.getSystemClassLoader() 方法調用 . ClassLoader 下所有的 getSystemXXX() 的靜態方法都是通過這個方法定義的 . 在你的代碼中 , 你應該盡量少地調用這個方法 , 以其它的類加載器作為代理 . 否則你的代碼將只能工作在簡單的命令行應用中 , 這個時候系統類加載器 (system classloader) 是 JVM 最后創建的類加載器 . 一但你把代碼移到 EJB, Web 應用或 Java Web Start 應用中 , 一定會出問題 .

      所以我們來看第二種選擇 : 當前上下文環境下的類加載器 . 根據定義 , 當前類加載器就是你當前方法所屬的類的加載器 . 在運行時類之間動態聯編 , 及調用 Class.forName,() Class.getResource() 等類似方法時 , 這個類加載器會被隱含地使用 . It is also used by syntactic constructs like X.class class literals.

    線程上下文類型加載器是在Java 2平臺上被引入的. 每一個線程都有一個類加載器與之對應(除非這個線程是被本地代碼創建的). 這個類加載器是通過Thread.setContextClassLoaser()方法設置的. 如果你不在線程構造后調用這個方法, 這個線程將從它的父線程中繼承相應的上下文類加載器. 如果在整個應用中你不做任何特殊設置, 所有的線程將都以系統類加載器(system classloader)作為自己的線程上下文類加載器. 自從Web和J2EE應用服務器使用成熟的類加載器機制來實現諸如JNDI, 線程池, 組件熱部署等功能以來, 這種在整個應用中不做任何線程類加載器設置的情況就很少了.

    為什么線程上下文類加載器存在于如此重要的位置呢? 這個概念在J2SE中的引入并不引人注目. 很多開發人員對這一概念迷惑的原因是Sun公司在這方面缺乏適當的指引和文檔.

    事實上, 上下文類加載器提供了類加載機制的后門, 這一點也在J2SE中被引入了. 通常, 在JVM中的所有類加載器被組織成了有繼承層次的結構, 每一個類加載器(除了引導JVM的原始類加載器)都有一個父加載器. 每當被請示加載類時, 類加載器都會首先請求其父類加載器, 只有當父類加載器不能加載時, 才會自己進行類加載.

   有時候這種類加載的順序安排不能正常工作, (此 處的意思是:正常情況下都是從子類加載器到根類加載器請求,萬一有根類里需要加載子類時,這種順序就不能滿足要求,就要有一條反向的通道,即得到子類加載 器,這樣就用到了thread context classloader,因為通過thread.getcontextclassloader()可以得到子類加載器).通常當必須動態加載應用程序開發人員提供的資源的時候. 以JNDI為例: 它的內容(從J2SE1.3開始)就在rt.jar中的引導類中實現了, 但是這些JNDI核心類需要動態加載由獨立廠商實現并部署在應用程序的classpath下的JNDI提供者. 這種情況就要求一個父classloader(本例, 就是引導類加載器)去加載對于它其中一個子classloader(本例, 系統類加載器)可見的類. 這時通常的類加載代理機制不能實現這個要求. 解決的辦法(workaround)就是, 讓JNDI核心類使用當前線程上下文的類加載器, 這樣, 就基本的類加載代理機制的相反方向建立了一條有效的途徑.

    另外, 上面一段可能讓你想起一些其它的事情: XML解析Java API(JAXP). 是的, 當JAXP只是J2SE的擴展進, 它很自然地用當前類加載器來引導解析器的實現. 而當JAXP被加入到J2SE1.4的核心類庫中時, 它的類加載也就改成了用當前線程類加載器, 與JNDI的情況完全類似(也使很多程序員很迷惑). 明白為什么我說來自Sun的指導很缺乏了吧?

   在以上的介紹之后, 我們來看關鍵問題: 這兩種選擇(當前類加載器和當前線程類加載器)都不是在所有環境下都適用. 有些人認為當前線程類加載器應該成為新的標準策略. 但是, 如果這樣, 當多個線程通過共享數據進行交互的時, 將會呈現出一幅極其復雜的類加載的畫面, 除非它們全部使用了同一個上下文的類加載器. 進一步說, 在某些遺留下來的解決方案中, 委派到當前類加載器的方法已經是標準. 比如對Class.forName(String)的直接調用(這也是我為什么推薦盡量避免對這個方法進行調用的原因). 即使你努力去只調用上下文相關的類加載器, 仍然會有一些代碼會不由你控制. 這種不受控制的類加載委派機制是混入是很危險的.

    更嚴重的問題, 某些應用服務器把環境上下文及當前類加載器設置到不同的類加載器實例上, 而這些類加載器有相同的類路徑但卻沒有委派機制中的父子關系. 想想這為什么十分可怕. 要知道類加載器定義并加載的類實例會帶有一個JVM內部的ID號. 如果當前類加載器加載一個類X的實例, 這個實例調用JNDI查找類Y的實例, 些時的上下文的類加載器也可以定義了加載類Y實例. 這個類Y的定義就與當前類加載器看到的類Y的定義不同. 如果進行強制類型轉換, 則產生異常.

   這種混亂的情況還將在Java中存在一段時間. 對于那些需要動態加載資源的J2SE的API, 我們來猜想它們的類加策略. 例如:

Ø         JNDI 使用線程上下文類加載器

Ø         Class.getResource() 和Class.forName()使用當前類加載器

Ø         JAXP(J2SE 1.4 及之后)使用線程上下文類加載器

Ø         java.util.ResourceBundle 使用調用者的當前類加載器

Ø         URL protocol handlers specified via java.protocol.handler.pkgs system property are looked up in the bootstrap and system classloaders only

Ø         Java 序列化API默認使用調用者當前的類加載器