要深入了解ClassLoader，首先就要知道ClassLoader是用來(lái)干什么的，顧名思義，它就是用來(lái)加載Class文件到JVM，以供程序使用的。我們知道，java程序可以動(dòng)態(tài)加載類(lèi)定義，而這個(gè)動(dòng)態(tài)加載的機(jī)制就是通過(guò)ClassLoader來(lái)實(shí)現(xiàn)的，所以可想而知ClassLoader的重要性如何。

看到這里，可能有的朋友會(huì)想到一個(gè)問(wèn)題，那就是既然ClassLoader是用來(lái)加載類(lèi)到JVM中的，那么ClassLoader又是如何被加載呢？難道它不是java的類(lèi)？

沒(méi)有錯(cuò)，在這里確實(shí)有一個(gè)ClassLoader不是用java語(yǔ)言所編寫(xiě)的，而是JVM實(shí)現(xiàn)的一部分，這個(gè)ClassLoader就是bootstrap classloader（啟動(dòng)類(lèi)加載器），這個(gè)ClassLoader在JVM運(yùn)行的時(shí)候加載java核心的API以滿(mǎn)足java程序最基本的需求，其中就包括用戶(hù)定義的ClassLoader，這里所謂的用戶(hù)定義是指通過(guò)java程序?qū)崿F(xiàn)的ClassLoader，一個(gè)是ExtClassLoader，這個(gè)ClassLoader是用來(lái)加載java的擴(kuò)展API的，也就是/lib/ext中的類(lèi)，一個(gè)是AppClassLoader，這個(gè)ClassLoader是用來(lái)加載用戶(hù)機(jī)器上CLASSPATH設(shè)置目錄中的Class的，通常在沒(méi)有指定ClassLoader的情況下，程序員自定義的類(lèi)就由該ClassLoader進(jìn)行加載。

當(dāng)運(yùn)行一個(gè)程序的時(shí)候，JVM啟動(dòng)，運(yùn)行bootstrap classloader，該ClassLoader加載java核心API（ExtClassLoader和AppClassLoader也在此時(shí)被加載），然后調(diào)用ExtClassLoader加載擴(kuò)展API，最后AppClassLoader加載CLASSPATH目錄下定義的Class，這就是一個(gè)程序最基本的加載流程。

上面大概講解了一下ClassLoader的作用以及一個(gè)最基本的加載流程，接下來(lái)將講解一下ClassLoader加載的方式，這里就不得不講一下ClassLoader在這里使用了雙親委托模式進(jìn)行類(lèi)加載。

每一個(gè)自定義ClassLoader都必須繼承ClassLoader這個(gè)抽象類(lèi)，而每個(gè)ClassLoader都會(huì)有一個(gè)parent ClassLoader，我們可以看一下ClassLoader這個(gè)抽象類(lèi)中有一個(gè)getParent()方法，這個(gè)方法用來(lái)返回當(dāng)前ClassLoader的parent，注意，這個(gè)parent不是指的被繼承的類(lèi)，而是在實(shí)例化該ClassLoader時(shí)指定的一個(gè)ClassLoader，如果這個(gè)parent為null，那么就默認(rèn)該ClassLoader的parent是bootstrap classloader，這個(gè)parent有什么用呢？

我們可以考慮這樣一種情況，假設(shè)我們自定義了一個(gè)ClientDefClassLoader，我們使用這個(gè)自定義的ClassLoader加載java.lang.String，那么這里String是否會(huì)被這個(gè)ClassLoader加載呢？事實(shí)上java.lang.String這個(gè)類(lèi)并不是被這個(gè)ClientDefClassLoader加載，而是由bootstrap classloader進(jìn)行加載，為什么會(huì)這樣？實(shí)際上這就是雙親委托模式的原因，因?yàn)樵谌魏我粋€(gè)自定義ClassLoader加載一個(gè)類(lèi)之前，它都會(huì)先委托它的父親ClassLoader進(jìn)行加載，只有當(dāng)父親ClassLoader無(wú)法加載成功后，才會(huì)由自己加載，在上面這個(gè)例子里，因?yàn)閖ava.lang.String是屬于java核心API的一個(gè)類(lèi)，所以當(dāng)使用ClientDefClassLoader加載它的時(shí)候，該ClassLoader會(huì)先委托它的父親ClassLoader進(jìn)行加載，上面講過(guò)，當(dāng)ClassLoader的parent為null時(shí)，ClassLoader的parent就是bootstrap classloader，所以在ClassLoader的最頂層就是bootstrap classloader，因此最終委托到bootstrap classloader的時(shí)候，bootstrap classloader就會(huì)返回String的Class。

我們來(lái)看一下ClassLoader中的一段源代碼：

 protected synchronized Class loadClass(String name, boolean resolve) 
  throws ClassNotFoundException 
    { 
  // 首先檢查該name指定的class是否有被加載 
  Class c = findLoadedClass(name); 
  if (c == null) { 
    try { 
    if (parent != null) { 
      //如果parent不為null，則調(diào)用parent的loadClass進(jìn)行加載 
   = parent.loadClass(name, false); 
    } else { 
      //parent為null，則調(diào)用BootstrapClassLoader進(jìn)行加載 
      c = findBootstrapClass0(name); 
    } 
    } catch (ClassNotFoundException e) { 
      //如果仍然無(wú)法加載成功，則調(diào)用自身的findClass進(jìn)行加載       
      c = findClass(name); 
    } 
  } 
  if (resolve) { 
    resolveClass(c); 
  } 
  return c; 
    } 

