△Hollis, 一個對Coding有著獨特追求的人△ 這是Hollis的第? 326? 篇原創(chuàng)分享 來源 l Hollis(ID:hollischuang) 最近一段時間,我在面試的過程中,很喜歡問雙親委派的一些問題,因為我發(fā)現(xiàn)這個問題真的可以幫助我全方位的了解一個候選人。 記得前幾天一次面試過程中,我和一位候選人聊到了JVM的類加載機制的問題,他談到了雙親委派,并且很自信的給我講了一下他對于雙親委派的理解。 因為難得碰到一個對著塊知識了解的比較多的候選人,于是我們展開了"300回合"的交鋒,當問完這些問題的之后,大概半個小時已經(jīng)過去了。 最后,這個后續(xù)人和我說:"我萬萬沒想到,我一個工作7年的技術(shù)經(jīng)理,竟然被雙親委派給虐了!!! " 先來回顧下我都問了他哪些問題,看看你能回答上來多少個: 3、"父加載器"和"子加載器"之間的關(guān)系是繼承的嗎?? 5、我能不能主動破壞這種雙親委派機制?怎么破壞?? 6、為什么重寫loadClass方法可以破壞雙親委派,這個方法和findClass()、defineClass()區(qū)別是什么?? 8、為什么JNDI、JDBC等需要破壞雙親委派?? 10、談?wù)勀銓δK化技術(shù)的理解吧! 以上,10個問題,從頭開始答,你大概可以堅持到第幾題? 首先,我們知道,虛擬機在加載類的過程中需要使用類加載器進行加載,而在Java中,類加載器有很多,那么當JVM想要加載一個.class文件的時候,到底應(yīng)該由哪個類加載器加載呢? 首先,我們需要知道的是,Java語言系統(tǒng)中支持以下4種類加載器: Bootstrap ClassLoader 啟動類加載器 Extention ClassLoader 標準擴展類加載器 Application ClassLoader 應(yīng)用類加載器 User ClassLoader 用戶自定義類加載器 這四種類加載器之間,是存在著一種層次關(guān)系的,如下圖 一般認為上一層加載器是下一層加載器的父加載器,那么,除了BootstrapClassLoader之外,所有的加載器都是有父加載器的。 那么,所謂的雙親委派機制,指的就是:當一個類加載器收到了類加載的請求的時候,他不會直接去加載指定的類,而是把這個請求委托給自己的父加載器去加載。只有父加載器無法加載這個類的時候,才會由當前這個加載器來負責(zé)類的加載。 其實,Java中提供的這四種類型的加載器,是有各自的職責(zé)的: Bootstrap ClassLoader ,主要負責(zé)加載Java核心類庫,%JRE_HOME%\lib下的rt.jar、resources.jar、charsets.jar和class等。 Extention ClassLoader,主要負責(zé)加載目錄%JRE_HOME%\lib\ext目錄下的jar包和class文件。 Application ClassLoader ,主要負責(zé)加載當前應(yīng)用的classpath下的所有類 User ClassLoader , 用戶自定義的類加載器,可加載指定路徑的class文件 那么也就是說,一個用戶自定義的類,如com.hollis.ClassHollis 是無論如何也不會被Bootstrap和Extention加載器加載的。 如上面我們提到的,因為類加載器之間有嚴格的層次關(guān)系,那么也就使得Java類也隨之具備了層次關(guān)系。 或者說這種層次關(guān)系是優(yōu)先級。 比如一個定義在java.lang包下的類,因為它被存放在rt.jar之中,所以在被加載過程匯總,會被一直委托到Bootstrap ClassLoader,最終由Bootstrap ClassLoader所加載。 而一個用戶自定義的com.hollis.ClassHollis類,他也會被一直委托到Bootstrap ClassLoader,但是因為Bootstrap ClassLoader不負責(zé)加載該類,那么會在由Extention ClassLoader嘗試加載,而Extention ClassLoader也不負責(zé)這個類的加載,最終才會被Application ClassLoader加載。 首先,通過委派的方式,可以避免類的重復(fù)加載 ,當父加載器已經(jīng)加載過某一個類時,子加載器就不會再重新加載這個類。 另外,通過雙親委派的方式,還保證了安全性 。因為Bootstrap ClassLoader在加載的時候,只會加載JAVA_HOME中的jar包里面的類,如java.lang.Integer,那么這個類是不會被隨意替換的,除非有人跑到你的機器上, 破壞你的JDK。 那么,就可以避免有人自定義一個有破壞功能的java.lang.Integer被加載。這樣可以有效的防止核心Java API被篡改。 很多人看到父加載器、子加載器這樣的名字,就會認為Java中的類加載器之間存在著繼承關(guān)系。 甚至網(wǎng)上很多文章也會有類似的錯誤觀點。 這里需要明確一下,雙親委派模型中,類加載器之間的父子關(guān)系一般不會以繼承(Inheritance)的關(guān)系來實現(xiàn),而是都使用組合(Composition)關(guān)系來復(fù)用父加載器的代碼的。 public ?abstract ?class ?ClassLoader ? { ????????//?The?parent?class?loader?for?delegation ????????private ?final ?ClassLoader?parent; ????}
雙親委派模型對于保證Java程序的穩(wěn)定運作很重要,但它的實現(xiàn)并不復(fù)雜。 實現(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?loaded ????????????????Class>?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?stats ????????????????????????sun.misc.PerfCounter.getParentDelegationTime().addTime(t1?-?t0); ????????????????????????sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1); ????????????????????????sun.misc.PerfCounter.getFindClasses().increment(); ????????????????????} ????????????????} ????????????????if ?(resolve)?{ ????????????????????resolveClass(c); ????????????????} ????????????????return ?c; ????????????} ????????}
代碼不難理解,主要就是以下幾個步驟:
2、若沒有加載則調(diào)用父加載器的loadClass()方法進行加載? 3、若父加載器為空則默認使用啟動類加載器作為父加載器。 4、如果父類加載失敗,拋出ClassNotFoundException異常后,再調(diào)用自己的findClass()方法進行加載。 知道了雙親委派模型的實現(xiàn),那么想要破壞雙親委派機制就很簡單了。 因為他的雙親委派過程都是在loadClass方法中實現(xiàn)的,那么想要破壞這種機制,那么就自定義一個類加載器,重寫其中的loadClass方法,使其不進行雙親委派即可。 loadClass()、findClass()、defineClass()區(qū)別 ClassLoader中和類加載有關(guān)的方法有很多,前面提到了loadClass,除此之外,還有findClass和defineClass等,那么這幾個方法有什么區(qū)別呢? loadClass()? 就是主要進行類加載的方法,默認的雙親委派機制就實現(xiàn)在這個方法中。 findClass() ? 根據(jù)名稱或位置加載.class字節(jié)碼 definclass() ? 把字節(jié)碼轉(zhuǎn)化為Class 這里面需要展開講一下loadClass和findClass,我們前面說過,當我們想要自定義一個類加載器的時候,并且像破壞雙親委派原則時,我們會重寫loadClass方法。 那么,如果我們想定義一個類加載器,但是不想破壞雙親委派模型的時候呢? 這時候,就可以繼承ClassLoader,并且重寫findClass方法。findClass()方法是JDK1.2之后的ClassLoader新添加的一個方法。 /** ?????*?@since ??1.2 ?????*/ ????protected ?Class>?findClass(String?name)?throws ?ClassNotFoundException?{ ????????throw ?new ?ClassNotFoundException(name); ????}
這個方法只拋出了一個異常,沒有默認實現(xiàn)。
JDK1.2之后已不再提倡用戶直接覆蓋loadClass()方法,而是建議把自己的類加載邏輯實現(xiàn)到findClass()方法中。 因為在loadClass()方法的邏輯里,如果父類加載器加載失敗,則會調(diào)用自己的findClass()方法來完成加載。 所以,如果你想定義一個自己的類加載器,并且要遵守雙親委派模型,那么可以繼承ClassLoader,并且在findClass中實現(xiàn)你自己的加載邏輯即可。 雙親委派機制的破壞不是什么稀奇的事情,很多框架、容器等都會破壞這種機制來實現(xiàn)某些功能。 第一種被破壞的情況是在雙親委派出現(xiàn)之前。 由于雙親委派模型是在JDK1.2之后才被引入的,而在這之前已經(jīng)有用戶自定義類加載器在用了。所以,這些是沒有遵守雙親委派原則的。 第二種,是JNDI、JDBC等需要加載SPI接口實現(xiàn)類的情況。 第三種是為了實現(xiàn)熱插拔熱部署工具。 為了讓代碼動態(tài)生效而無需重啟,實現(xiàn)方式時把模塊連同類加載器一起換掉就實現(xiàn)了代碼的熱替換。第四種時tomcat等web容器的出現(xiàn)。 第五種時OSGI、Jigsaw等模塊化技術(shù)的應(yīng)用。 我們?nèi)粘i_發(fā)中,大多數(shù)時候會通過API的方式調(diào)用Java提供的那些基礎(chǔ)類,這些基礎(chǔ)類時被Bootstrap加載的。 但是,調(diào)用方式除了API之外,還有一種SPI的方式。 如典型的JDBC服務(wù),我們通常通過以下方式創(chuàng)建數(shù)據(jù)庫連接: Connection?conn?=?DriverManager.getConnection("jdbc:mysql://localhost:3306/mysql" ,?"root" ,?"1234" ); 在以上代碼執(zhí)行之前,DriverManager會先被類加載器加載,因為java.sql.DriverManager類是位于rt.jar下面的 ,所以他會被根加載器加載。
類加載時,會執(zhí)行該類的靜態(tài)方法。其中有一段關(guān)鍵的代碼是: ServiceLoader?loadedDrivers?=?ServiceLoader.load(Driver.class); 這段代碼,會嘗試加載classpath下面的所有實現(xiàn)了Driver接口的實現(xiàn)類。
DriverManager是被根加載器加載的,那么在加載時遇到以上代碼,會嘗試加載所有Driver的實現(xiàn)類,但是這些實現(xiàn)類基本都是第三方提供的,根據(jù)雙親委派原則,第三方的類不能被根加載器加載。 于是,就在JDBC中通過引入ThreadContextClassLoader(線程上下文加載器,默認情況下是AppClassLoader)的方式破壞了雙親委派原則。 我們深入到ServiceLoader.load方法就可以看到: public ?static ??ServiceLoader?load (Class?service) ? { ????????ClassLoader?cl?=?Thread.currentThread().getContextClassLoader(); ????????return ?ServiceLoader.load(service,?cl); ????}第一行,獲取當前線程的線程上下?類加載器 AppClassLoader,?于加載 classpath 中的具體實現(xiàn)類。
我們知道,Tomcat是web容器,那么一個web容器可能需要部署多個應(yīng)用程序。 不同的應(yīng)用程序可能會依賴同一個第三方類庫的不同版本,但是不同版本的類庫中某一個類的全路徑名可能是一樣的。 如多個應(yīng)用都要依賴hollis.jar,但是A應(yīng)用需要依賴1.0.0版本,但是B應(yīng)用需要依賴1.0.1版本。這兩個版本中都有一個類是com.hollis.Test.class。 如果采用默認的雙親委派類加載機制,那么是無法加載多個相同的類。 所以,Tomcat破壞雙親委派原則,提供隔離的機制,為每個web容器單獨提供一個WebAppClassLoader加載器。 Tomcat的類加載機制:為了實現(xiàn)隔離性,優(yōu)先加載 Web 應(yīng)用自己定義的類,所以沒有遵照雙親委派的約定,每一個應(yīng)用自己的類加載器——WebAppClassLoader負責(zé)加載本身的目錄下的class文件,加載不到時再交給CommonClassLoader加載,這和雙親委派剛好相反。 近幾年模塊化技術(shù)已經(jīng)很成熟了,在JDK 9中已經(jīng)應(yīng)用了模塊化的技術(shù)。 其實早在JDK 9之前,OSGI這種框架已經(jīng)是模塊化的了,而OSGI之所以能夠?qū)崿F(xiàn)模塊熱插拔和模塊內(nèi)部可見性的精準控制都歸結(jié)于其特殊的類加載機制,加載器之間的關(guān)系不再是雙親委派模型的樹狀結(jié)構(gòu),而是發(fā)展成復(fù)雜的網(wǎng)狀結(jié)構(gòu)。 在JDK9之前,JVM的基礎(chǔ)類以前都是在rt.jar這個包里,這個包也是JRE運行的基石。 這不僅是違反了單一職責(zé)原則,同樣程序在編譯的時候會將很多無用的類也一并打包,造成臃腫。 在JDK9中,整個JDK都基于模塊化進行構(gòu)建,以前的rt.jar, tool.jar被拆分成數(shù)十個模塊,編譯的時候只編譯實際用到的模塊,同時各個類加載器各司其職,只加載自己負責(zé)的模塊。 Class>?c?=?findLoadedClass(cn); ????if ?(c?==?null )?{ ????????//?找到當前類屬于哪個模塊 ????????LoadedModule?loadedModule?=?findLoadedModule(cn); ????????if ?(loadedModule?!=?null )?{ ????????????//獲取當前模塊的類加載器 ????????????BuiltinClassLoader?loader?=?loadedModule.loader(); ????????????//進行類加載 ????????????c?=?findClassInModuleOrNull(loadedModule,?cn); ?????????}?else ?{ ??????????????//?找不到模塊信息才會進行雙親委派 ????????????????if ?(parent?!=?null )?{ ??????????????????c?=?parent.loadClassOrNull(cn); ????????????????} ??????????} ????}
以上,從什么是雙親委派,到如何實現(xiàn)與破壞雙親委派,又從破壞雙親委派的示例等多個方面全面介紹了關(guān)于雙親委派的知識。 相信通過學(xué)習(xí)本文,你一定對雙親委派機制有了更加深刻的了解。 閱讀過本文之后,反手在簡歷上寫下:熟悉Java的類加載機制,不服來問! 推薦閱讀:
順豐快遞:請簽收MySQL靈魂十連
面試官留步!聽我跟你侃會兒Docker原理
講解 Zookeeper 的五個核心知識點
歡 迎 關(guān) 注 微 信 公 眾 號 : 互 聯(lián) 網(wǎng) 全 棧 架 構(gòu) , 收 取 更 多 有 價 值 的 信 息 。