?????????????????類加載器

??虛擬機(jī)設(shè)計(jì)團(tuán)隊(duì)把類加載階段中的“通過一個(gè)類的全限定名來獲取描述此類的二進(jìn)制字節(jié)流”這個(gè)動(dòng)作放到Java虛擬機(jī)外部去實(shí)現(xiàn)，以便讓應(yīng)用程序自己決定如何去獲取所需要的類。實(shí)現(xiàn)這個(gè)動(dòng)作的代碼模塊稱為“類加載器”。

類加載器可以說是Java語言的一項(xiàng)創(chuàng)新，也是Java語言流行的重要原因之一，它最初是為了滿足Java Applet的需求而開發(fā)出來的。雖然目前Java Applet技術(shù)基本上已經(jīng)“死掉”，但類加載器卻在類層次劃分、OSGi、熱部署、代碼加密等領(lǐng)域大放異彩，成為了Java技術(shù)體系中一塊重要的基石，可謂是失之桑榆，收之東隅。

1 、類與類加載器

??類加載器雖然只用于實(shí)現(xiàn)類的加載動(dòng)作，但它在Java程序中起到的作用卻遠(yuǎn)遠(yuǎn)不限于類加載階段。對(duì)于任意一個(gè)類，都需要由加載它的類加載器和這個(gè)類本身一同確立其在Java虛擬機(jī)中的唯一性，每一個(gè)類加載器，都擁有一個(gè)獨(dú)立的類名稱空間。這句話可以表達(dá)得更通俗一些：比較兩個(gè)類是否“相等”，只有在這兩個(gè)類是由同一個(gè)類加載器加載的前提下才有意義，否則，即使這兩個(gè)類來源于同一個(gè)Class文件，被同一個(gè)虛擬機(jī)加載，只要加載它們的類加載器不同，那這兩個(gè)類就必定不相等。

??這里所指的“相等”，包括代表類的Class對(duì)象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回結(jié)果，也包括使用instanceof關(guān)鍵字做對(duì)象所屬關(guān)系判定等情況。

2 、雙親委派模型

??從Java虛擬機(jī)的角度來講，只存在兩種不同的類加載器：一種是啟動(dòng)類加載器（Bootstrap ClassLoader），這個(gè)類加載器使用C++語言實(shí)現(xiàn)，是虛擬機(jī)自身的一部分；另一種就是所有其他的類加載器，這些類加載器都由Java語言實(shí)現(xiàn)，獨(dú)立于虛擬機(jī)外部，并且全都繼承自抽象類java.lang.ClassLoader。

從Java開發(fā)人員的角度來看，類加載器還可以劃分得更細(xì)致一些，絕大部分Java程序都會(huì)使用到以下3種系統(tǒng)提供的類加載器。

（1）啟動(dòng)類加載器（Bootstrap ClassLoader）

??前面已經(jīng)介紹過，這個(gè)類將器負(fù)責(zé)將存放在<JAVA_HOME>\lib目錄中的，或者被-Xbootclasspath參數(shù)所指定的路徑中的，并且是虛擬機(jī)識(shí)別的（僅按照文件名識(shí)別，如rt.jar，名字不符合的類庫即使放在lib目錄中也不會(huì)被加載）類庫加載到虛擬機(jī)內(nèi)存中。啟動(dòng)類加載器無法被Java程序直接引用，用戶在編寫自定義類加載器時(shí)，如果需要把加載請(qǐng)求委派給引導(dǎo)類加載器，那直接使用null代替即可。

（2）擴(kuò)展類加載器（Extension ClassLoader）

??這個(gè)加載器由sun.misc.Launcher$ExtClassLoader實(shí)現(xiàn)，它負(fù)責(zé)加載<JAVA_HOME>\lib\ext目錄中的，或者被java.ext.dirs系統(tǒng)變量所指定的路徑中的所有類庫，開發(fā)者可以直接使用擴(kuò)展類加載器。

（3）應(yīng)用程序類加載器（Application ClassLoader）

??這個(gè)類加載器由sun.misc.Launcher$App-ClassLoader實(shí)現(xiàn)。由于這個(gè)類加載器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也稱它為系統(tǒng)類加載器。它負(fù)責(zé)加載用戶類路徑（ClassPath）上所指定的類庫，開發(fā)者可以直接使用這個(gè)類加載器，如果應(yīng)用程序中沒有自定義過自己的類加載器，一般情況下這個(gè)就是程序中默認(rèn)的類加載器。

