牛掰！20張圖解密JVM類加載子系統(tǒng)，瞬間豁然開朗

1. java語言編寫， 由sun.misc.Launcher$AppClassLoader實(shí)現(xiàn)。

2. 「派生于ClassLoader類」

3. 它負(fù)責(zé)加載環(huán)境變量classpath或系統(tǒng)屬性 java.class.path指定路徑下的類庫

4. 「該類加載器是程序中默認(rèn)的類加載器」，一般來說，java應(yīng)用的類都是由它來完成加載

5. 通過ClassLoader#getSystemClassLoader()方法可以獲取到該類加載器

/**
?*?虛擬機(jī)自帶加載器
?*/
public?class?ClassLoaderTest1?{
????public?static?void?main(String[]?args)?{
????????System.out.println("********啟動類加載器*********");
????????URL[]?urls?=?sun.misc.Launcher.getBootstrapClassPath().getURLs();
????????//獲取BootStrapClassLoader能夠加載的api路徑
????????for?(URL?e:urls){
????????????System.out.println(e.toExternalForm());
????????}

????????//從上面的路徑中隨意選擇一個類?看看他的類加載器是什么
????????//Provider位于?/jdk1.8.0_171.jdk/Contents/Home/jre/lib/jsse.jar?下，引導(dǎo)類加載器加載它
????????ClassLoader?classLoader?=?Provider.class.getClassLoader();
????????System.out.println(classLoader);//null

????????System.out.println("********拓展類加載器********");
????????String?extDirs?=?System.getProperty("java.ext.dirs");
????????for?(String?path?:?extDirs.split(";")){
????????????System.out.println(path);
????????}
????????//從上面的路徑中隨意選擇一個類?看看他的類加載器是什么:拓展類加載器
????????ClassLoader?classLoader1?=?CurveDB.class.getClassLoader();
????????System.out.println(classLoader1);//sun.misc.Launcher$ExtClassLoader@4dc63996
????}
}

「知識擴(kuò)展：啟動類加載器BootStrapClassLoader能夠加載的api路徑有」

最近看java.util.concurrent包的內(nèi)容，發(fā)現(xiàn)java.time.、java.util.、java.nio.、java.lang.、java.text.、java.sql.、java.math.*等等都在rt.jar包下。

3.3 用戶自定義加載器

「在Java的日常應(yīng)用程序開發(fā)中，類的加載幾乎是由上述三種類加載器相互配合執(zhí)行的，在必要的時候，我們還可以自定義加載器，來定制類的加載方式?！?/strong>

為什么要使用用戶自定義類加載器

1. 隔離加載類

2. 修改類加載的方式

3. 拓展加載源

4. 防止源碼泄漏

「用戶自定義加載器實(shí)現(xiàn)步驟：」

1. 開發(fā)人員可以通過繼承抽象類 java.lang.ClassLoader 類的方式，實(shí)現(xiàn)自己的類加載器，以滿足一些特殊的需求
2. 在JDK1.2之前，在自定義類加載器時，總會去繼承ClassLoader類并重寫loadClass()方法，從而實(shí)現(xiàn)自定義的類加載類，但是在JDK1.2之后已不再建議用戶去覆蓋loadClass()方法，而是建議把自定義的類加載邏輯寫在findClass()方法中
3. 在編寫自定義類加載器時，如果沒有太過于復(fù)雜的需求，可以直接繼承URLClassLoader類，這樣就可以避免自己去編寫findClass()方法及其獲取字節(jié)碼流的方式，使自定義類加載器編寫更加簡潔。

四、ClassLoader的常用方法及獲取方法

ClassLoader類，它是一個抽象類，其后所有的類加載器都繼承自ClassLoader（不包括啟動類加載器）

4.1 ClassLoader繼承關(guān)系

「sun.misc.Launcher它是一個java虛擬機(jī)的入口應(yīng)用」

4.2 代碼示例

public?class?ClassLoaderTest2?{
????public?static?void?main(String[]?args)?{
????????try?{
????????????
????????????//1.Class.forName().getClassLoader()
????????????ClassLoader?classLoader?=?Class.forName("java.lang.String").getClassLoader();
????????????System.out.println(classLoader);?//?String?類由啟動類加載器加載，我們無法獲取

????????????//2.Thread.currentThread().getContextClassLoader()
????????????ClassLoader?classLoader1?=?Thread.currentThread().getContextClassLoader();
????????????System.out.println(classLoader1);

????????????//3.ClassLoader.getSystemClassLoader().getParent()
????????????ClassLoader?classLoader2?=?ClassLoader.getSystemClassLoader();
????????????System.out.println(classLoader2);

????????}?catch?(ClassNotFoundException?e)?{
????????????e.printStackTrace();
????????}
????}
}

//?輸出
null
sun.misc.Launcher$AppClassLoader@18b4aac2
sun.misc.Launcher$AppClassLoader@18b4aac2

五、雙親委派機(jī)制

Java虛擬機(jī)對class文件采用的是按需加載的方式，也就是說當(dāng)需要使用該類時才會將她的class文件加載到內(nèi)存生成的class對象。而且加載某個類的class文件時，java虛擬機(jī)采用的是雙親委派模式，即把請求交由父類處理，它是一種任務(wù)委派模式。

5.1 雙親委派機(jī)制工作原理

1. 如果一個類加載器收到了類加載請求，它并不會自己先去加載，而是把這個請求委托給父類的加載器去執(zhí)行；
2. 如果父類加載器還存在其父類加載器，則進(jìn)一步向上委托，依次遞歸，請求最終將到達(dá)頂層的啟動類加載器；
3. 如果父類加載器可以完成類加載任務(wù)，就成功返回，倘若父類加載器無法完成此加載任務(wù)，子加載器才會嘗試自己去加載，這就是雙親委派模式。

