前言
今天繼續聊類裝載器是如何實現安全的，這些細節一定是你以前沒有注意到的，深入底層的知識往往是我們最容易逃避的，小瘋子寫在頭條裏，希望你停下來娛樂的時候也能花個3分鐘看看，對你是否有所啓發？喜歡的一定點收藏，關注哦，每天都會在更新。
基本看完的人都收藏起來了。
正文
-
類裝載器
類裝載器體系結構守護了被信任類庫的邊界，因爲類加載器的類型不同，裝載以後分別放入不同的包裏，包與包之間一般情況下是不能訪問的。
在版本1.2開始，除了啓動類裝載器以外的每一個類裝載器，都有一個“雙親”類裝載器，在某個特定的類裝載器試圖以常用方式裝載類型以前，它都會以默認的方式，把這個類委託給它的雙親來處理——請求雙親來裝載這個類型。這個雙親再依次請求它自己的雙親類來處理，依次類推，直到到達啓動類裝載器，因爲啓動類裝載器是沒有雙親的，處於最頂層了。在這個傳遞過程中，如果有一個雙親類裝載器有能力裝載這個類型，則這個類型的類裝載器返回這個類型，否則，這個類裝載器試圖自己來裝載這個類型。
下面我們就接着分析一下啓動類加載器、標準擴展類加載器和系統類加載器三者之間的關係。可能大家已經從各種資料上面看到了如下類似的一幅圖片：
啓動類裝載器只負責加載那些核心的Java API的class文件，因爲核心Java API的class文件是用於“啓動”Java虛擬機的class文件，所以，啓動類裝載器的名字也因此而得。
用戶自定義的類裝載器來負責其他class文件的裝載，在應用程序啓動以前，它至少創建一個用戶自定義類裝載器，也可能創建多個，所有這些類裝載器被連接在一個雙親-孩子的關係鏈中，在這條鏈的頂端是啓動類裝載器，末端是系統類裝載器，它是由Java應用程序創建的，新的用戶定義類裝載器的默認委派雙親。
這裏就簡要敘述一下一般用戶自定義類加載器的工作流程吧：
1、首先檢查請求的類型是否已經被這個類裝載器裝載到命名空間中了，如果已經裝載，直接返回；否則轉入步驟2；
2、委派類加載請求給父類加載器（更準確的說應該是雙親類加載器，真實虛擬機中各種類加載器最終會呈現樹狀結構），如果父類加載器能夠完成，則返回父類加載器加載的Class實例；否則轉入步驟3；
3、調用本類加載器的findClass（…）方法，試圖獲取對應的字節碼，如果獲取的到，則調用defineClass（…）導入類型到方法區；如果獲取不到對應的字節碼或者其他原因失敗，返回異常給loadClass（…）， loadClass（…）轉而拋異常，終止加載過程（注意：這裏的異常種類不止一種）。
這裏就不在細說了，一般熟悉類加載器這部分知識應該都比較熟悉，我們來繼續將，類加載器怎麼實現安全的！
類裝載器的體系結構是通過剔除裝作被信任的不可靠的類，來保護那些可信任類庫的邊界，如果某個惡意的類可以成功的欺騙Java虛擬機，使得Java虛擬機相信它是一個來自可靠源的可信類，那麼，這個惡意類就可能突破沙箱的阻隔，爲了防止這樣的情況，類裝載器體系結構阻塞了危機Java虛擬機運行時安全的潛在途徑。
在雙親委派的情況下，啓動類裝載器會在最可信的類庫-核心Java API-中檢查每個被裝載的類型，然後，才依次到標準擴展，類路徑上的本地類文件中檢查，所以，如果網絡類裝載器裝載的某個代碼執行時，想要從網絡上下載一個和Java API中某個類型同名的類，例如Java.lang.Integer,它將不能成功，如果Java.lang.Integer的class文件已經存在，將不會再裝載，它只能使用由它的雙親委派返回的類，這個類是由啓動類裝載器裝載的，用這種方法，類裝載器的體系結構就可以防止不可靠的代碼用自己的版本來替代可信任的類。
還有一種可能，就是，我不是去替代你這個被信任的類，我是要在你被信任的類庫裏插入一個全新的類型，會怎麼樣？
比如我們下載了一個類Java.lang.virus，這個請求一路向上委派給啓動裝載器，但它無法找到這個成員，同時在已擴展以及本地類路徑中也找不到，你的類裝載器將試圖從網絡上下載這個類。
Java允許同一個包裏面的類擁有相同的權限，而包外面的類則沒有這個權限，你的類加載進Java.lang 包，那麼也就擁有這個包的所有權限，它就可以其中被信任的類，這樣的一個不可靠的類的存在太可怕了！
Java虛擬機是這樣佈置的，不同的類加載器加載的類放在不同的包裏，於是，這個從網絡上下載的類所屬於的包跟啓動類裝載的類並不是在一個包裏面，這樣，它就得不到其他可信任類的信息。而兩個包之間要允許可見，必須滿足同一個類裝載器裝載，這樣就可以避免不可靠類的侵犯。
下一節我們會將class文件檢查器！喜歡一定要關注收藏哦！