??我們的應(yīng)用程序都是由這3種類加載器互相配合進(jìn)行加載的，如果有必要，還可以加入自己定義的類加載器。這些類加載器之間的關(guān)系一般如下圖所示。

????????????????類加載器雙親委派模型

??雙親委派模型的工作過程是：如果一個(gè)類加載器收到了類加載的請(qǐng)求，它首先不會(huì)自己去嘗試加載這個(gè)類，而是把這個(gè)請(qǐng)求委派給父類加載器去完成，每一個(gè)層次的類加載器都是如此，因此所有的加載請(qǐng)求最終都應(yīng)該傳送到頂層的啟動(dòng)類加載器中，只有當(dāng)父加載器反饋?zhàn)约簾o法完成這個(gè)加載請(qǐng)求（它的搜索范圍中沒有找到所需的類）時(shí)，子加載器才會(huì)嘗試自己去加載。

3 、破壞雙親委派模型

??上文提到過雙親委派模型并不是一個(gè)強(qiáng)制性的約束模型，而是Java設(shè)計(jì)者推薦給開發(fā)者的類加載器實(shí)現(xiàn)方式。在Java的世界中大部分的類加載器都遵循這個(gè)模型，但也有例外，到目前為止，雙親委派模型主要出現(xiàn)過3較大規(guī)模的“被破壞”情況。

第一次“被破壞”

??雙親委派模型的第一次“被破壞”其實(shí)發(fā)生在雙親委派模型出現(xiàn)之前——即JDK 1.2發(fā)布之前。由于雙親委派模型在JDK 1.2之后才被引入，而類加載器和抽象類java.lang. ClassLoader則在JDK 1.0時(shí)代就已經(jīng)存在，面對(duì)已經(jīng)存在的用戶自定義類加載器的實(shí)現(xiàn)代碼，Java設(shè)計(jì)者引入雙親委派模型時(shí)不得不做出一些妥協(xié)。為了向前兼容，JDK 1.2之后的java.lang.ClassLoader添加了一個(gè)新的protected方法findClass()，在此之前，用戶去繼承java. lang.ClassLoader的唯一目的就是為了重寫loadClass()方法，因?yàn)樘摂M機(jī)在進(jìn)行類加載的時(shí)候會(huì)調(diào)用加載器的私有方法loadClassInternal()，而這個(gè)方法的唯一邏輯就是去調(diào)用自己的loadClass()。

上一節(jié)我們已經(jīng)看過loadClass()方法的代碼，雙親委派的具體邏輯就實(shí)現(xiàn)在這個(gè)方法之中，JDK 1.2之后已不提倡用戶再去覆蓋loadClass()方法，而應(yīng)當(dāng)把自己的類加載邏輯寫到findClass()方法中，在loadClass()方法的邏輯里如果父類加載失敗，則會(huì)調(diào)用自己的findClass()方法來完成加載，這樣就可以保證新寫出來的類加載器是符合雙親委派規(guī)則的。

第二次“被破壞”

??雙親委派模型的第二次“被破壞”是由這個(gè)模型自身的缺陷所導(dǎo)致的，雙親委派很好地解決了各個(gè)類加載器的基礎(chǔ)類的統(tǒng)一問題（越基礎(chǔ)的類由越上層的加載器進(jìn)行加載），基礎(chǔ)類之所以稱為“基礎(chǔ)”，是因?yàn)樗鼈兛偸亲鳛楸挥脩舸a調(diào)用的API，但世事往往沒有絕對(duì)的完美，如果基礎(chǔ)類又要調(diào)用回用戶的代碼，那該怎么辦？

這并非是不可能的事情，一個(gè)典型的例子便是JNDI服務(wù)，JNDI現(xiàn)在已經(jīng)是Java的標(biāo)準(zhǔn)服務(wù)，它的代碼由啟動(dòng)類加載器去加載（在JDK 1.3時(shí)放進(jìn)去的rt.jar），但JNDI的目的就是對(duì)資源進(jìn)行集中管理和查找，它需要調(diào)用由獨(dú)立廠商實(shí)現(xiàn)并部署在應(yīng)用程序的ClassPath下的JNDI接口提供者（SPI，Service Provider Interface）的代碼，但啟動(dòng)類加載器不可能“認(rèn)識(shí)”這些代碼啊！那該怎么辦？

