最近一段時(shí)間，我在面試的過(guò)程中，很喜歡問(wèn)雙親委派的一些問(wèn)題，因?yàn)槲野l(fā)現(xiàn)這個(gè)問(wèn)題真的可以幫助我全方位的了解一個(gè)候選人。

記得前幾天一次面試過(guò)程中，我和一位候選人聊到了JVM的類加載機(jī)制的問(wèn)題，他談到了雙親委派，并且很自信的給我講了一下他對(duì)于雙親委派的理解。

因?yàn)殡y得碰到一個(gè)對(duì)著塊知識(shí)了解的比較多的候選人，于是我們展開(kāi)了"300回合"的交鋒，當(dāng)問(wèn)完這些問(wèn)題的之后，大概半個(gè)小時(shí)已經(jīng)過(guò)去了。

最后，這個(gè)后續(xù)人和我說(shuō)：“我萬(wàn)萬(wàn)沒(méi)想到，我一個(gè)工作7年的技術(shù)經(jīng)理，竟然被雙親委派給虐了！！！”

先來(lái)回顧下我都問(wèn)了他哪些問(wèn)題，看看你能回答上來(lái)多少個(gè)：

1、什么是雙親委派？

2、為什么需要雙親委派，不委派有什么問(wèn)題？

3、"父加載器"和"子加載器"之間的關(guān)系是繼承的嗎？

4、雙親委派是怎么實(shí)現(xiàn)的？

5、我能不能主動(dòng)破壞這種雙親委派機(jī)制？怎么破壞？

6、為什么重寫loadClass方法可以破壞雙親委派，這個(gè)方法和findClass（）、defineClass（）區(qū)別是什么？

7、說(shuō)一說(shuō)你知道的雙親委派被破壞的例子吧

8、為什么JNDI、JDBC等需要破壞雙親委派？

9、為什么TOMCAT要破壞雙親委派？

10、談?wù)勀銓?duì)模塊化技術(shù)的理解吧！

以上，10個(gè)問(wèn)題，從頭開(kāi)始答，你大概可以堅(jiān)持到第幾題？

什么是雙親委派機(jī)制

首先，我們知道，虛擬機(jī)在加載類的過(guò)程中需要使用類加載器進(jìn)行加載，而在Java中，類加載器有很多，那么當(dāng)JVM想要加載一個(gè).class文件的時(shí)候，到底應(yīng)該由哪個(gè)類加載器加載呢？

這就不得不提到"雙親委派機(jī)制"。

首先，我們需要知道的是，Java語(yǔ)言系統(tǒng)中支持以下4種類加載器：

• Bootstrap ClassLoader 啟動(dòng)類加載器
• Extention ClassLoader 標(biāo)準(zhǔn)擴(kuò)展類加載器
• Application ClassLoader 應(yīng)用類加載器
• User ClassLoader 用戶自定義類加載器

這四種類加載器之間，是存在著一種層次關(guān)系的，如下圖

[圖片上傳中…(image-27cd3a-1611066134740-1)]



一般認(rèn)為上一層加載器是下一層加載器的父加載器，那么，除了BootstrapClassLoader之外，所有的加載器都是有父加載器的。

那么，所謂的雙親委派機(jī)制，指的就是：當(dāng)一個(gè)類加載器收到了類加載的請(qǐng)求的時(shí)候，他不會(huì)直接去加載指定的類，而是把這個(gè)請(qǐng)求委托給自己的父加載器去加載。只有父加載器無(wú)法加載這個(gè)類的時(shí)候，才會(huì)由當(dāng)前這個(gè)加載器來(lái)負(fù)責(zé)類的加載。

那么，什么情況下父加載器會(huì)無(wú)法加載某一個(gè)類呢？

其實(shí)，Java中提供的這四種類型的加載器，是有各自的職責(zé)的：

• Bootstrap ClassLoader ，主要負(fù)責(zé)加載Java核心類庫(kù)，%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。
• Extention ClassLoader，主要負(fù)責(zé)加載目錄%JRE_HOME%\lib\ext目錄下的jar包和class文件。
• Application ClassLoader ，主要負(fù)責(zé)加載當(dāng)前應(yīng)用的classpath下的所有類
• User ClassLoader ， 用戶自定義的類加載器,可加載指定路徑的class文件

