Java中一共有四個類加載器，之所以叫類加載器，是程序要用到某個類的時候，要用類加載器載入內存。
這四個類加載器分別為：Bootstrap ClassLoader、Extension ClassLoader、AppClassLoader
和URLClassLoader，他們的作用其實從名字就可以大概推測出來了。其中AppClassLoader在很多地方被叫做System ClassLoader
Bootstrap ClassLoader是在JVM開始運行的時候加載java的核心類，是用C++編寫的，它用來加載核心類庫，在JVM源代碼中這樣寫道：
static const char classpathFormat[] =
"%/lib/rt.jar:"
"%/lib/i18n.jar:"
"%/lib/sunrsasign.jar:"
"%/lib/jsse.jar:"
"%/lib/jce.jar:"
"%/lib/charsets.jar:"
"%/classes";
Extension ClassLoader是用來加載擴展類，即/lib/ext中的類。
AppClassLoader用來加載Classpath的類，是和我們關系最密切的類。
URLClassLoader用來加載網絡上遠程的類，暫且不討論。
它們之間的關系:
1.Parent-Child，按順序從大到小。不是簡單的繼承關系。
2.ClassLoader有個getParent的方法，但是Ext ClassLoader調用後得到的是null，bootstrap是JVM自己的，用戶看不到。
3.classloader的委托機制：當等級比較低的ClassLoader要加載某個類的時候，它首先會請求Parent加載器來加載，Parent再請求它的Parent
比如現在Ext要加載了，它往上請求。如果最大的Bootstrap找不到，那麼Boot會叫Ext自己找找，Ext找不到，是不會讓下一級的App去找的，此時就報出ClassNotFoundException
4.類A調用類B，B會要求調用它的類的類加載器來加載它，也就是B會要求加載A的加載器來加載B。這就會有個問題，如果他們在一起，那沒關系，肯定某個classloader會把它們倆都加載好。但是如果A在/lib/ext文件夾中，而B在Classpath中呢？過程是這樣的首先加載A，那麼一層層上到Bootstrap Classloader，boot沒找到所以ext自己找，找到了，沒問題；加載B，因為A調用了B，所以也從bootstrap來找，沒找到，然後A的ext classloader來找還是沒找到，但是再也不會往下調用了，於是報出ClassNotFoundException。
但是現實生活中有很多應用，比如JDBC核心方法在核心庫而驅動在擴展庫，是必定在兩個地方的，那怎麼辦呢？要用到Context ClassLoader我們在建立一個線程Thread的時候，可以為這個線程通過setContextClassLoader方法來指定一個合適的classloader作為這個線程的context classloader，當此線程運行的時候，我們可以通過getContextClassLoader方法來獲得此context classloader，就可以用它來載入我們所需要的Class。默認的是system classloader。利用這個特性，我們可以“打破”classloader委托機制了，父classloader可以獲得當前線程的context classloader，而這個context classloader可以是它的子classloader或者其他的classloader，那麼父classloader就可以從其獲得所需的 Class，這就打破了只能向父classloader請求的限制了。這個機制可以滿足當我們的classpath是在運行時才確定,並由定制的 classloader加載的時候,由system classloader(即在jvm classpath中)加載的class可以通過context classloader獲得定制的classloader並加載入特定的class(通常是抽象類和接口,定制的classloader中是其實現),例如web應用中的servlet就是用這種機制加載的.
