JVM的藝術之什么是類加載器

這篇文章主要介紹“JVM的藝術之什么是類加載器”，在日常操作中，相信很多人在JVM的藝術之什么是類加載器問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”JVM的藝術之什么是類加載器”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

什么是定義類加載器和初始化類加載器？

• 定義類加載器：假設我們的某一個類是由ExtClassLoader加載的，那么ExtClassLoader稱為該類的定義類加載器

• 初始化加載器：能夠返回Class對象引用的都叫做該類的初始類加載器，比如類A是由我們的ExtClassLoader加載，那么

  ExtClassLoader是該類的定義類加載器，也是該類的初始類加載器，而我們的AppClassLoader也能返回我們A類的引用

  那么AppClassLoader也是該類的初始類加載器。

什么是類加載器的雙親委派模型？

上篇文章我們提到了類加載器的雙親委派模型，也可以稱為雙親委托模型。今天這篇文章我們就來把這個概念給講明白。

概念：用一種簡單的方式去描述雙親委托的概念。可以分為兩個部分去理解

1委托:

jvm加載類的時候是通過雙親委派的方式去加載，自下而上的去委托。

自定義類加載器需要加載類時，先委托應用類加載器去加載，然后應用類加載器又向擴展類加載器去委托，擴展類加載器在向啟動類加載器去委托。

如果啟動類加載器不能加載該類。那么就向下加載

2加載:

jvm加載類的時候是通過雙親委派的方式去加載委托，但是加載的時候是由上向下去加載的，當委托到最頂層啟動類加載器的時候，無法在向上委托，那么

啟動類加載器就開始嘗試去加載這個類，啟動類加載器加載不了就向下交給擴展類加載器去加載，擴展類加載器加載不了就繼續向下委托交給應用類加載器

去加載，以此類推。

如果文字描述你還不清楚什么是雙親委托機制，那么我畫了一幅圖可以更清楚類加載的過程。如下：

通過上圖，我們知道更能清楚的知道，雙親委托模型的工作機制，用一句簡單的話說，就是需要加載一個類的時候，向上委托，向下加載。

注意：在雙親委派機制中，各個加載器按照父子關系形成樹型結構,除了根加載器以外,每一個加載器有且只有一個父加載器。

接下來，我也從jdk底層源碼的角度給大家畫了一張類加載的主要過程，圖如下：

以上就是類加載器加載一個類的重要過程步驟。希望各位小伙兒可以結合源碼的方式，仔細再研究一下。其實還挺好理解的。

下面咱們再說說，java采用雙親委托的方式去加載類，這樣做的好處是什么呢？

• 雙親委派模型的好處

  總所周知:java.lang.object類是所有類的父類，所以我們程序在運行期間會把java.lang.object類加載到內存中，假如java.lang.object類

  能夠被我們自定義類加載器去加載的話，那么jvm中就會存在多份Object的Class對象，而且這些Class對象是不兼容的。

  所以雙親委派模型可以保證java核心類庫下的類型的安全。

  借助雙親委派模型，我們java核心類庫的類必須是由我們的啟動類加載器加載的，這樣可以確保我們核心類庫只會在jvm中存在一份

  這就不會給自定義類加載器去加載我們核心類庫的類。

  根據我們的演示案例，一個class可以由多個類加載器去加載，同時可以在jvm內存中存在多個不同版本的Class對象，這些對象是不兼容的。

  并且是不能相互轉換的。

什么是全盤委托加載？

解釋:假如我們的Person類是由我們的系統類APP類加載器加載的，而person類所依賴的Dog類也會委托給App系統類進 行加載，這個委托過程也遵循雙親委派模型。代碼如下

person類代碼中創建Dog實例

public class Person {

  public Person(){
  
      new Dog();
  }

}

public class Dog {

    public Dog(){
        System.out.println("Dog 的構造函數");
    }
}

• 測試類

  public class MainClass02 {
  
      public static void main(String[] args) throws Exception {
          //創建自定義類加載器的一個實例，并且通過構造器指定名稱        Test01ClassLoader myClassLoader = new Test01ClassLoader("loader1");
          myClassLoader.setPath("I:\\test\\");
          Class<?> classz = myClassLoader.loadClass("com.test.Person");
          System.out.println(classz.getClassLoader());
          System.out.println(Dog.class.getClassLoader());
      }
  }
  
  
  運行結果：
  
  sun.misc.Launcher$AppClassLoader@18b4aac2
  sun.misc.Launcher$AppClassLoader@18b4aac2
  
  Process finished with exit code 0

  從上面的運行結果，我們可以看出，當我們用自定義類加載器去加載我們的Person的時候，根據雙親委托模型，我們的Person并沒有被自定義類加載（Test01ClassLoader）加載，而是被AppClassloader加載成功，同時根據全盤委托規則，我們的Dog類也被AppClassLoader加載了。所以大家一定要記住這個至關重要的結論。為我們后面的學習打下堅實的基礎。

