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

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

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

1 、類與類加載器

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

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

2 、雙親委派模型

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

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

（1）啟動類加載器（Bootstrap ClassLoader）

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

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

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

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

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

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

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

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

3 、破壞雙親委派模型

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

第一次“被破壞”

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

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

第二次“被破壞”

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

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

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

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

第三次“被破壞”

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

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

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

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

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

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

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

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

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

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