5.2 代碼示例

如圖，雖然我們自定義了一個java.lang包下的String嘗試覆蓋核心類庫中的String，但是由于雙親委派機(jī)制，啟動加載器會加載java核心類庫的String類（BootStrap啟動類加載器只加載包名為java、javax、sun等開頭的類），而核心類庫中的String并沒有main方法。

5.3 雙親委派機(jī)制的優(yōu)勢

1. 「避免類的重復(fù)加載，如上」

2. 「保護(hù)程序安全，防止核心API被隨意修改」

啟動類加載器可以搶在標(biāo)準(zhǔn)擴(kuò)展類加載器之前去加載類，而標(biāo)準(zhǔn)擴(kuò)展類裝載器可以搶在類路徑加載器之前去裝載那個類，類路徑裝載 器又可以搶在自定義類加載器之前去加載它。所以Java虛擬機(jī)先從最可信的Java核心API查找類型，這是為了防止不可靠的類扮演被信任的類，試想一 下，網(wǎng)絡(luò)上有個名叫java.lang.Integer的類，它是某個黑客為了想混進(jìn)java.lang包所起的名字，實(shí)際上里面含有惡意代碼，但是這種伎倆在雙親模式加載體系結(jié)構(gòu)下是行不通的，因為網(wǎng)絡(luò)類加載器在加載它的時候，它首先調(diào)用雙親類加載器，這樣一直向上委托，直到啟動類加載器，而啟動類加載器在核心Java API里發(fā)現(xiàn)了這個名字的類，所以它就直接加載Java核心API的java.lang.Integer類，然后將這個類返回，所以自始自終網(wǎng)絡(luò)上的 java.lang.Integer的類是不會被加載的。

3. 「保證核心API包的訪問權(quán)限」

但是如果這個移動代碼不是去試圖替換一個被信任的類（就是前面說的那種情況），而是想在一個被信任的包中插入一個全新的類型，情況會怎樣呢？比如一個名為 java.lang.Virus的類，經(jīng)過雙親委托模式，最終類裝載器試圖從網(wǎng)絡(luò)上下載這個類，因為網(wǎng)絡(luò)類裝載器的雙親們都沒有這個類（當(dāng)然沒有了，因為 是病毒嘛）。假設(shè)成功下載了這個類，那你肯定會想，Virus和lang下的其他類痛在java.lang包下，暗示這個類是Java API的一部分，那么是不是也擁有修改Java.lang包中數(shù)據(jù)的權(quán)限呢？答案當(dāng)然不是，因為要取得訪問和修改java.lang包中的權(quán) 限，java.lang.Virus和java.lang下其他類必須是屬于同一個運(yùn)行時包的，什么是運(yùn)行時包？運(yùn)行時包是指由同一個類裝載器裝載的、屬 于同一個包的、多個類型的集合。考慮一下，java.lang.Virus和java.lang其他類是同一個類裝載器裝載的嗎？不是 的！java.lang.Virus是由網(wǎng)絡(luò)類裝載器裝載的！

自定義類：java.lang.MeDsh（java.lang包需要訪問權(quán)限，阻止我們用包名自定義類）

5.4 雙親委派機(jī)制在SPI中的應(yīng)用

1. 某個應(yīng)用程序由雙親委派機(jī)制找到引導(dǎo)類加載器，首先調(diào)用rt.jar包中的SPI核心，但由于SPI核心當(dāng)中有各種各樣的接口需要被實(shí)現(xiàn)（這里指具體的服務(wù)提供商），這里我們已JDBC.jar為例，jdbc.jar可以為我們提供具體的實(shí)現(xiàn)。

2. 那么這時我們需要反向委托，找到線程上下文類加載器去加載jdbc.jar

3. 線程上下文類加載器屬于系統(tǒng)類加載器

5.5 沙箱安全機(jī)制

自定義String類，但是在加載自定義String類的時候會率先使用引導(dǎo)類加載器加載，而引導(dǎo)類加載器在加載的過程中會先加載JDK自帶的文件(rt.jar包中java\lang\String.class)，報錯信息說沒有main方法，就是因為加載的rt.jar包中的String類。這樣可以何保證對java核心源代碼的保護(hù)，這就是沙箱安全機(jī)制。

六、其他

6.1 JVM中表示兩個class對象是否為同一個類

在JVM中表示兩個class對象是否為同一個類存在的兩個必要條件

• 類的完整類名必須一致，包括包名

• 即使類的完整類名一致，同時要求加載這個類的ClassLoader（指ClassLoader實(shí)例對象）必須相同；是引導(dǎo)類加載器、還是定義類加載器

換句話說，在JVM中，即使這兩個類對象（class對象）來源同一個Class文件，被同一個虛擬機(jī)所加載，但只要加載它們的ClassLoader實(shí)例對象不同，那么這兩個類對象也是不相等的。

6.2 對類加載器的引用

JVM必須知道一個類型是由啟動類加載器加載的還是由用戶類加載器加載的。如果一個類型由用戶類加載器加載的，那么JVM會 「將這個類加載器的一個引用作為類型信息的一部分保存在方法區(qū)中」。當(dāng)解析一個類型到另一個類型的引用的時候，JVM需要保證兩個類型的加載器是相同的。

6.3 類的主動使用和被動使用

Java程序?qū)︻惖氖褂梅绞椒譃椋褐鲃邮褂煤捅粍邮褂茫?strong>「即是否調(diào)用了clinit()方法」。