下面我們再看一個例子。我們把類路徑下的Person.class文件刪除掉，然后再運行一下上面的main函數，看看結果。代碼如下：

通過那行結果我們看出，Person類是由我們的自定義類加載器加載的。那為什么Dog類沒有進行全盤委托的，這是因為雙親委托模型的緣故，我們的類路徑下并沒有Person類，故此AppClassLoader是無法加載我們的路徑I：\\test\\下的com.test.Person.class文件的。所以Person類是由我們自定的類加載器加載的。再看Dog類，由于它的加載要遵循雙親委托模型，因為類路徑下有Dog.class文件，所以AppClassLoader就可以加載Dog類。故此加載Dog類的ClassLoader是AppClassLoader。寫到這里，大家對類加載已經有了一個非常深刻的理解。那么java為什么使用雙親委托模型的好處我相信已經不言而喻了。那么下面來說說雙親委托模型，有沒有他的弊端呢，或者說有什么不好的地方嘛？我們可以打破這種雙親委托的方式去加載類嘛？下面我們來看一個例子。

類加載器的命名空間

說到雙親委托模型的弊端，那我就離不開命名空間的概念。

類加載器的命名空間 是由類加載器本身以及所有父加載器所加載出來的binary name(full class name)組成.

①:在同一個命名空間里，不允許出現二個完全一樣的binary name。

②:在不同的命名空間中，可以出現二個相同的binary name。當然二者對應的Class對象是相互不能感知到的，也就是說Class對象的類型是不一樣的。