那么也就是說(shuō)，一個(gè)用戶自定義的類，如com.hollis.ClassHollis 是無(wú)論如何也不會(huì)被Bootstrap和Extention加載器加載的。

為什么需要雙親委派？

如上面我們提到的，因?yàn)轭惣虞d器之間有嚴(yán)格的層次關(guān)系，那么也就使得Java類也隨之具備了層次關(guān)系。

或者說(shuō)這種層次關(guān)系是優(yōu)先級(jí)。

比如一個(gè)定義在java.lang包下的類，因?yàn)樗淮娣旁趓t.jar之中，所以在被加載過(guò)程匯總，會(huì)被一直委托到Bootstrap ClassLoader，最終由Bootstrap ClassLoader所加載。

而一個(gè)用戶自定義的com.hollis.ClassHollis類，他也會(huì)被一直委托到Bootstrap ClassLoader，但是因?yàn)锽ootstrap ClassLoader不負(fù)責(zé)加載該類，那么會(huì)在由Extention ClassLoader嘗試加載，而Extention ClassLoader也不負(fù)責(zé)這個(gè)類的加載，最終才會(huì)被Application ClassLoader加載。

這種機(jī)制有幾個(gè)好處。

首先，通過(guò)委派的方式，可以避免類的重復(fù)加載，當(dāng)父加載器已經(jīng)加載過(guò)某一個(gè)類時(shí)，子加載器就不會(huì)再重新加載這個(gè)類。

另外，通過(guò)雙親委派的方式，還保證了安全性。因?yàn)锽ootstrap ClassLoader在加載的時(shí)候，只會(huì)加載JAVA_HOME中的jar包里面的類，如java.lang.Integer，那么這個(gè)類是不會(huì)被隨意替換的，除非有人跑到你的機(jī)器上， 破壞你的JDK。

那么，就可以避免有人自定義一個(gè)有破壞功能的java.lang.Integer被加載。這樣可以有效的防止核心Java API被篡改。

"父子加載器"之間的關(guān)系是繼承嗎？

很多人看到父加載器、子加載器這樣的名字，就會(huì)認(rèn)為Java中的類加載器之間存在著繼承關(guān)系。

甚至網(wǎng)上很多文章也會(huì)有類似的錯(cuò)誤觀點(diǎn)。

這里需要明確一下，雙親委派模型中，類加載器之間的父子關(guān)系一般不會(huì)以繼承（Inheritance）的關(guān)系來(lái)實(shí)現(xiàn)，而是都使用組合（Composition）關(guān)系來(lái)復(fù)用父加載器的代碼的。

如下為ClassLoader中父加載器的定義：

