Classloader的兩個任務：
1、Classloader負責將Class加載到JVM中，並且確定由那個ClassLoader來加載（父優先的等級加載機制）。
2、還有一個任務就是將Class字節碼重新解釋為JVM統一要求的格式
Classloader的分類：
Java類加載器采用雙親委派模型：
-
BootStrapClassLoader：啟動類加載器，該ClassLoader是jvm在啟動時創建的，用於加載 $JAVA_HOME/jre/lib下面的類庫（或者通過參數-Xbootclasspath指定）。由於引導類加載器涉及到虛擬機本地實現細節，開發者無法直接獲取到啟動類加載器的引用，所以不能直接通過引用進行操作。
-
ExtClassLoader：擴展類加載器，該ClassLoader是在sun.misc.Launcher里作為一個內部類ExtClassLoader定義的（即 sun.misc.Launcher$ExtClassLoader），ExtClassLoader會加載 $JAVA_HOME/jre/lib/ext下的類庫（或者通過參數-Djava.ext.dirs指定）。
-
AppClassLoader：應用程序類加載器，該ClassLoader同樣是在sun.misc.Launcher里作為一個內部類AppClassLoader定義的（即 sun.misc.Launcher$AppClassLoader），AppClassLoader會加載java環境變量CLASSPATH所指定的路徑下的類庫，而CLASSPATH所指定的路徑可以通過System.getProperty("java.class.path")獲取；當然，該變量也可以覆蓋，可以使用參數-cp，例如：java -cp 路徑 （可以指定要執行的class目錄）。
-
CustomClassLoader：自定義類加載器，該ClassLoader是指我們自定義的ClassLoader，比如tomcat的StandardClassLoader屬於這一類；當然，大部分情況下使用AppClassLoader就足夠了。
ClassLoader初始化源碼
上述四種類加載器中CustomClassLoader是用戶自定義的，BootStrapClassLoader是jvm創建的，就不展示了；這里展示下AppClassLoader和ExtClassLoader的啟動過程
public Launcher(){ ExtClassLoader extclassloader; try{ extclassloader = ExtClassLoader.getExtClassLoader(); } catch(IOException ioexception) { throw new InternalError("Could not create extension class loader"); } try{ loader = AppClassLoader.getAppClassLoader(extclassloader); } catch(IOException ioexception1){ throw new InternalError("Could not create application class loader"); } Thread.currentThread().setContextClassLoader(loader); String s = System.getProperty("java.security.manager"); if(s != null){ SecurityManager securitymanager = null; if("".equals(s) || "default".equals(s)) securitymanager = new SecurityManager(); else try{ securitymanager = (SecurityManager)loader.loadClass(s).newInstance(); } catch(IllegalAccessException illegalaccessexception) { } catch(InstantiationException instantiationexception) { } catch(ClassNotFoundException classnotfoundexception) { } catch(ClassCastException classcastexception) { } if(securitymanager != null) System.setSecurityManager(securitymanager); else throw new InternalError((new StringBuilder()).append("Could not create SecurityManager: ").append(s).toString()); } }
可以看到在Launcher構造函數的執行過程如下：
-
通過ExtClassLoader.getExtClassLoader()創建了ExtClassLoader；
-
通過AppClassLoader.getAppClassLoader(ExtClassLoader)創建了AppClassLoader，並將ExtClassLoader設為AppClassLoader的parent ClassLoader；
-
通過Thread.currentThread().setContextClassLoader(loader)把AppClassLoader設為線程的上下文 ClassLoader；
-
根據jvm參數-Djava.security.manager創建安全管理器（安全管理器的相關內容會在后續博客安全管理器及Java API中介紹），此時jvm會設置系統屬性"java.security.manager"為空字符串""。
再貼下ExtClassLoader源碼：
static class ExtClassLoader extends URLClassLoader { private File[] dirs; public static ExtClassLoader getExtClassLoader() throws IOException { // 用調getExtDirs()方法取獲配置的擴展類路徑 final File[] dirs = getExtDirs(); try { // 應用getExtDirs()方法返回的路徑生成一個新的ClassLoader實例 return (ExtClassLoader) AccessController.doPrivileged(new PrivilegedExceptionAction() { public Object run() throws IOException { int len = dirs.length; for (int i = 0; i < len; i++) { MetaIndex.registerDirectory(dirs[i]); } return new ExtClassLoader(dirs); } }); } catch (java.security.PrivilegedActionException e) { throw (IOException) e.getException(); } } // 再看這個方法 private static File[] getExtDirs() { // 取獲配置的擴展類路徑 String s = System.getProperty("java.ext.dirs"); File[] dirs; if (s != null) { StringTokenizer st = new StringTokenizer(s, File.pathSeparator); int count = st.countTokens(); dirs = new File[count]; for (int i = 0; i < count; i++) { dirs[i] = new File(st.nextToken()); } } else { dirs = new File[0]; } return dirs; } // 其他碼代略 ... }
反編譯的源碼，大家將就看下；這里大家關注下getExtDirs()這個方法，它會獲取屬性"java.ext.dirs"所對應的值，然后通過系統分隔符分割，然后加載分割后的字符串對應的目錄作為ClassLoader的類加載庫。
下面看看AppClassLoader源碼：
public static ClassLoader getAppClassLoader(ClassLoader classloader) throws IOException{ String s = System.getProperty("java.class.path"); File afile[] = s != null ? Launcher.getClassPath(s) : new File[0]; return (AppClassLoader)AccessController.doPrivileged(new PrivilegedAction(s, afile, classloader) { public Object run() { URL aurl[] = s != null ? Launcher.pathToURLs(path) : new URL[0]; return new AppClassLoader(aurl, extcl); } final String val$s; final File val$path[]; final ClassLoader val$extcl; { s = s1; path = afile; extcl = classloader; super(); } }); }
首先獲取"java.class.path"對應的屬性，並轉換為URL[]並設置為ClassLoader的類加載庫，注意這里的方法入參classloader就是ExtClassLoader，在創AppClassLoader會傳入ExtClassLoader作為parent ClassLoader。
上面就是ClassLoader的啟動和初始化過程，后面會把loader作為應用程序的默認ClassLoader使用，看下面的測試用例:
public static void main(String... args) { ClassLoader loader = Test.class.getClassLoader(); System.err.println(loader); while (loader != null) { loader = loader.getParent(); System.err.println(loader); } }
可以看到ClassLoader的層次結構，輸出結果為：
ClassLoader雙親委派機制源碼
前面談到了ClassLoader的幾類加載器，而ClassLoader使用雙親委派機制來加載class文件的。
ClassLoader的雙親委派機制是這樣的（這里先忽略掉自定義類加載器CustomClassLoader）：
-
當AppClassLoader加載一個class時，它首先不會自己去嘗試加載這個類，而是把類加載請求委派給父類加載器ExtClassLoader去完成。
-
當ExtClassLoader加載一個class時，它首先也不會自己去嘗試加載這個類，而是把類加載請求委派給BootStrapClassLoader去完成。
-
如果BootStrapClassLoader加載失敗（例如在$JAVA_HOME/jre/lib里未查找到該class），會使用ExtClassLoader來嘗試加載；
-
若ExtClassLoader也加載失敗，則會使用AppClassLoader來加載，如果AppClassLoader也加載失敗，則會報出異常ClassNotFoundException。
下面貼下ClassLoader的loadClass(String name, boolean resolve)源碼：
protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException { // First, check if the class has already been loaded Class c = findLoadedClass(name); if (c == null) { try { if (parent != null) { c = parent.loadClass(name, false); } else { c = findBootstrapClassOrNull(name); } } catch (ClassNotFoundException e) { // ClassNotFoundException thrown if class not found // from the non-null parent class loader } if (c == null) { // If still not found, then invoke findClass in order // to find the class. c = findClass(name); } } if (resolve) { resolveClass(c); } return c; }
代碼很明朗：首先找緩存（findLoadedClass），沒有的話就判斷有沒有parent，有的話就用parent來遞歸的loadClass，然而ExtClassLoader並沒有設置parent，則會通過findBootstrapClassOrNull來加載class，而findBootstrapClassOrNull則會通過JNI方法”private native Class findBootstrapClass(String name)“來使用BootStrapClassLoader來加載class。
然后如果parent未找到class，則會調用findClass來加載class，findClass是一個protected的空方法，可以覆蓋它以便自定義class加載過程。
另外，雖然ClassLoader加載類是使用loadClass方法，但是鼓勵用 ClassLoader 的子類重寫 findClass(String)，而不是重寫loadClass，這樣就不會覆蓋了類加載默認的雙親委派機制。
雙親委派機制為什么安全
前面談到雙親委派機制是為了安全而設計的，但是為什么就安全了呢？舉個例子，ClassLoader加載的class文件來源很多，比如編譯器編譯生成的class、或者網絡下載的字節碼。而一些來源的class文件是不可靠的，比如我可以自定義一個java.lang.Integer類來覆蓋jdk中默認的Integer類，例如下面這樣：
package java.lang; /** * hack */ public class Integer { public Integer(int value) { System.exit(0); } }
初始化這個Integer的構造器是會退出JVM，破壞應用程序的正常進行，如果使用雙親委派機制的話該Integer類永遠不會被調用，以為委托BootStrapClassLoader加載后會加載JDK中的Integer類而不會加載自定義的這個，可以看下下面這測試個用例：
public static void main(String... args) { Integer i = new Integer(1); System.err.println(i); }
執行時JVM並未在new Integer(1)時退出，說明未使用自定義的Integer，於是就保證了安全性。