JVM的藝術(shù)之什么是類加載器

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

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

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

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

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

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

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

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

概念：用一種簡單的方式去描述雙親委托的概念?？梢苑譃閮蓚€(gè)部分去理解

1委托:

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

自定義類加載器需要加載類時(shí)，先委托應(yīng)用類加載器去加載，然后應(yīng)用類加載器又向擴(kuò)展類加載器去委托，擴(kuò)展類加載器在向啟動(dòng)類加載器去委托。

如果啟動(dòng)類加載器不能加載該類。那么就向下加載

2加載:

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

啟動(dòng)類加載器就開始嘗試去加載這個(gè)類，啟動(dòng)類加載器加載不了就向下交給擴(kuò)展類加載器去加載，擴(kuò)展類加載器加載不了就繼續(xù)向下委托交給應(yīng)用類加載器

去加載，以此類推。

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

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

注意：在雙親委派機(jī)制中，各個(gè)加載器按照父子關(guān)系形成樹型結(jié)構(gòu),除了根加載器以外,每一個(gè)加載器有且只有一個(gè)父加載器。

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

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

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

• 雙親委派模型的好處

  總所周知:java.lang.object類是所有類的父類，所以我們程序在運(yùn)行期間會(huì)把java.lang.object類加載到內(nèi)存中，假如java.lang.object類

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

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

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

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

  根據(jù)我們的演示案例，一個(gè)class可以由多個(gè)類加載器去加載，同時(shí)可以在jvm內(nèi)存中存在多個(gè)不同版本的Class對(duì)象，這些對(duì)象是不兼容的。

  并且是不能相互轉(zhuǎn)換的。

什么是全盤委托加載？

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

person類代碼中創(chuàng)建Dog實(shí)例

public class Person {

  public Person(){
  
      new Dog();
  }

}

public class Dog {

    public Dog(){
        System.out.println("Dog 的構(gòu)造函數(shù)");
    }
}

• 測試類

  public class MainClass02 {
  
      public static void main(String[] args) throws Exception {
          //創(chuàng)建自定義類加載器的一個(gè)實(shí)例，并且通過構(gòu)造器指定名稱        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());
      }
  }
  
  
  運(yùn)行結(jié)果：
  
  sun.misc.Launcher$AppClassLoader@18b4aac2
  sun.misc.Launcher$AppClassLoader@18b4aac2
  
  Process finished with exit code 0

  從上面的運(yùn)行結(jié)果，我們可以看出，當(dāng)我們用自定義類加載器去加載我們的Person的時(shí)候，根據(jù)雙親委托模型，我們的Person并沒有被自定義類加載（Test01ClassLoader）加載，而是被AppClassloader加載成功，同時(shí)根據(jù)全盤委托規(guī)則，我們的Dog類也被AppClassLoader加載了。所以大家一定要記住這個(gè)至關(guān)重要的結(jié)論。為我們后面的學(xué)習(xí)打下堅(jiān)實(shí)的基礎(chǔ)。

下面我們?cè)倏匆粋€(gè)例子。我們把類路徑下的Person.class文件刪除掉，然后再運(yùn)行一下上面的main函數(shù)，看看結(jié)果。代碼如下：

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

類加載器的命名空間

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

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

①:在同一個(gè)命名空間里，不允許出現(xiàn)二個(gè)完全一樣的binary name。

②:在不同的命名空間中，可以出現(xiàn)二個(gè)相同的binary name。當(dāng)然二者對(duì)應(yīng)的Class對(duì)象是相互不能感知到的，也就是說Class對(duì)象的類型是不一樣的。

解釋：同一個(gè)Person.class文件 被我們的不同的類加載器去加載，那么我們的jvm內(nèi)存中會(huì)生成二個(gè)對(duì)應(yīng)的Person的Class對(duì)象，而且這二個(gè)對(duì)應(yīng)的Class對(duì)象是相互不可見的(通過Class對(duì)象反射創(chuàng)建的實(shí)例對(duì)象相互是不能夠兼容的不能相互轉(zhuǎn)型**

③:子加載器的命名空間中的binary name對(duì)應(yīng)的類中可以訪問 父加載器命名空間中binary name對(duì)應(yīng)的類，反之不行

下面準(zhǔn)備了一張圖，以便于大家的理解。

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

我們光畫圖，光用嘴說并不是一種很有力的證據(jù)，就如同我寫在這篇博文的時(shí)候所提，我們?cè)趯W(xué)習(xí)和掌握某個(gè)概念的時(shí)候，就必須要拿出有力的證據(jù)，來證明自己的猜想或者是觀點(diǎn)，那我們就舉一個(gè)例子。來驗(yàn)證一下我們上面的理論是否正確。代碼如下：

這是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 的構(gòu)造函數(shù)");
    }
}

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

