您好,登錄后才能下訂單哦!
本篇內容介紹了“Java類加載雙親委派機制是什么”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
JVM預定義的三種類型類加載器:
除了以上列舉的三種類加載器,還有一種比較特殊的類型 — 線程上下文類加載器。
啟動(Bootstrap)類加載器:是用本地代碼實現的類裝入器,它負責將 <Java_Runtime_Home>/lib下面的類庫加載到內存中(比如rt.jar)。由于引導類加載器涉及到虛擬機本地實現細節,開發者無法直接獲取到啟動類加載器的引用,所以不允許直接通過引用進行操作。
標準擴展(Extension)類加載器:是由 Sun 的 ExtClassLoader(sun.misc.Launcher$ExtClassLoader)實現的。它負責將< Java_Runtime_Home >/lib/ext或者由系統變量 java.ext.dir指定位置中的類庫加載到內存中。開發者可以直接使用標準擴展類加載器。
系統(System)類加載器:是由 Sun 的 AppClassLoader(sun.misc.Launcher$AppClassLoader)實現的。它負責將系統類路徑(CLASSPATH)中指定的類庫加載到內存中。開發者可以直接使用系統類加載器。
雙親委派機制描述
某個特定的類加載器在接到加載類的請求時,首先將加載任務委托給父類加載器,依次遞歸,如果父類加載器可以完成類加載任務,就成功返回;只有父類加載器無法完成此加載任務時,才自己去加載。
Java虛擬機的第一個類加載器是Bootstrap,這個加載器很特殊,它不是Java類,因此它不需要被別人加載,它嵌套在Java虛擬機內核里面,也就是JVM啟動的時候Bootstrap就已經啟動,它是用C++寫的二進制代碼(不是字節碼),它可以去加載別的類。
這也是我們在測試時為什么發現System.class.getClassLoader()結果為null的原因,這并不表示System這個類沒有類加載器,而是它的加載器比較特殊,是BootstrapClassLoader,由于它不是Java類,因此獲得它的引用肯定返回null。
委托機制具體含義
當Java虛擬機要加載一個類時,到底派出哪個類加載器去加載呢?
首先當前線程的類加載器去加載線程中的第一個類(假設為類A)。
注:當前線程的類加載器可以通過Thread類的getContextClassLoader()獲得,也可以通過setContextClassLoader()自己設置類加載器。
如果類A中引用了類B,Java虛擬機將使用加載類A的類加載器去加載類B。
還可以直接調用ClassLoader.loadClass()方法來指定某個類加載器去加載某個類。
委托機制的意義 — 防止內存中出現多份同樣的字節碼
比如兩個類A和類B都要加載System類:
如果不用委托而是自己加載自己的,那么類A就會加載一份System字節碼,然后類B又會加載一份System字節碼,這樣內存中就出現了兩份System字節碼。
如果使用委托機制,會遞歸的向父類查找,也就是首選用Bootstrap嘗試加載,如果找不到再向下。這里的System就能在Bootstrap中找到然后加載,如果此時類B也要加載System,也從Bootstrap開始,此時Bootstrap發現已經加載過了System那么直接返回內存中的System即可而不需要重新加載,這樣內存中就只有一份System的字節碼了。
能不能自己寫個類叫java.lang.System?
答案:通常不可以,但可以采取另類方法達到這個需求。
解釋:為了不讓我們寫System類,類加載采用委托機制,這樣可以保證爸爸們優先,爸爸們能找到的類,兒子就沒有機會加載。而System類是Bootstrap加載器加載的,就算自己重寫,也總是使用Java系統提供的System,自己寫的System類根本沒有機會得到加載。
但是,我們可以自己定義一個類加載器來達到這個目的,為了避免雙親委托機制,這個類加載器也必須是特殊的。由于系統自帶的三個類加載器都加載特定目錄下的類,如果我們自己的類加載器放在一個特殊的目錄,那么系統的加載器就無法加載,也就是最終還是由我們自己的加載器加載。
“Java類加載雙親委派機制是什么”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。