## 類與類加載器
類加載器只用于實現類加載的動作，但是同時還有著確保類的唯一性的作用。也就是說:比較兩個類是否相等，只有確保這兩個類在同一個類加載器的前提下才是有意義的。否則即使兩個類來源于同一個klass文件，被同一個jvm加載，只要他們的類加載器不同，那么這兩個類就不相等(這里的相等代表klass對象的equals、isAssignableFrom、isInstance方法返回的結果)。
雙親委派模式
類加載器的種類
對于jvm來講，類加載器分為兩種：
一種是啟動類加載器，使用c++實現，是jvm自身的一部分
另一種是所有其他的類加載器，使用java實現，獨立于虛擬機外部，并且繼承自ClassLoader。
然而對于java開發人員來講，類加載器可以分成這三種：
- 啟動類加載器
- 擴展類加載器
- 應用程序類加載器。這個類加載器也被稱為
系統類加載器，負責加載用戶路徑上的類庫，開發者可以直接使用這個類加載器。
對于jvm加載一個類而言，是通過上面的三種類加載器相互配合加載的，他們之間的關系如下圖：
上圖中展示的這種一層層的層次加載關系，被稱為類的雙親委派模式。的雙親委派要求除了頂層的類加載器外都有自己的父類加載器。這里的類加載器之間的父子關系一般都不會以繼承的關系來實現，而是組合關系來復用類加載器的代碼。
整個雙親委派模式的過程是：
如果一個類加載器收到了類加載請求，他不會嘗試自己去加載，而是吧這個請求委派給父類加載器去完成，每一個層次的類加載器都是如此，因此所有類加載的請求最終都應該傳到頂層的啟動類加載器中，只有當父類加載器反饋自己無法完成這個類加載的請求(它的搜索范圍中沒有找到所需的類)時，子類才會嘗試自己加載。
為什么要使用雙親委派模式：因為這樣加載一個類，java類隨著他的類加載器一起具備了一種帶有優先級的層次關系，例如java.lang.Object他放在rt.jar中。無論哪個類加載器加載這個類，最后都是委派給最頂端的啟動類加載器去加載，這樣就保證了java.lang.Object無論是由哪個類加載器加載的，在當前jvm下都是同一個類。
破壞雙親委派模型
第一次破壞是在jdk2之前，用戶自定義的類加載器都是重寫
Classloader中的loadClass方法,這樣就導致每個自定義的類加載器其實是在使用自己的loadClass方法中的加載機制來進行加載,這種模式當然是不符合雙親委派機制的，也是無法保證同一個類在jvm中的唯一性的，那么為了保證及時是由不同的類加載器(哪怕是用戶自定義的類加載器加載)也是唯一的，java官方在Classloader中添加了findClass方法,用戶只需要重新這個findClass方法，在loadClass方法的邏輯里，如果父類加載失敗的時候，才會調用自己的findClass方法來完成類加載，這樣就完成了符合雙親委派機制。-
第二次的破壞是類似于jndi，jdbc這種服務，因為這種服務需要回調用戶的代碼，但是對于父類加載器而言是不認識用戶的代碼的。
那么這時候java團隊使用了一個不太優雅的設計：線程上下文類加載器。這個類加載器可以通過
Thread類的setContextClassLoader方法進行設置,如果創建線程時還未設置，它就從父線程繼承一個，如果在應用全局范圍內都沒有設置過的話，那這個類加載器默認就是應用程序類加載器。
利用這個線程上下文類加載器,jdni去加載需要的spi代碼，也就是父類請求子類的加載器去加載。
- 第三次的破壞是因為用戶對于程序的動態性追求，諸如：代碼熱替換，模塊熱部署。
這時候就誕生了諸如jigsaw和osgi。對于現在的業界來講，osgi贏得了java模塊化的主導權，成為目前業界模塊化的標準。而Osgi模塊話的關鍵是他自己的類加載機制：每個程序模塊(bundle)都有自己的類加載器，需要更換程序(bundle)的時候，連同類加載器一起替換，以實現代碼的熱部署。
osgi和雙親委派模式不同，他是一個基于網狀的互相組合依賴的加載。
Osgi的加載步驟是這樣的：
- 如果類或者資源是在包java.*中，那么交由父級類加載器代理完成，否則，搜索過程進入第二步。如果父類級類加載器加載失敗，那么查找過程結束，加載失敗。
- 如果類或者資源在啟動代理序列（org.osgi.framework.bootdelegation）中定義，那么交由父級代理完成，此時的父級代理有啟動參數org.osgi.framework.bundle.parent指定，默認是引導類加載器（bootstrap class loader），如果找到了類或者資源，那么查找過程結束。
- 如果類或者資源所在的包是在Import-Package中指定的，或者是在此之前通過動態導入加載的了，那么將請求轉發到導出bundle的類加載器，否則搜索繼續進行下一步；如果該包在啟動參數org.osgi.framework.system.packages.extra中，則將請求轉發給osgi容器外部的類加載器（通常是系統類加載器）。如果將請求交由導出類加載器代理，而類或者資源又沒有找到，那么查找過程中止，同時請求失敗。
- 如果包中類或者和資源所在的包由其他bundle通過是使用Require-Bundle從一個或多個其他bundle進行導入的了，那么請求交由其他那些bundle的類加載器完成，按照根據在bundle的manifest中指定的順序進行查找進行查找。如果沒有找到類或者資源，搜索繼續進行。
- 使用bundle本身的內部bundle類路徑查找完畢之后，。如果類或者資源還沒有找到，搜索繼續到下一步。
- 查找每一個附加的fragment的內部類路徑，fragment的查找根據bundle ID順序升序查找。如果沒有找到類或者資源的，查找過程繼續下一步。
- 如果包中類或者資源所在的包由bundle導出，或者包由bundle導入（使用Import-Package或者Require-Bundle），查找結束，即類或者資源沒有找到。
- 否則，如果類或者資源所在的包是通過使用DynamicImport-Package進行導入，那么試圖進行包的動態導入。導出者exporter必須符合包約束。如果找到了合適的導出者exporter，然后建立連接，以后的包導入就可以通過步驟三進行。如果連接建立失敗，那么請求失敗。
- 如果動態導入建立了，請求交由導出bundle的類加載器代理。如果代理查找失敗，那么查找過程中止，請求失敗