然后呢，我們讓Dog類去被AppClassLoader（系統(tǒng)類加載器去加載）。然后我們?cè)赑erson類中去訪問Dog類?？纯茨芊裨L問成功。

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

創(chuàng)建main方法進(jìn)行測試：

package com.test;import java.lang.reflect.Method;/**
 * jvm 類加載器 第一章
 * @author 奇客時(shí)間-時(shí)光
 * 自定義類加載器——命名空間
 * 測試父加載所加載的類，不能訪問子加載器所加載的類。
 */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();


    }
}

運(yùn)行結(jié)果：
    "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

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

即啟動(dòng)類加載器所加載的類，不能訪問系統(tǒng)類加載器所加載的類（AppClassLoader）。

那么肯定會(huì)有人問，我們的子加載器所加載的類，可以訪問父加載器所加載的類嘛？我們不妨來證實(shí)一下，我們只需要改動(dòng)一下MainClass02這個(gè)類的代碼即可，讓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 奇客時(shí)間-時(shí)光
 * 自定義類加載器
 * 測試子類加載器所加載的類，能否訪問父加載器所加載的類。
 */public class MainClass02 {

    public static void main(String[] args) throws Exception {
        //創(chuàng)建自定義類加載器的一個(gè)實(shí)例，并且通過構(gòu)造器指定名稱        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();


    }
}

運(yùn)行結(jié)果："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 的構(gòu)造函數(shù)

Process finished with exit code 0

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

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

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

雙親委托模型的弊端

• 我們先看一段我們非常熟悉的數(shù)據(jù)庫連接相關(guān)的代碼片段。

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

案例分析

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

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

• 我們都知道classPath下的jar包是由我們系統(tǒng)類加載器/應(yīng)用加載器進(jìn)行加載，根據(jù)我們雙親委托的機(jī)制父類加載器是看不到子類（系統(tǒng)類加載器）所加載的具體實(shí)現(xiàn)。createStatement 這個(gè)接口是由根類加載器進(jìn)行加載的 而具體的實(shí)現(xiàn)又加載不了。在雙親委托的機(jī)制下，createStatement這個(gè)接口就無具體的實(shí)現(xiàn)。

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

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

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

獲取類加載器的幾個(gè)方法

• Class.getClassLoader()

/**
* Returns the class loader for the class(返回加載該類的類加載器). Some implementations may use
* null to represent the bootstrap class loader(有一些jvm的實(shí)現(xiàn)可能用null來表示我們的啟動(dòng)類加載器比如 hotspot).
* This method will return null in such implementations if this class was loaded by the bootstrap class loader.
* 若這個(gè)方法返回null的話,那么這個(gè)類是由我們的啟動(dòng)類加載器加載
*
* 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:有一些虛擬機(jī)(比如hotspot) 的啟動(dòng)類加載器是null來表示

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

• ClassLoader.getSystemClassLoader()方法解讀

/**
* Returns the system class loader for delegation(該方法返回系統(tǒng)類加載器). This is the default
* delegation parent for new ClassLoader instances(也是我們自己定義的類加載器的委托父類), and is
* typically the class loader used to start the application(通常系統(tǒng)類加載器是用來啟動(dòng)我們的應(yīng)用的)
*
* This method is first invoked early in the runtime's startup
* sequence(程序在運(yùn)行早起就會(huì)調(diào)用該方法), at which point it creates the system class loader and sets it
* as the context class loader of the invoking <tt>Thread</tt>.(在那個(gè)時(shí)間,調(diào)用線程創(chuàng)建我們的系統(tǒng)類加載器同時(shí)把系統(tǒng)類加載器設(shè)置到我們線程上下文中)
*
* <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 系統(tǒng)屬性來指定一個(gè)自定義的類加載的二進(jìn)制名稱作為新的系統(tǒng)類加載器，
在我們自定的加載中我們需要定義個(gè)帶參數(shù)的構(gòu)造函數(shù)，參數(shù)為classLoader,那么我們這個(gè)自定義的類加載器就會(huì)看做系統(tǒng)類加載器

*
* @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() {//初始化系統(tǒng)類加載器initSystemClassLoader();if (scl == null) {return null;
}
SecurityManager sm = System.getSecurityManager();if (sm != null) {
checkClassLoaderPermission(scl, Reflection.getCallerClass());
}return scl;
}

• 1:該方法的作用是返回系統(tǒng)類加載器

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

• 3:系統(tǒng)類加載器是用來啟動(dòng)我們的應(yīng)用的

• 4:在系統(tǒng)早期，調(diào)用線程會(huì)創(chuàng)建出我們的系統(tǒng)類加載器，并且把我們的系統(tǒng)類加載器設(shè)置到當(dāng)前線程的上下文中.

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

到此，關(guān)于“JVM的藝術(shù)之什么是類加載器”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！