解釋：同一個Person.class文件 被我們的不同的類加載器去加載，那么我們的jvm內存中會生成二個對應的Person的Class對象，而且這二個對應的Class對象是相互不可見的(通過Class對象反射創建的實例對象相互是不能夠兼容的不能相互轉型**

③:子加載器的命名空間中的binary name對應的類中可以訪問 父加載器命名空間中binary name對應的類，反之不行

下面準備了一張圖，以便于大家的理解。

上面這張圖就很好的解釋了命名空間的概念。大家可以再好好的體會一下。

我們光畫圖，光用嘴說并不是一種很有力的證據，就如同我寫在這篇博文的時候所提，我們在學習和掌握某個概念的時候，就必須要拿出有力的證據，來證明自己的猜想或者是觀點，那我們就舉一個例子。來驗證一下我們上面的理論是否正確。代碼如下：

這是Person類的代碼。

package com.test;public class Person {

    public Person() {
        new Dog();
        System.out.println("Dog的classLoader:-->"+ Dog.class.getClassLoader());
    }

    static{
        System.out.println("person類被初始化了");
    }
}

這是Dog類的代碼。

package com.test;public class Dog {

    public Dog(){
        System.out.println("Dog 的構造函數");
    }
}

具體的驗證思路是這樣的，首先我們把Person類的Class文件放到啟動類加載器的加載目錄下（C:\Program Files\Java\jdk1.8.0_144\jre\classes 這是啟動類加載器的加載目錄）來達到Person類交給啟動類加載器加載的目的。

然后呢，我們讓Dog類去被AppClassLoader（系統類加載器去加載）。然后我們在Person類中去訪問Dog類。看看能否訪問成功。

測試環境:把我們的Person.class放置在C:\Program Files\Java\jdk1.8.0_131\jre\classes這個目錄下，那么我們的Person.class就會被我們的啟動類加載器加載,而我們的Dog類是被AppClassLoader進行加載，我們的Person類 中引用我們的Dog類會拋出異常.

創建main方法進行測試：

package com.test;import java.lang.reflect.Method;/**
 * jvm 類加載器 第一章
 * @author 奇客時間-時光
 * 自定義類加載器——命名空間
 * 測試父加載所加載的類，不能訪問子加載器所加載的類。
 */public class MainClass02 {

    public static void main(String[] args) throws Exception {

        System.out.println("Person的類加載器:"+Person.class.getClassLoader());

        System.out.println("Dog的類加載器:"+Dog.class.getClassLoader());

        Class<?> clazz = Person.class;
        clazz.newInstance();


    }
}

運行結果：
    "C:\Program Files\Java\jdk1.8.0_144\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\lib\idea_rt.jar=59226:C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;I:\jvm\out\production\jvm-classloader" com.test.MainClass02
Person的類加載器:nullDog的類加載器:sun.misc.Launcher$AppClassLoader@18b4aac2
person類被初始化了
Exception in thread "main" java.lang.NoClassDefFoundError: com/test/Dog
 at com.test.Person.<init>(Person.java:7)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
 at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
 at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
 at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
 at java.lang.Class.newInstance(Class.java:442)
 at com.test.MainClass02.main(MainClass02.java:20)

Process finished with exit code 1

總結:通過上面的代碼我們就可以看出來，我們在Person中去new一個Dog的實例的時候，并沒有創建成功，而是拋出了Exception in thread "main" java.lang.NoClassDefFoundError: com/test/Dog這樣的異常，這也就證明了，我們上面所說的結論（父加載器所加載的類，不能訪問子加載所加載的類。）

即啟動類加載器所加載的類，不能訪問系統類加載器所加載的類（AppClassLoader）。

那么肯定會有人問，我們的子加載器所加載的類，可以訪問父加載器所加載的類嘛？我們不妨來證實一下，我們只需要改動一下MainClass02這個類的代碼即可，讓AppClassLoader去加載Dog類，讓我們的自定義類加載器去加載我們的Person類。并在Person類中去訪問Dog類。然后將之前C:\Program Files\Java\jdk1.8.0_131\jre\classes目錄下的Person中的Class文件刪除掉，另外還有把我們類路徑下的Person文件刪除掉，并且在I:\test\目錄下添加com.test.Person.class文件。代碼如下：

package com.test;import java.lang.reflect.Method;/**
 * jvm 類加載器 第一章
 * @author 奇客時間-時光
 * 自定義類加載器
 * 測試子類加載器所加載的類，能否訪問父加載器所加載的類。
 */public class MainClass02 {

    public static void main(String[] args) throws Exception {
        //創建自定義類加載器的一個實例，并且通過構造器指定名稱        Test01ClassLoader myClassLoader = new Test01ClassLoader("loader1");
        myClassLoader.setPath("I:\\test\\");
        Class<?> classz = myClassLoader.loadClass("com.test.Person");
        System.out.println(classz.getClassLoader());

        System.out.println("Dog的類加載器:"+Dog.class.getClassLoader());

        classz.newInstance();


    }
}

運行結果："C:\Program Files\Java\jdk1.8.0_144\bin\java.exe" "-javaagent:C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\lib\idea_rt.jar=60588:C:\Program Files\JetBrains\IntelliJ IDEA 2019.2\bin" -Dfile.encoding=UTF-8 -classpath "C:\Program Files\Java\jdk1.8.0_144\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\access-bridge-64.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\cldrdata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jaccess.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\jfxrt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\nashorn.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunec.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunjce_provider.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunmscapi.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\sunpkcs11.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\ext\zipfs.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jce.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfr.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jfxswt.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\resources.jar;C:\Program Files\Java\jdk1.8.0_144\jre\lib\rt.jar;I:\jvm\out\production\jvm-classloader" com.test.MainClass02
自己的類加載器被加載了
com.test.Test01ClassLoader@677327b6
Dog的類加載器:sun.misc.Launcher$AppClassLoader@18b4aac2
Dog 的構造函數

Process finished with exit code 0

從上面的結果可以看出，Person是由我們的Test01ClassLoader自定義類加載器所加載的，那么它的父親加載器是AppClassLoader，顯然Dog類是由我們的AppClassLoader所加載的。故此代碼正常運行，沒有拋出異常，從而得出結論：

1：父加載器所加載的類，不能訪問子加載器所加載的類。

2：子加載器所加載的類，可以訪問父加載器所加載的類。

雙親委托模型的弊端

• 我們先看一段我們非常熟悉的數據庫連接相關的代碼片段。

  Class.forName("com.mysql.jdbc.Driver");
  Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/RUNOOB","root","123456");
  Statement stmt = conn.createStatement();

案例分析

• 在上述圖中的第五步為什么會用線程上下文加載器進行加載呢？

• 在雙親委托模型的機制下，類的加載是由下而上的。即下層的加載器會委托上層進行加載。有些接口是Java核心庫（rt.jar）提供的例如上面的createStatement接口，而Java核心庫是由啟動類加載器進行加載的。而這些接口的具體實現是來自不同的廠商(Mysql)。而具體的實現都是通過依賴jar包放到我們項目中的classPath下的。Java的啟動類加載器/根類加載器是不會加載這些其他來源的jar包。

• 我們都知道classPath下的jar包是由我們系統類加載器/應用加載器進行加載，根據我們雙親委托的機制父類加載器是看不到子類（系統類加載器）所加載的具體實現。createStatement 這個接口是由根類加載器進行加載的 而具體的實現又加載不了。在雙親委托的機制下，createStatement這個接口就無具體的實現。

• 我們Java的開發者就通過給當前線程池設置上下文加載器的機制，就可以由設置的上下文加載器來實現對于接口實現類的加載。換句話說父類加載器可以使用當前線程上下文加載器加載父類加載器加載不了的一些接口的實現。完美了解決了由于SPI模型（接口定義在核心庫中,而實現由各自的廠商以jar的形式依賴到我們項目中）的接口調用。

下面我提供了一張SPI的流程圖。不知道什么是SPI的小伙伴兒，可以看一下這張圖：

從上面的例子，我們可以看出，雙親委托模型的弊端。然后我們的jdk給我們提供了一種通過修改線程上下文類加載的方式來打破這種雙親委托的規則。關于修改線程上下文類加載的話題，我們下個章節再具體的講解。接下來呢，我們再看看，獲取類加載器的幾個方法。并且奉上翻譯好的java doc文檔。方便我們后續學習線程類加載器。

獲取類加載器的幾個方法

• Class.getClassLoader()

/**
* Returns the class loader for the class(返回加載該類的類加載器). Some implementations may use
* null to represent the bootstrap class loader(有一些jvm的實現可能用null來表示我們的啟動類加載器比如 hotspot).
* This method will return null in such implementations if this class was loaded by the bootstrap class loader.
* 若這個方法返回null的話,那么這個類是由我們的啟動類加載器加載
*
* If this object represents a primitive type or void, null is returned.
(原始類型 比如int,long等等的類或者 void類型 那么他們的類加載器是null)
*
*
*/public ClassLoader getClassLoader() {
ClassLoader cl = getClassLoader0();if (cl == null)return null;
SecurityManager sm = System.getSecurityManager();if (sm != null) {
ClassLoader.checkClassLoaderPermission(cl, Reflection.getCallerClass());
}return cl;
}

• 1:返回代表加載該class的類加載器

• 2:有一些虛擬機(比如hotspot) 的啟動類加載器是null來表示

• 3:原始類型 比如int ,long 或者是void類型 ，他們的類加載器是null

• ClassLoader.getSystemClassLoader()方法解讀

/**
* Returns the system class loader for delegation(該方法返回系統類加載器). This is the default
* delegation parent for new ClassLoader instances(也是我們自己定義的類加載器的委托父類), and is
* typically the class loader used to start the application(通常系統類加載器是用來啟動我們的應用的)
*
* This method is first invoked early in the runtime's startup
* sequence(程序在運行早起就會調用該方法), at which point it creates the system class loader and sets it
* as the context class loader of the invoking <tt>Thread</tt>.(在那個時間,調用線程創建我們的系統類加載器同時把系統類加載器設置到我們線程上下文中)
*
* <p> The default system class loader is an implementation-dependent
* instance of this class.(這句話沒有很好的理解)
*
* <p> If the system property "<tt>java.system.class.loader</tt>" is defined
* when this method is first invoked then the value of that property is
* taken to be the name of a class that will be returned as the system
* class loader. The class is loaded using the default system class loader
* and must define a public constructor that takes a single parameter of
* type <tt>ClassLoader</tt> which is used as the delegation parent. An
* instance is then created using this constructor with the default system
* class loader as the parameter. The resulting class loader is defined
* to be the system class loader.
我們可以通過java.system.class.loader 系統屬性來指定一個自定義的類加載的二進制名稱作為新的系統類加載器，
在我們自定的加載中我們需要定義個帶參數的構造函數，參數為classLoader,那么我們這個自定義的類加載器就會看做系統類加載器

*
* @return The system <tt>ClassLoader</tt> for delegation, or
* <tt>null</tt> if none
*
* @throws SecurityException
* If a security manager exists and its <tt>checkPermission</tt>
* method doesn't allow access to the system class loader.
*
* @throws IllegalStateException
* If invoked recursively during the construction of the class
* loader specified by the "<tt>java.system.class.loader</tt>"
* property.
*
* @throws Error
* If the system property "<tt>java.system.class.loader</tt>"
* is defined but the named class could not be loaded, the
* provider class does not define the required constructor, or an
* exception is thrown by that constructor when it is invoked. The
* underlying cause of the error can be retrieved via the
* {@link Throwable#getCause()} method.
*
* @revised 1.4
*/@CallerSensitivepublic static ClassLoader getSystemClassLoader() {//初始化系統類加載器initSystemClassLoader();if (scl == null) {return null;
}
SecurityManager sm = System.getSecurityManager();if (sm != null) {
checkClassLoaderPermission(scl, Reflection.getCallerClass());
}return scl;
}

• 1:該方法的作用是返回系統類加載器

• 2:也是我們自定義加載器的直接父類

• 3:系統類加載器是用來啟動我們的應用的

• 4:在系統早期，調用線程會創建出我們的系統類加載器，并且把我們的系統類加載器設置到當前線程的上下文中.

• 5：我們可以通過系統屬性:java.system.class.loader來指定一個我們自定義類加載器來充當我們系統類加載器，不過我們的我們自定的加載器需要提供一個帶參數(classloader)的構造器

到此，關于“JVM的藝術之什么是類加載器”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！