??為了解決這個(gè)問題，Java設(shè)計(jì)團(tuán)隊(duì)只好引入了一個(gè)不太優(yōu)雅的設(shè)計(jì)：線程上下文類加載器（Thread Context ClassLoader）。這個(gè)類加載器可以通過java.lang.Thread類的setContextClassLoaser()方法進(jìn)行設(shè)置，如果創(chuàng)建線程時(shí)還未設(shè)置，它將會(huì)從父線程中繼承一個(gè)，如果在應(yīng)用程序的全局范圍內(nèi)都沒有設(shè)置過的話，那這個(gè)類加載器默認(rèn)就是應(yīng)用程序類加載器。

??有了線程上下文類加載器，就可以做一些“舞弊”的事情了，JNDI服務(wù)使用這個(gè)線程上下文類加載器去加載所需要的SPI代碼，也就是父類加載器請(qǐng)求子類加載器去完成類加載的動(dòng)作，這種行為實(shí)際上就是打通了雙親委派模型的層次結(jié)構(gòu)來逆向使用類加載器，實(shí)際上已經(jīng)違背了雙親委派模型的一般性原則，但這也是無可奈何的事情。Java中所有涉及SPI的加載動(dòng)作基本上都采用這種方式，例如JNDI、JDBC、JCE、JAXB和JBI等。

第三次“被破壞”

??雙親委派模型的第三次“被破壞”是由于用戶對(duì)程序動(dòng)態(tài)性的追求而導(dǎo)致的，這里所說的“動(dòng)態(tài)性”指的是當(dāng)前一些非?！盁衢T”的名詞：代碼熱替換（HotSwap）、模塊熱部署（Hot Deployment）等，說白了就是希望應(yīng)用程序能像我們的計(jì)算機(jī)外設(shè)那樣，接上鼠標(biāo)、U盤，不用重啟機(jī)器就能立即使用，鼠標(biāo)有問題或要升級(jí)就換個(gè)鼠標(biāo)，不用停機(jī)也不用重啟。對(duì)于個(gè)人計(jì)算機(jī)來說，重啟一次其實(shí)沒有什么大不了的，但對(duì)于一些生產(chǎn)系統(tǒng)來說，關(guān)機(jī)重啟一次可能就要被列為生產(chǎn)事故，這種情況下熱部署就對(duì)軟件開發(fā)者，尤其是企業(yè)級(jí)軟件開發(fā)者具有很大的吸引力。

??Sun公司所提出的JSR-294、JSR-277[插圖]規(guī)范在與JCP組織的模塊化規(guī)范之爭中落敗給JSR-291（即OSGi R4.2），雖然Sun不甘失去Java模塊化的主導(dǎo)權(quán)，獨(dú)立在發(fā)展Jigsaw項(xiàng)目，但目前OSGi已經(jīng)成為了業(yè)界“事實(shí)上”的Java模塊化標(biāo)準(zhǔn)，而OSGi實(shí)現(xiàn)模塊化熱部署的關(guān)鍵則是它自定義的類加載器機(jī)制的實(shí)現(xiàn)。每一個(gè)程序模塊（OSGi中稱為Bundle）都有一個(gè)自己的類加載器，當(dāng)需要更換一個(gè)Bundle時(shí)，就把Bundle連同類加載器一起換掉以實(shí)現(xiàn)代碼的熱替換。

在OSGi環(huán)境下，類加載器不再是雙親委派模型中的樹狀結(jié)構(gòu)，而是進(jìn)一步發(fā)展為更加復(fù)雜的網(wǎng)狀結(jié)構(gòu)，當(dāng)收到類加載請(qǐng)求時(shí)，OSGi將按照下面的順序進(jìn)行類搜索：

（1）將以java.*開頭的類委派給父類加載器加載。

（2）否則，將委派列表名單內(nèi)的類委派給父類加載器加載。

（3）否則，將Import列表中的類委派給Export這個(gè)類的Bundle的類加載器加載。

（4）否則，查找當(dāng)前Bundle的ClassPath，使用自己的類加載器加載。

（5）否則，查找類是否在自己的Fragment Bundle中，如果在，則委派給Fragment Bundle的類加載器加載。

（6）否則，查找Dynamic Import列表的Bundle，委派給對(duì)應(yīng)Bundle的類加載器加載。

（7）否則，類查找失敗。