啟動類裝載器只負責加載那些核心的Java API的class文件，因為核心Java API的class文件是用于“啟動”Java虛擬機的class文件，所以，啟動類裝載器的名字也因此而得。

　　用戶自定義的類裝載器來負責其他class文件的裝載，在應用程序啟動以前，它至少創(chuàng)建一個用戶自定義類裝載器，也可能創(chuàng)建多個，所有這些類裝載器被連接在一個雙親-孩子的關系鏈中，在這條鏈的頂端是啟動類裝載器，末端是系統(tǒng)類裝載器，它是由Java應用程序創(chuàng)建的，新的用戶定義類裝載器的默認委派雙親。

　　這里就簡要敘述一下一般用戶自定義類加載器的工作流程吧：

　　1、首先檢查請求的類型是否已經被這個類裝載器裝載到命名空間中了，如果已經裝載，直接返回;否則轉入步驟2;

　　2、委派類加載請求給父類加載器(更準確的說應該是雙親類加載器，真實虛擬機中各種類加載器最終會呈現樹狀結構)，如果父類加載器能夠完成，則返回父類加載器加載的Class實例;否則轉入步驟3;

　　3、調用本類加載器的findClass(…)方法，試圖獲取對應的字節(jié)碼，如果獲取的到，則調用defineClass(…)導入類型到方法區(qū);如果獲取不到對應的字節(jié)碼或者其他原因失敗，返回異常給loadClass(…)， loadClass(…)轉而拋異常，終止加載過程(注意：這里的異常種類不止一種)。

　　這里就不在細說了，一般熟悉類加載器這部分知識應該都比較熟悉，我們來繼續(xù)將，類加載器怎么實現安全的!

　　類裝載器的體系結構是通過剔除裝作被信任的不可靠的類，來保護那些可信任類庫的邊界，如果某個惡意的類可以成功的欺騙Java虛擬機，使得Java虛擬機相信它是一個來自可靠源的可信類，那么，這個惡意類就可能突破沙箱的阻隔，為了防止這樣的情況，類裝載器體系結構阻塞了危機Java虛擬機運行時安全的潛在途徑。

　　在雙親委派的情況下，啟動類裝載器會在最可信的類庫-核心Java API-中檢查每個被裝載的類型，然后，才依次到標準擴展，類路徑上的本地類文件中檢查，所以，如果網絡類裝載器裝載的某個代碼執(zhí)行時，想要從網絡上下載一個和Java API中某個類型同名的類，例如Java.lang.Integer,它將不能成功，如果Java.lang.Integer的class文件已經存在，將不會再裝載，它只能使用由它的雙親委派返回的類，這個類是由啟動類裝載器裝載的，用這種方法，類裝載器的體系結構就可以防止不可靠的代碼用自己的版本來替代可信任的類。

　　還有一種可能，就是，我不是去替代你這個被信任的類，我是要在你被信任的類庫里插入一個全新的類型，會怎么樣?

　　比如我們下載了一個類Java.lang.virus，這個請求一路向上委派給啟動裝載器，但它無法找到這個成員，同時在已擴展以及本地類路徑中也找不到，你的類裝載器將試圖從網絡上下載這個類。

　　Java允許同一個包里面的類擁有相同的權限，而包外面的類則沒有這個權限，你的類加載進Java.lang 包，那么也就擁有這個包的所有權限，它就可以其中被信任的類，這樣的一個不可靠的類的存在太可怕了!

　　Java虛擬機是這樣布置的，不同的類加載器加載的類放在不同的包里，于是，這個從網絡上下載的類所屬于的包跟啟動類裝載的類并不是在一個包里面，這樣，它就得不到其他可信任類的信息。而兩個包之間要允許可見，必須滿足同一個類裝載器裝載，這樣就可以避免不可靠類的侵犯。