關於Java類加載雙親委派機制的思考（附一道面試題）

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

1. 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）中指定的類庫加載到內存中。開發者能夠直接使用系統類加載器。

   除了以上列舉的三種類加載器，還有一種比較特殊的類型 — 線程上下文類加載器。

2. 雙親委派機制描述
   某個特定的類加載器在接到加載類的請求時，首先將加載任務委託給父類加載器，依次遞歸，若是父類加載器能夠完成類加載任務，就成功返回；只有父類加載器沒法完成此加載任務時，才本身去加載。

 

幾點思考

1. Java虛擬機的第一個類加載器是Bootstrap，這個加載器很特殊，它不是Java類，所以它不須要被別人加載，它嵌套在Java虛擬機內核裏面，也就是JVM啓動的時候Bootstrap就已經啓動，它是用C++寫的二進制代碼（不是字節碼），它能夠去加載別的類。

   這也是咱們在測試時爲何發現System.class.getClassLoader()結果爲null的緣由，這並不表示System這個類沒有類加載器，而是它的加載器比較特殊，是BootstrapClassLoader，因爲它不是Java類，所以得到它的引用確定返回null。

2. 委託機制具體含義
   當Java虛擬機要加載一個類時，到底派出哪一個類加載器去加載呢？

   • 首先當前線程的類加載器去加載線程中的第一個類（假設爲類A）。
     注：當前線程的類加載器能夠經過Thread類的getContextClassLoader()得到，也能夠經過setContextClassLoader()本身設置類加載器。
   • 若是類A中引用了類B，Java虛擬機將使用加載類A的類加載器去加載類B。
   • 還能夠直接調用ClassLoader.loadClass()方法來指定某個類加載器去加載某個類。

3. 委託機制的意義 — 防止內存中出現多份一樣的字節碼
   好比兩個類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類根本沒有機會獲得加載。

  可是，咱們能夠本身定義一個類加載器來達到這個目的，爲了不雙親委託機制，這個類加載器也必須是特殊的。因爲系統自帶的三個類加載器都加載特定目錄下的類，若是咱們本身的類加載器放在一個特殊的目錄，那麼系統的加載器就沒法加載，也就是最終仍是由咱們本身的加載器加載。