另類 app 類庫 .com 任務 發現 clas context 表示

預定義類加載器和雙親委派機制

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類加載雙親委派機制的思考（附一道面試題）