為了深入了解Java的ClassLoader機制，我們先來做以下實驗：
package Java.lang;
public class Test {
public static void main(String[] args) {
char[] c = "1234567890".toCharArray();
String s = new String(0, 10, c);
}
}
String類有一個Package權限的構造函數String（int offset， int length， char[] array），按照默認的訪問權限，由於Test屬於Java.lang包，因此理論上應該可以訪問String的這個構造函數。編譯通過！執行時結果如下：
Exception in thread "main" Java.lang.SecurityException:
Prohibited package name:
Java.lang
at Java.lang.ClassLoader.defineClass(Unknown Source)
at Java.security.SecureClassLoader.defineClass(Unknown Source)
at Java.Net.URLClassLoader.defineClass(Unknown Source)
at Java.Net.URLClassLoader.Access$100(Unknown Source)
at Java.Net.URLClassLoader$1.run(Unknown Source)
at Java.security.AccessController.doPrivileged(Native Method)
at Java.Net.URLClassLoader.findClass(Unknown Source)
at Java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at Java.lang.ClassLoader.loadClass(Unknown Source)
at Java.lang.ClassLoader.loadClassInternal(Unknown Source)
奇怪吧？要弄清為什麼會有SecurityException，就必須搞清楚ClassLoader的機制。
Java的ClassLoader就是用來動態裝載class的，ClassLoader對一個class只會裝載一次，JVM使用的ClassLoader一共有4種：
啟動類裝載器，標准擴展類裝載器，類路徑裝載器和網絡類裝載器。
這4種ClassLoader的優先級依次從高到低，使用所謂的“雙親委派模型”。確切地說，如果一個網絡類裝載器被請求裝載一個java.lang.Integer，它會首先把請求發送給上一級的類路徑裝載器，如果返回已裝載，則網絡類裝載器將不會裝載這個java.lang.Integer，如果上一級的類路徑裝載器返回未裝載，它才會裝載Java.lang.Integer.
類似的，類路徑裝載器收到請求後（無論是直接請求裝載還是下一級的ClassLoader上傳的請求），它也會先把請求發送到上一級的標准擴展類裝載器，這樣一層一層上傳，於是啟動類裝載器優先級最高，如果它按照自己的方式找到了java.lang.Integer，則下面的ClassLoader 都不能再裝載java.lang.Integer，盡管你自己寫了一個java.lang.Integer，試圖取代核心庫的Java.lang.Integer是不可能的，因為自己寫的這個類根本無法被下層的ClassLoader裝載。
再說說Package權限。Java語言規定，在同一個包中的class，如果沒有修飾符，默認為Package權限，包內的class都可以訪問。但是這還不夠准確。確切的說，只有由同一個ClassLoader裝載的class才具有以上的Package權限。比如啟動類裝載器裝載了java.lang.String，類路徑裝載器裝載了我們自己寫的Java.lang.Test，它們不能互相訪問對方具有Package權限的方法。這樣就阻止了惡意代碼訪問核心類的Package權限方法。
