<rt id="bn8ez"></rt>
<label id="bn8ez"></label>

  • <span id="bn8ez"></span>

    <label id="bn8ez"><meter id="bn8ez"></meter></label>

    憨厚生

    ----Java's Slave----
    ***Java's Host***

      BlogJava :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理 ::
      165 隨筆 :: 17 文章 :: 90 評論 :: 0 Trackbacks
    本文是一篇譯文。原文:Find a way out of the ClassLoader maze

    對于類加載器,普通Java應用開發人員不需要了解太多。但對于系統開發人員,正確理解Java的類加載器模型是開發Java系統軟件的關鍵。很久以來,我一直對ClassLoader許多問題感到很模糊,自己也在一直探討ClassLoader的機制,但苦于Java這方面的文檔太少,許多東西都是自己學習JDK源碼和看開源系統應用項目的代碼總結出來,很不清晰。前不久在幫朋友做那個企業應用平臺時,對這方面的知識深入研究和學習了一下,遇到的最好的文檔就是這篇文章了。在這兒翻譯出來,與希望寫系統代碼的朋友分享。

    原文太長,分篇譯出。喜歡看原文的朋友不妨直接閱讀原文。

    問題:何時使用Thread.getContextClassLoader()?

    這是一個很常見的問題,但答案卻很難回答。這個問題通常在需要動態加載類和資源的系統編程時會遇到。總的說來動態加載資源時,往往需要從三種類加載器里選擇:系統或說程序的類加載器、當前類加載器、以及當前線程的上下文類加載器。在程序中應該使用何種類加載器呢?

    系統類加載器通常不會使用。此類加載器處理啟動應用程序時classpath指定的類,可以通過ClassLoader.getSystemClassLoader()來獲得。所有的ClassLoader.getSystemXXX()接口也是通過這個類加載器加載的。一般不要顯式調用這些方法,應該讓其他類加載器代理到系統類加載器上。由于系統類加載器是JVM最后創建的類加載器,這樣代碼只會適應于簡單命令行啟動的程序。一旦代碼移植到EJB、Web應用或者Java Web Start應用程序中,程序肯定不能正確執行。

    因此一般只有兩種選擇,當前類加載器和線程上下文類加載器。當前類加載器是指當前方法所在類的加載器。這個類加載器是運行時類解析使用的加載器,Class.forName(String)和Class.getResource(String)也使用該類加載器。代碼中X.class的寫法使用的類加載器也是這個類加載器。

    線程上下文類加載器在Java 2(J2SE)時引入。每個線程都有一個關聯的上下文類加載器。如果你使用new Thread()方式生成新的線程,新線程將繼承其父線程的上下文類加載器。如果程序對線程上下文類加載器沒有任何改動的話,程序中所有的線程將都使用系統類加載器作為上下文類加載器。Web應用和Java企業級應用中,應用服務器經常要使用復雜的類加載器結構來實現JNDI(Java命名和目錄接口)、線程池、組件熱部署等功能,因此理解這一點尤其重要。

    為什么要引入線程的上下文類加載器?將它引入J2SE并不是純粹的噱頭,由于Sun沒有提供充分的文檔解釋說明這一點,這使許多開發者很糊涂。實際上,上下文類加載器為同樣在J2SE中引入的類加載代理機制提供了后門。通常JVM中的類加載器是按照層次結構組織的,目的是每個類加載器(除了啟動整個JVM的原初類加載器)都有一個父類加載器。當類加載請求到來時,類加載器通常首先將請求代理給父類加載器。只有當父類加載器失敗后,它才試圖按照自己的算法查找并定義當前類。

    有時這種模式并不能總是奏效。這通常發生在JVM核心代碼必須動態加載由應用程序動態提供的資源時。拿JNDI為例,它的核心是由JRE核心類(rt.jar)實現的。但這些核心JNDI類必須能加載由第三方廠商提供的JNDI實現。這種情況下調用父類加載器(原初類加載器)來加載只有其子類加載器可見的類,這種代理機制就會失效。解決辦法就是讓核心JNDI類使用線程上下文類加載器,從而有效的打通類加載器層次結構,逆著代理機制的方向使用類加載器。

    順便提一下,XML解析API(JAXP)也是使用此種機制。當JAXP還是J2SE擴展時,XML解析器使用當前累加載器方法來加載解析器實現。但當JAXP成為J2SE核心代碼后,類加載機制就換成了使用線程上下文加載器,這和JNDI的原因相似。

    好了,現在我們明白了問題的關鍵:這兩種選擇不可能適應所有情況。一些人認為線程上下文類加載器應成為新的標準。但這在不同JVM線程共享數據來溝通時,就會使類加載器的結構亂七八糟。除非所有線程都使用同一個上下文類加載器。而且,使用當前類加載器已成為缺省規則,它們廣泛應用在類聲明、Class.forName等情景中。即使你想盡可能只使用上下文類加載器,總是有這樣那樣的代碼不是你所能控制的。這些代碼都使用代理到當前類加載器的模式。混雜使用代理模式是很危險的。

    更為糟糕的是,某些應用服務器將當前類加載器和上下文類加器分別設置成不同的ClassLoader實例。雖然它們擁有相同的類路徑,但是它們之間并不存在父子代理關系。想想這為什么可怕:記住加載并定義某個類的類加載器是虛擬機內部標識該類的組成部分,如果當前類加載器加載類X并接著執行它,如JNDI查找類型為Y的數據,上下文類加載器能夠加載并定義Y,這個Y的定義和當前類加載器加載的相同名稱的類就不是同一個,使用隱式類型轉換就會造成異常。

    這種混亂的狀況還將在Java中存在很長時間。在J2SE中還包括以下的功能使用不同的類加載器:

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

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

    * JAXP使用上下文類加載器

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

    * URL協議處理器使用java.protocol.handler.pkgs系統屬性并只使用系統類加載器。

    * Java序列化API缺省使用調用者當前的類加載器

    這些類加載器非常混亂,沒有在J2SE文檔中給以清晰明確的說明。

    posted on 2007-04-24 20:39 二胡 閱讀(261) 評論(0)  編輯  收藏 所屬分類: Java
    主站蜘蛛池模板: 国产yw855.c免费视频| 亚洲中文字幕乱码一区| 亚洲理论片中文字幕电影| 亚洲中文无码卡通动漫野外| 免费看黄福利app导航看一下黄色录像| 国内自产拍自a免费毛片| 亚洲中久无码永久在线观看同| 久久综合九九亚洲一区| 色窝窝亚洲av网| 免费精品国产自产拍在线观看图片| 蜜桃精品免费久久久久影院| 亚洲福利在线观看| 久久亚洲精品国产精品| 一级人做人爰a全过程免费视频 | 国产免费爽爽视频在线观看| 四虎永久在线精品免费观看地址 | 免费看美女午夜大片| 免费无码肉片在线观看| 中文字幕一精品亚洲无线一区| 亚洲精品久久无码| 久久国产免费观看精品3| 国产大片91精品免费看3| 97se亚洲国产综合自在线| 免费无码中文字幕A级毛片| 337p日本欧洲亚洲大胆裸体艺术 | 1区1区3区4区产品亚洲| 日韩av无码久久精品免费| 国产亚洲成av片在线观看| 丰满妇女做a级毛片免费观看| 四虎永久在线精品免费影视| 亚洲国产成人手机在线观看| 18禁美女裸体免费网站| 亚洲精品视频专区| 午夜男人一级毛片免费| 国产亚洲人成在线播放| 免费人成在线观看视频播放| 久久亚洲精品无码gv| 亚洲欧洲日产国码一级毛片| 阿v视频免费在线观看| 四虎国产精品免费久久| 亚洲宅男天堂a在线|