雙親委派模型

對于任意一個類，都需要由加載它的類加載器和這個類本身來一同確立其在Java虛擬機中的唯一性。

為什么需要雙親委派

如果不是同一個類加載器加載，即使是相同的class文件，也會出現(xiàn)判斷不相同的情況，從而引發(fā)一些意想不到的情況，為了保證相同的class文件，在使用的時候，是相同的對象，jvm設(shè)計的時候，采用了雙親委派的方式來加載類。

雙親委派好處

• 避免同一個類被多次加載；
• 每個加載器只能加載自己范圍內(nèi)的類；

缺點：

頂層的啟動類加載器的代碼無法訪問到底層的類加載器。

每一個類都有一個對應(yīng)它的類加載器。系統(tǒng)中的 ClassLoder 在協(xié)同工作的時候會默認使用雙親委派模型 。即在類加載的時候，系統(tǒng)會首先判斷當(dāng)前類是否被加載過。已經(jīng)被加載的類會直接返回，否則才會嘗試加載。類加載的時候，首先會把該請求委派該父類加載器的 loadClass() 處理，因此所有的請求最終都應(yīng)該傳送到頂層的啟動類加載器 BootstrapClassLoader中。當(dāng)父類加載器無法處理時，才由自己來處理。特別當(dāng)父類加載器為null時，會使用啟動類加載器 BootstrapClassLoader 作為父類加載器。

父類加載器有自己的加載范圍，范圍內(nèi)沒有找到，則不加載，并返回給子類。

jvm提供了三種系統(tǒng)加載器：

• 啟動類加載器（Bootstrap ClassLoader）：C++實現(xiàn)，在java里無法獲取，負責(zé)加載/lib下的類。
• 擴展類加載器（Extension ClassLoader）： Java實現(xiàn)，可以在java里獲取，負責(zé)加載/lib/ext下的類。
• 系統(tǒng)類加載器/應(yīng)用程序類加載器（Application ClassLoader）：是與我們接觸對多的類加載器，我們寫的代碼默認就是由它來加載，ClassLoader.getSystemClassLoader返回的就是它。

破壞雙親委派

為什么需要破壞雙親委派？

因為在某些情況下父類加載器需要委托子類加載器去加載class文件。受到加載范圍的限制，父類加載器無法加載到需要的文件，以Driver接口為例，由于Driver接口定義在jdk當(dāng)中的，而其實現(xiàn)由各個數(shù)據(jù)庫的服務(wù)商來提供，比如mysql的就寫了MySQL Connector，那么問題就來了，DriverManager（也由jdk提供）要加載各個實現(xiàn)了Driver接口的實現(xiàn)類，然后進行管理，但是DriverManager由啟動類加載器加載，只能記載JAVA_HOME的lib下文件，而其實現(xiàn)是由服務(wù)商提供的，由系統(tǒng)類加載器加載，這個時候就需要啟動類加載器來委托子類來加載Driver實現(xiàn)，從而破壞了雙親委派，這里僅僅是舉了破壞雙親委派的其中一個情況。

破壞雙親委派的實現(xiàn)

我們結(jié)合Driver來看一下在spi（Service Provider Inteface）中如何實現(xiàn)破壞雙親委派。
先從DriverManager開始看，平時我們通過DriverManager來獲取數(shù)據(jù)庫的Connection：
在調(diào)用DriverManager的時候，會先初始化類，調(diào)用其中的靜態(tài)塊：

可以看到，load方法調(diào)用獲取了當(dāng)前線程中的上下文類加載器，那么上下文類加載器放的是什么加載器呢？

在sun.misc.Launcher中，我們找到了答案，在Launcher初始化的時候，會獲取AppClassLoader，然后將其設(shè)置為上下文類加載器，而這個AppClassLoader，就是之前上文提到的系統(tǒng)類加載器Application ClassLoader，所以上下文類加載器默認情況下就是系統(tǒng)加載器。

以上就是淺談jvm雙親委派和破壞雙親委派的詳細內(nèi)容，更多關(guān)于jvm雙親委派的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論