從上面一段代碼中，我們可以看出一個(gè)類(lèi)加載的大概過(guò)程與之前我所舉的例子是一樣的，而我們要實(shí)現(xiàn)一個(gè)自定義類(lèi)的時(shí)候，只需要實(shí)現(xiàn)findClass方法即可。

為什么要使用這種雙親委托模式呢？

第一個(gè)原因就是因?yàn)檫@樣可以避免重復(fù)加載，當(dāng)父親已經(jīng)加載了該類(lèi)的時(shí)候，就沒(méi)有必要子ClassLoader再加載一次。

第二個(gè)原因就是考慮到安全因素，我們?cè)囅胍幌拢绻皇褂眠@種委托模式，那我們就可以隨時(shí)使用自定義的String來(lái)動(dòng)態(tài)替代java核心api中定義類(lèi)型，這樣會(huì)存在非常大的安全隱患，而雙親委托的方式，就可以避免這種情況，因?yàn)镾tring已經(jīng)在啟動(dòng)時(shí)被加載，所以用戶(hù)自定義類(lèi)是無(wú)法加載一個(gè)自定義的ClassLoader。

上面對(duì)ClassLoader的加載機(jī)制進(jìn)行了大概的介紹，接下來(lái)不得不在此講解一下另外一個(gè)和ClassLoader相關(guān)的類(lèi)，那就是Class類(lèi)，每個(gè)被ClassLoader加載的class文件，最終都會(huì)以Class類(lèi)的實(shí)例被程序員引用，我們可以把Class類(lèi)當(dāng)作是普通類(lèi)的一個(gè)模板，JVM根據(jù)這個(gè)模板生成對(duì)應(yīng)的實(shí)例，最終被程序員所使用。

我們看到在Class類(lèi)中有個(gè)靜態(tài)方法forName，這個(gè)方法和ClassLoader中的loadClass方法的目的一樣，都是用來(lái)加載class的，但是兩者在作用上卻有所區(qū)別。
Class<?> loadClass(String name)
Class<?> loadClass(String name, boolean resolve)
我們看到上面兩個(gè)方法聲明，第二個(gè)方法的第二個(gè)參數(shù)是用于設(shè)置加載類(lèi)的時(shí)候是否連接該類(lèi)，true就連接，否則就不連接。

說(shuō)到連接，不得不在此做一下解釋?zhuān)贘VM加載類(lèi)的時(shí)候，需要經(jīng)過(guò)三個(gè)步驟，裝載、連接、初始化。裝載就是找到相應(yīng)的class文件，讀入JVM，初始化就不用說(shuō)了，最主要就說(shuō)說(shuō)連接。

連接分三步，第一步是驗(yàn)證class是否符合規(guī)格，第二步是準(zhǔn)備，就是為類(lèi)變量分配內(nèi)存同時(shí)設(shè)置默認(rèn)初始值，第三步就是解釋?zhuān)@步就是可選的，根據(jù)上面loadClass方法的第二個(gè)參數(shù)來(lái)判定是否需要解釋?zhuān)^的解釋根據(jù)《深入JVM》這本書(shū)的定義就是根據(jù)類(lèi)中的符號(hào)引用查找相應(yīng)的實(shí)體，再把符號(hào)引用替換成一個(gè)直接引用的過(guò)程。有點(diǎn)深?yuàn)W吧，呵呵，在此就不多做解釋了，想具體了解就翻翻《深入JVM吧》，呵呵，再這樣一步步解釋下去，那就不知道什么時(shí)候才能解釋得完了。

我們?cè)賮?lái)看看那個(gè)兩個(gè)參數(shù)的loadClass方法，在JAVA API 文檔中，該方法的定義是protected，那也就是說(shuō)該方法是被保護(hù)的，而用戶(hù)真正應(yīng)該使用的方法是一個(gè)參數(shù)的那個(gè)，一個(gè)參數(shù)的loadclass方法實(shí)際上就是調(diào)用了兩個(gè)參數(shù)的方法，而第二個(gè)參數(shù)默認(rèn)為false，因此在這里可以看出通過(guò)loadClass加載類(lèi)實(shí)際上就是加載的時(shí)候并不對(duì)該類(lèi)進(jìn)行解釋?zhuān)虼艘膊粫?huì)初始化該類(lèi)。而Class類(lèi)的forName方法則是相反，使用forName加載的時(shí)候就會(huì)將Class進(jìn)行解釋和初始化，forName也有另外一個(gè)版本的方法，可以設(shè)置是否初始化以及設(shè)置ClassLoader，在此就不多講了。

不知道上面對(duì)這兩種加載方式的解釋是否足夠清楚，就在此舉個(gè)例子吧，例如JDBC DRIVER的加載，我們?cè)诩虞dJDBC驅(qū)動(dòng)的時(shí)候都是使用的forName而非是ClassLoader的loadClass方法呢？我們知道，JDBC驅(qū)動(dòng)是通過(guò)DriverManager，必須在DriverManager中注冊(cè)，如果驅(qū)動(dòng)類(lèi)沒(méi)有被初始化，則不能注冊(cè)到DriverManager中，因此必須使用forName而不能用loadClass。

通過(guò)ClassLoader我們可以自定義類(lèi)加載器，定制自己所需要的加載方式，例如從網(wǎng)絡(luò)加載，從其他格式的文件加載等等都可以，其實(shí)ClassLoader還有很多地方?jīng)]有講到，例如ClassLoader內(nèi)部的一些實(shí)現(xiàn)等等，

  通過(guò)此文，小編希望大家對(duì)ClassLoader 機(jī)制有所了解,謝謝支持！ 

最新評(píng)論