public abstract class ClassLoader {// The parent class loader for delegationprivate final ClassLoader parent; } 復(fù)制代碼

雙親委派是怎么實(shí)現(xiàn)的？

雙親委派模型對(duì)于保證Java程序的穩(wěn)定運(yùn)作很重要，但它的實(shí)現(xiàn)并不復(fù)雜。

實(shí)現(xiàn)雙親委派的代碼都集中在java.lang.ClassLoader的loadClass()方法之中：

protected Class<?> loadClass(String name, boolean resolve)throws ClassNotFoundException{synchronized (getClassLoadingLock(name)) {// First, check if the class has already been loadedClass<?> c = findLoadedClass(name);if (c == null) {long t0 = System.nanoTime();try {if (parent != null) {c = parent.loadClass(name, false);} else {c = findBootstrapClassOrNull(name);}} catch (ClassNotFoundException e) {// ClassNotFoundException thrown if class not found// from the non-null parent class loader}if (c == null) {// If still not found, then invoke findClass in order// to find the class.long t1 = System.nanoTime();c = findClass(name);// this is the defining class loader; record the statssun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);sun.misc.PerfCounter.getFindClasses().increment();}}if (resolve) {resolveClass(c);}return c;}} 復(fù)制代碼

代碼不難理解，主要就是以下幾個(gè)步驟：

1、先檢查類是否已經(jīng)被加載過(guò) 2、若沒(méi)有加載則調(diào)用父加載器的loadClass()方法進(jìn)行加載 3、若父加載器為空則默認(rèn)使用啟動(dòng)類加載器作為父加載器。 4、如果父類加載失敗，拋出ClassNotFoundException異常后，再調(diào)用自己的findClass()方法進(jìn)行加載。

如何主動(dòng)破壞雙親委派機(jī)制？

知道了雙親委派模型的實(shí)現(xiàn)，那么想要破壞雙親委派機(jī)制就很簡(jiǎn)單了。

因?yàn)樗碾p親委派過(guò)程都是在loadClass方法中實(shí)現(xiàn)的，那么想要破壞這種機(jī)制，那么就自定義一個(gè)類加載器，重寫其中的loadClass方法，使其不進(jìn)行雙親委派即可。

loadClass（）、findClass（）、defineClass（）區(qū)別

ClassLoader中和類加載有關(guān)的方法有很多，前面提到了loadClass，除此之外，還有findClass和defineClass等，那么這幾個(gè)方法有什么區(qū)別呢？

• loadClass()
  • 就是主要進(jìn)行類加載的方法，默認(rèn)的雙親委派機(jī)制就實(shí)現(xiàn)在這個(gè)方法中。
• findClass()
  • 根據(jù)名稱或位置加載.class字節(jié)碼
• definclass()
  • 把字節(jié)碼轉(zhuǎn)化為Class

這里面需要展開(kāi)講一下loadClass和findClass，我們前面說(shuō)過(guò)，當(dāng)我們想要自定義一個(gè)類加載器的時(shí)候，并且像破壞雙親委派原則時(shí)，我們會(huì)重寫loadClass方法。

那么，如果我們想定義一個(gè)類加載器，但是不想破壞雙親委派模型的時(shí)候呢？

這時(shí)候，就可以繼承ClassLoader，并且重寫findClass方法。findClass()方法是JDK1.2之后的ClassLoader新添加的一個(gè)方法。

/*** @since 1.2*/ protected Class<?> findClass(String name) throws ClassNotFoundException {throw new ClassNotFoundException(name); } 復(fù)制代碼

這個(gè)方法只拋出了一個(gè)異常，沒(méi)有默認(rèn)實(shí)現(xiàn)。

JDK1.2之后已不再提倡用戶直接覆蓋loadClass()方法，而是建議把自己的類加載邏輯實(shí)現(xiàn)到findClass()方法中。

因?yàn)樵趌oadClass()方法的邏輯里，如果父類加載器加載失敗，則會(huì)調(diào)用自己的findClass()方法來(lái)完成加載。

所以，如果你想定義一個(gè)自己的類加載器，并且要遵守雙親委派模型，那么可以繼承ClassLoader，并且在findClass中實(shí)現(xiàn)你自己的加載邏輯即可。

雙親委派被破壞的例子

雙親委派機(jī)制的破壞不是什么稀奇的事情，很多框架、容器等都會(huì)破壞這種機(jī)制來(lái)實(shí)現(xiàn)某些功能。

第一種被破壞的情況是在雙親委派出現(xiàn)之前。

由于雙親委派模型是在JDK1.2之后才被引入的，而在這之前已經(jīng)有用戶自定義類加載器在用了。所以，這些是沒(méi)有遵守雙親委派原則的。

第二種，是JNDI、JDBC等需要加載SPI接口實(shí)現(xiàn)類的情況。

**第三種是為了實(shí)現(xiàn)熱插拔熱部署工具。**為了讓代碼動(dòng)態(tài)生效而無(wú)需重啟，實(shí)現(xiàn)方式時(shí)把模塊連同類加載器一起換掉就實(shí)現(xiàn)了代碼的熱替換。

第四種時(shí)tomcat等web容器的出現(xiàn)。

第五種時(shí)OSGI、Jigsaw等模塊化技術(shù)的應(yīng)用。

為什么JNDI，JDBC等需要破壞雙親委派？

我們?nèi)粘ｉ_(kāi)發(fā)中，大多數(shù)時(shí)候會(huì)通過(guò)API的方式調(diào)用Java提供的那些基礎(chǔ)類，這些基礎(chǔ)類時(shí)被Bootstrap加載的。

