這四個類加載器分別為: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的類,是和我們關(guān)系最密切的類。 URLClassLoader用來加載網(wǎng)絡(luò)上遠程的類,暫且不討論。 它們之間的關(guān)系: 1.Parent-Child,按順序從大到小。不是簡單的繼承關(guān)系。 2.ClassLoader有個getParent的方法,但是Ext ClassLoader調(diào)用后得到的是null,bootstrap是JVM自己的,用戶看不到。 3.classloader的委托機制:當?shù)燃壉容^低的ClassLoader要加載某個類的時候,它首先會請求Parent加載器來加載,Parent再請求它的Parent 比如現(xiàn)在Ext要加載了,它往上請求。如果最大的Bootstrap找不到,那么Boot會叫Ext自己找找,Ext找不到,是不會讓下一級的App去找的,此時就報出ClassNotFoundException 4.類A調(diào)用類B,B會要求調(diào)用它的類的類加載器來加載它,也就是B會要求加載A的加載器來加載B。這就會有個問題,如果他們在一起,那沒關(guān)系,肯定某個classloader會把它們倆都加載好。但是如果A在/lib/ext文件夾中,而B在Classpath中呢?過程是這樣的首先加載A,那么一層層上到Bootstrap Classloader,boot沒找到所以ext自己找,找到了,沒問題;加載B,因為A調(diào)用了B,所以也從bootstrap來找,沒找到,然后A的ext classloader來找還是沒找到,但是再也不會往下調(diào)用了,于是報出ClassNotFoundException。 但是現(xiàn)實生活中有很多應(yīng)用,比如JDBC核心方法在核心庫而驅(qū)動在擴展庫,是必定在兩個地方的,那怎么辦呢?要用到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中是其實現(xiàn)),例如web應(yīng)用中的servlet就是用這種機制加載的. |
|
來自: yandao1117 > 《我的圖書館》