jvm classLoader architecture：

1. Bootstrap ClassLoader/啟動(dòng)類加載器 ?
   主要負(fù)責(zé)jdk_home/lib目錄下的核心 api 或 -Xbootclasspath 選項(xiàng)指定的jar包裝入工作。
2. Extension ClassLoader/擴(kuò)展類加載器 ?
   主要負(fù)責(zé)jdk_home/lib/ext目錄下的jar包或 -Djava.ext.dirs 指定目錄下的jar包裝入工作。
3. System ClassLoader/系統(tǒng)類加載器 ?
   主要負(fù)責(zé)java -classpath/-Djava.class.path所指的目錄下的類與jar包裝入工作。
4. User Custom ClassLoader/用戶自定義類加載器(java.lang.ClassLoader的子類) ?
   在程序運(yùn)行期間, 通過java.lang.ClassLoader的子類動(dòng)態(tài)加載class文件, 體現(xiàn)java動(dòng)態(tài)實(shí)時(shí)類裝入特性。

類加載器的特性：

1. 每個(gè)ClassLoader都維護(hù)了一份自己的名稱空間， 同一個(gè)名稱空間里不能出現(xiàn)兩個(gè)同名的類。
2. 為了實(shí)現(xiàn)java安全沙箱模型頂層的類加載器安全機(jī)制, java默認(rèn)采用了 " 雙親委派的加載鏈 " 結(jié)構(gòu)。

類圖中， BootstrapClassLoader是一個(gè)單獨(dú)的java類， 其實(shí)在這里， 不應(yīng)該叫他是一個(gè)java類。因?yàn)椋呀?jīng)完全不用java實(shí)現(xiàn)了。它是在jvm啟動(dòng)時(shí)， 就被構(gòu)造起來(lái)的， 負(fù)責(zé)java平臺(tái)核心庫(kù)。

自定義類加載器加載一個(gè)類的步驟

ClassLoader 類加載邏輯分析， 以下邏輯是除 BootstrapClassLoader 外的類加載器加載流程：

線程上下文類加載器
java默認(rèn)的線程上下文類加載器是 系統(tǒng)類加載器(AppClassLoader)。

以上代碼摘自sun.misc.Launch的無(wú)參構(gòu)造函數(shù)Launch()。

使用線程上下文類加載器, 可以在執(zhí)行線程中, 拋棄雙親委派加載鏈模式, 使用線程上下文里的類加載器加載類.
典型的例子有, 通過線程上下文來(lái)加載第三方庫(kù)jndi實(shí)現(xiàn), 而不依賴于雙親委派.
大部分java app服務(wù)器(jboss, tomcat..)也是采用contextClassLoader來(lái)處理web服務(wù)。
還有一些采用 hotswap 特性的框架, 也使用了線程上下文類加載器, 比如 seasar (full stack framework in japenese).

線程上下文從根本解決了一般應(yīng)用不能違背雙親委派模式的問題.
使java類加載體系顯得更靈活.

隨著多核時(shí)代的來(lái)臨, 相信多線程開發(fā)將會(huì)越來(lái)越多地進(jìn)入程序員的實(shí)際編碼過程中. 因此,
在編寫基礎(chǔ)設(shè)施時(shí)， 通過使用線程上下文來(lái)加載類, 應(yīng)該是一個(gè)很好的選擇。

當(dāng)然, 好東西都有利弊. 使用線程上下文加載類, 也要注意, 保證多根需要通信的線程間的類加載器應(yīng)該是同一個(gè),
防止因?yàn)椴煌念惣虞d器, 導(dǎo)致類型轉(zhuǎn)換異常(ClassCastException)。

為什么要使用這種雙親委托模式呢？

1. 因?yàn)檫@樣可以避免重復(fù)加載，當(dāng)父親已經(jīng)加載了該類的時(shí)候，就沒有必要子ClassLoader再加載一次。
2. 考慮到安全因素，我們?cè)囅胍幌拢绻皇褂眠@種委托模式，那我們就可以隨時(shí)使用自定義的String來(lái)動(dòng)態(tài)替代java核心api中定義類型，這樣會(huì)存在非常大的安全隱患，而雙親委托的方式，就可以避免這種情況，因?yàn)镾tring已經(jīng)在啟動(dòng)時(shí)被加載，所以用戶自定義類是無(wú)法加載一個(gè)自定義的ClassLoader。

java動(dòng)態(tài)載入class的兩種方式：

1. implicit隱式,即利用實(shí)例化才載入的特性來(lái)動(dòng)態(tài)載入class
2. explicit顯式方式,又分兩種方式:
   1. java.lang.Class的forName()方法
   2. java.lang.ClassLoader的loadClass()方法

用Class.forName加載類

Class.forName使用的是被調(diào)用者的類加載器來(lái)加載類的。
這種特性, 證明了java類加載器中的名稱空間是唯一的, 不會(huì)相互干擾。
即在一般情況下, 保證同一個(gè)類中所關(guān)聯(lián)的其他類都是由當(dāng)前類的類加載器所加載的。

上面中 ClassLoader.getCallerClassLoader 就是得到調(diào)用當(dāng)前forName方法的類的類加載器

static塊在什么時(shí)候執(zhí)行?

• 當(dāng)調(diào)用forName(String)載入class時(shí)執(zhí)行,如果調(diào)用ClassLoader.loadClass并不會(huì)執(zhí)行.forName(String,false,ClassLoader)時(shí)也不會(huì)執(zhí)行.
• 如果載入Class時(shí)沒有執(zhí)行static塊則在第一次實(shí)例化時(shí)執(zhí)行.比如new ,Class.newInstance()操作
• static塊僅執(zhí)行一次

各個(gè)java類由哪些classLoader加載?

• java類可以通過實(shí)例.getClass.getClassLoader()得知
• 接口由AppClassLoader(System ClassLoader,可以由ClassLoader.getSystemClassLoader()獲得實(shí)例)載入
• ClassLoader類由bootstrap loader載入

NoClassDefFoundError和ClassNotFoundException

• NoClassDefFoundError:當(dāng)java源文件已編譯成.class文件,但是ClassLoader在運(yùn)行期間在其搜尋路徑load某個(gè)類時(shí),沒有找到.class文件則報(bào)這個(gè)錯(cuò)
• ClassNotFoundException:試圖通過一個(gè)String變量來(lái)創(chuàng)建一個(gè)Class類時(shí)不成功則拋出這個(gè)異常