但是，調(diào)用方式除了API之外，還有一種SPI的方式。

如典型的JDBC服務(wù)，我們通常通過(guò)以下方式創(chuàng)建數(shù)據(jù)庫(kù)連接：

Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql", "root", "1234"); 復(fù)制代碼

在以上代碼執(zhí)行之前，DriverManager會(huì)先被類加載器加載，因?yàn)閖ava.sql.DriverManager類是位于rt.jar下面的 ，所以他會(huì)被根加載器加載。

類加載時(shí)，會(huì)執(zhí)行該類的靜態(tài)方法。其中有一段關(guān)鍵的代碼是：

ServiceLoader<Driver> loadedDrivers = ServiceLoader.load(Driver.class); 復(fù)制代碼

這段代碼，會(huì)嘗試加載classpath下面的所有實(shí)現(xiàn)了Driver接口的實(shí)現(xiàn)類。

那么，問(wèn)題就來(lái)了。

DriverManager是被根加載器加載的，那么在加載時(shí)遇到以上代碼，會(huì)嘗試加載所有Driver的實(shí)現(xiàn)類，但是這些實(shí)現(xiàn)類基本都是第三方提供的，根據(jù)雙親委派原則，第三方的類不能被根加載器加載。

那么，怎么解決這個(gè)問(wèn)題呢？

于是，就在JDBC中通過(guò)引入ThreadContextClassLoader（線程上下文加載器，默認(rèn)情況下是AppClassLoader）的方式破壞了雙親委派原則。

我們深入到ServiceLoader.load方法就可以看到：

public static <S> ServiceLoader<S> load(Class<S> service) {ClassLoader cl = Thread.currentThread().getContextClassLoader();return ServiceLoader.load(service, cl); } 復(fù)制代碼

第一行，獲取當(dāng)前線程的線程上下?類加載器 AppClassLoader，?于加載 classpath 中的具體實(shí)現(xiàn)類。

為什么Tomcat要破壞雙親委派

我們知道，Tomcat是web容器，那么一個(gè)web容器可能需要部署多個(gè)應(yīng)用程序。

不同的應(yīng)用程序可能會(huì)依賴同一個(gè)第三方類庫(kù)的不同版本，但是不同版本的類庫(kù)中某一個(gè)類的全路徑名可能是一樣的。

如多個(gè)應(yīng)用都要依賴hollis.jar，但是A應(yīng)用需要依賴1.0.0版本，但是B應(yīng)用需要依賴1.0.1版本。這兩個(gè)版本中都有一個(gè)類是com.hollis.Test.class。

如果采用默認(rèn)的雙親委派類加載機(jī)制，那么是無(wú)法加載多個(gè)相同的類。

所以，Tomcat破壞雙親委派原則，提供隔離的機(jī)制，為每個(gè)web容器單獨(dú)提供一個(gè)WebAppClassLoader加載器。

Tomcat的類加載機(jī)制：為了實(shí)現(xiàn)隔離性，優(yōu)先加載 Web 應(yīng)用自己定義的類，所以沒(méi)有遵照雙親委派的約定，每一個(gè)應(yīng)用自己的類加載器——WebAppClassLoader負(fù)責(zé)加載本身的目錄下的class文件，加載不到時(shí)再交給CommonClassLoader加載，這和雙親委派剛好相反。

模塊化技術(shù)與類加載機(jī)制

近幾年模塊化技術(shù)已經(jīng)很成熟了，在JDK 9中已經(jīng)應(yīng)用了模塊化的技術(shù)。

其實(shí)早在JDK 9之前，OSGI這種框架已經(jīng)是模塊化的了，而OSGI之所以能夠?qū)崿F(xiàn)模塊熱插拔和模塊內(nèi)部可見(jiàn)性的精準(zhǔn)控制都?xì)w結(jié)于其特殊的類加載機(jī)制，加載器之間的關(guān)系不再是雙親委派模型的樹(shù)狀結(jié)構(gòu)，而是發(fā)展成復(fù)雜的網(wǎng)狀結(jié)構(gòu)。

[圖片上傳中…(image-257470-1611066134739-0)]



在JDK中，雙親委派也不是絕對(duì)的了。

在JDK9之前，JVM的基礎(chǔ)類以前都是在rt.jar這個(gè)包里，這個(gè)包也是JRE運(yùn)行的基石。

這不僅是違反了單一職責(zé)原則，同樣程序在編譯的時(shí)候會(huì)將很多無(wú)用的類也一并打包，造成臃腫。

在JDK9中，整個(gè)JDK都基于模塊化進(jìn)行構(gòu)建，以前的rt.jar, tool.jar被拆分成數(shù)十個(gè)模塊，編譯的時(shí)候只編譯實(shí)際用到的模塊，同時(shí)各個(gè)類加載器各司其職，只加載自己負(fù)責(zé)的模塊。

Class<?> c = findLoadedClass(cn); if (c == null) {// 找到當(dāng)前類屬于哪個(gè)模塊LoadedModule loadedModule = findLoadedModule(cn);if (loadedModule != null) {//獲取當(dāng)前模塊的類加載器BuiltinClassLoader loader = loadedModule.loader();//進(jìn)行類加載c = findClassInModuleOrNull(loadedModule, cn);} else {// 找不到模塊信息才會(huì)進(jìn)行雙親委派if (parent != null) {c = parent.loadClassOrNull(cn);}} } 復(fù)制代碼

總結(jié)

以上，從什么是雙親委派，到如何實(shí)現(xiàn)與破壞雙親委派，又從破壞雙親委派的示例等多個(gè)方面全面介紹了關(guān)于雙親委派的知識(shí)。

相信通過(guò)學(xué)習(xí)本文，你一定對(duì)雙親委派機(jī)制有了更加深刻的了解。

作者：HollisChuang
鏈接：https://juejin.cn/post/6916314841472991239
來(lái)源：掘金

總結(jié)

談到面試，其實(shí)說(shuō)白了就是刷題刷題刷題，天天作死的刷。。。。。

為了準(zhǔn)備這個(gè)“金三銀四”的春招，狂刷一個(gè)月的題，狂補(bǔ)超多的漏洞知識(shí)，像這次美團(tuán)面試問(wèn)的算法、數(shù)據(jù)庫(kù)、Redis、設(shè)計(jì)模式等這些題目都是我刷到過(guò)的

并且我也將自己刷的題全部整理成了PDF或者Word文檔（含詳細(xì)答案解析），有需要的朋友可以戳這里即可免費(fèi)領(lǐng)取

66個(gè)Java面試知識(shí)點(diǎn)

架構(gòu)專題（MySQL，Java，Redis，線程，并發(fā)，設(shè)計(jì)模式，Nginx，Linux，框架，微服務(wù)等）+大廠面試題詳解（百度，阿里，騰訊，華為，迅雷，網(wǎng)易，中興，北京中軟等）

算法刷題（PDF）

我刷到過(guò)的

并且我也將自己刷的題全部整理成了PDF或者Word文檔（含詳細(xì)答案解析），有需要的朋友可以戳這里即可免費(fèi)領(lǐng)取

[外鏈圖片轉(zhuǎn)存中…(img-5hIDEwY4-1623727308699)]

66個(gè)Java面試知識(shí)點(diǎn)

架構(gòu)專題（MySQL，Java，Redis，線程，并發(fā)，設(shè)計(jì)模式，Nginx，Linux，框架，微服務(wù)等）+大廠面試題詳解（百度，阿里，騰訊，華為，迅雷，網(wǎng)易，中興，北京中軟等）

[外鏈圖片轉(zhuǎn)存中…(img-x0zsIKqG-1623727308701)]

算法刷題（PDF）

總結(jié)

以上是生活随笔為你收集整理的Java自学资料！你确定你真的理解_双亲委派_了吗？！的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。