如何深入探索Groovy的ClassLoader體系

如何深入探索Groovy的ClassLoader體系，很多新手對(duì)此不是很清楚，為了幫助大家解決這個(gè)難題，下面小編將為大家詳細(xì)講解，有這方面需求的人可以來(lái)學(xué)習(xí)下，希望你能有所收獲。

Groovy中定義了不少ClassLoader，介紹其中絕大多數(shù)Groovy腳本都會(huì)涉及到的，也是最主要的3個(gè)ClassLoader：RootLoader、GroovyClassLoader和GroovyClassLoader.InnerLoader。

注：以下分析的Groovy源代碼來(lái)自Groovy 2.1.3。

Java的ClassLoader

顧名思義，Java的ClassLoader就是類的裝載器，它使JVM可以動(dòng)態(tài)的載入Java類，JVM并不需要知道從什么地方（本地文件、網(wǎng)絡(luò)等）載入Java類，這些都由ClassLoader完成。

可以說(shuō)，ClassLoader是Class的命名空間。同一個(gè)名字的類可以由多個(gè)ClassLoader載入，由不同ClassLoader載入的相同名字的類將被認(rèn)為是不同的類；而同一個(gè)ClassLoader對(duì)同一個(gè)名字的類只能載入一次。

Java的ClassLoader有一個(gè)著名的雙親委派模型（Parent Delegation Model）：除了Bootstrap ClassLoader外，每個(gè)ClassLoader都有一個(gè)parent的ClassLoader，沿著parent最終會(huì)追索到Bootstrap ClassLoader；當(dāng)一個(gè)ClassLoader要載入一個(gè)類時(shí)，會(huì)首先委派給parent，如果parent能載入這個(gè)類，則返回，否則這個(gè)ClassLoader才會(huì)嘗試去載入這個(gè)類。

Java的ClassLoader體系如下，其中箭頭指向的是該ClassLoader的parent：

Bootstrap ClassLoader           ↑  Extension ClassLoader           ↑  System ClassLoader           ↑  User Custom ClassLoader  // 不一定有

Groovy的ClassLoader

我們首先通過(guò)一個(gè)腳本來(lái)看一下，一個(gè)Groovy腳本的ClassLoader以及它的祖先們分別是什么：

def cl = this.class.classLoader  while (cl) {      println cl      cl = cl.parent  }

輸出如下： 

groovy.lang.GroovyClassLoader$InnerLoader@18622f3  groovy.lang.GroovyClassLoader@147c1db  org.codehaus.groovy.tools.RootLoader@186db54  sun.misc.Launcher$AppClassLoader@192d342  sun.misc.Launcher$ExtClassLoader@6b97fd

我們從而得出Groovy的ClassLoader體系：

            null                      // 即Bootstrap ClassLoader               ↑  sun.misc.Launcher.ExtClassLoader      // 即Extension ClassLoader               ↑  sun.misc.Launcher.AppClassLoader      // 即System ClassLoader               ↑  org.codehaus.groovy.tools.RootLoader  // 以下為User Custom ClassLoader               ↑  groovy.lang.GroovyClassLoader               ↑  groovy.lang.GroovyClassLoader.InnerLoader

下面我們分別介紹一下RootLoader、GroovyClassLoader和GroovyClassLoader.InnerLoader。

Groovy腳本啟動(dòng)過(guò)程

要介紹RootLoader前，我們需要介紹一下Groovy腳本的啟動(dòng)過(guò)程。

當(dāng)我們?cè)诿钚休斎搿癵roovy SomeScript”來(lái)運(yùn)行腳本時(shí)，調(diào)用的是shell腳本$GROOVY_HOME/bin/groovy：

#…   startGroovy groovy.ui.GroovyMain "$@"

其中startGroovy定義在$GROOVY_HOME/bin/startGroovy中： 

#…  STARTER_CLASSPATH="$GROOVY_HOME/lib/groovy-2.1.3.jar" #…  startGroovy ( ) {      CLASS=$1     shift      # Start the Profiler or the JVM      if $useprofiler ; then          runProfiler      else         exec "$JAVACMD" $JAVA_OPTS \              -classpath "$STARTER_CLASSPATH" \              -Dscript.name="$SCRIPT_PATH" \              -Dprogram.name="$PROGNAME" \              -Dgroovy.starter.conf="$GROOVY_CONF" \              -Dgroovy.home="$GROOVY_HOME" \              -Dtools.jar="$TOOLS_JAR" \              $STARTER_MAIN_CLASS \              --main $CLASS \              --conf "$GROOVY_CONF" \              --classpath "$CP" \              "$@"     fi  }   STARTER_MAIN_CLASS=org.codehaus.groovy.tools.GroovyStarter

我們可以發(fā)現(xiàn)，這里其實(shí)是通過(guò)java啟動(dòng)了org.codehaus.groovy.tools.GroovyStarter，然后把“--main groovy.ui.GroovyMain”作為參數(shù)傳給GroovyStarter，***又把SomeScript作為參數(shù)傳給GroovyMain。注意，這里只把$GROOVY_HOME/lib/groovy-2.1.3.jar作為classpath參數(shù)傳給了JVM，而不包含Groovy依賴的第三方j(luò)ar包。

我們來(lái)看一下GroovyStarter的源代碼（其中省略了異常處理的代碼）：

public static void rootLoader(String args[]) {      String conf = System.getProperty("groovy.starter.conf",null);      LoaderConfiguration lc = new LoaderConfiguration();      // 這里省略了解析命令行參數(shù)的代碼      // load configuration file      if (conf!=null) {          lc.configure(new FileInputStream(conf));      }      // create loader and execute main class      ClassLoader loader = new RootLoader(lc);      Class c = loader.loadClass(lc.getMainClass()); // 使用RootLoader載入GroovyMain      Method m = c.getMethod("main", new Class[]{String[].class});      m.invoke(null, new Object[]{newArgs}); // 調(diào)用GroovyMain的main方法  }  //   public static void main(String args[]) {      rootLoader(args);  }

這里的LoaderConfiguration是用來(lái)做什么的呢？它是用來(lái)解析$GROOVY_HOME/conf/groovy-starter.conf文件的，該文件內(nèi)容如下（去掉了注釋部分）：

load !{groovy.home}/lib/*.jar  load !{user.home}/.groovy/lib/*.jar  load ${tools.jar}

這表示，將$GROOVY_HOME/lib/*.jar、$HOME/.groovy/lib/*.jar以及tools.jar加入到RootLoader的classpath中，可以看出，這里包含了Groovy依賴的第三方j(luò)ar包。

接下來(lái)，我們來(lái)看一下GroovyMain的源代碼。GroovyMain的main函數(shù)進(jìn)去之后，最終會(huì)到達(dá)processOnce方法：

private void processOnce() throws CompilationFailedException, IOException {      GroovyShell groovy = new GroovyShell(conf);       if (isScriptFile) {          if (isScriptUrl(script)) {              groovy.run(getText(script), script.substring(script.lastIndexOf("/") + 1), args);          } else {              groovy.run(huntForTheScriptFile(script), args); // 本地腳本文件執(zhí)行這行          }      } else {          groovy.run(script, "script_from_command_line", args);      }  }

可以看到，GroovyMain是通過(guò)GroovyShell來(lái)執(zhí)行腳本文件的，GroovyShell的具體執(zhí)行腳本的代碼我們不再分析，我們只看GroovyShell的構(gòu)造函數(shù)中初始化ClassLoader的代碼：

final ClassLoader parentLoader = (parent!=null)?parent:GroovyShell.class.getClassLoader();  this.loader = AccessController.doPrivileged(new PrivilegedAction<GroovyClassLoader>() {      public GroovyClassLoader run() {          return new GroovyClassLoader(parentLoader,config);      }  });

由此可見(jiàn)，GroovyShell使用了GroovyClassLoader來(lái)加載類，而該GroovyClassLoader的parent即為GroovyShell的ClassLoader，也就是GroovyMain的ClassLoader，也就是RootLoader。

***來(lái)總結(jié)一下Groovy腳本的啟動(dòng)流程（括號(hào)中表示使用的ClassLoader）：

GroovyStarter      ↓ (RootLoader)  GroovyMain      ↓  GroovyShell      ↓ (GroovyClassLoader)  SomeScript

RootLoader

RootLoader作為Groovy的根ClassLoader，負(fù)責(zé)加載Groovy及其依賴的第三方庫(kù)中的類。它管理了Groovy的classpath，我們可以通過(guò)$GROOVY_HOME/conf/groovy-starter.conf文件或groovy的命令行參數(shù)“-classpath”往其中添加路徑。注意，這有別于java的命令行參數(shù)“-classpath”定義的classpath，RootLoader中的classpath對(duì)Java原有的ClassLoader是不可見(jiàn)的。

我們先通過(guò)一個(gè)腳本來(lái)看一下RootLoader是如何體現(xiàn)為Groovy的classpath管理者的：

class C {}   println this.class.classLoader  println C.classLoader  println()   println groovy.ui.GroovyMain.classLoader  println org.objectweb.asm.ClassVisitor.classLoader  println()   println String.classLoader  println()   println org.codehaus.groovy.tools.GroovyStarter.classLoader  println ClassLoader.systemClassLoader.findLoadedClass('org.codehaus.groovy.tools.GroovyStarter')?.classLoader  println()

輸出如下： 

groovy.lang.GroovyClassLoader$InnerLoader@1ba6076 groovy.lang.GroovyClassLoader$InnerLoader@1ba6076  org.codehaus.groovy.tools.RootLoader@a97b0b org.codehaus.groovy.tools.RootLoader@a97b0b  null  org.codehaus.groovy.tools.RootLoader@a97b0b sun.misc.Launcher$AppClassLoader@192d342

• 腳本類和C類的ClassLoader是GroovyClassLoader.InnerLoader，這是我們預(yù)期內(nèi)的。

• GroovyMain 的ClassLoader是RootLoader，是因?yàn)镚roovyStarter就是用RootLoader來(lái)加載它的；而ClassVisitor 是Groovy依賴的asm庫(kù)中的類，這個(gè)庫(kù)的jar文件路徑不在Java的classpath中，而是在Groovy的classpath中，所以很自然的，它的ClassLoader也是RootLoader。

• String的ClassLoader是null，這是因?yàn)镴DK中的基本類型都必須由Bootstrap ClassLoader加載（如果允許自定義的ClassLoader加載，那就天下大亂了）。

• GroovyStarter 的ClassLoader是RootLoader，這點(diǎn)讓我們很意外，GroovyStarter應(yīng)該已經(jīng)由System ClassLoader載入（systemClassLoader.findLoadedClass證實(shí)了這個(gè)想法），根據(jù)雙親委派模型，System ClassLoader的后代都不會(huì)嘗試去加載這個(gè)類，為什么RootLoader又去加載了一次GroovyStarter呢？

答案很簡(jiǎn)單，因?yàn)镽ootLoader沒(méi)有遵循雙親委派模型。我們來(lái)看一下RootLoader的loadClass方法（做了一些簡(jiǎn)單的方法展開(kāi)）： 

protected synchronized Class loadClass(final String name, boolean resolve) throws ClassNotFoundException {      Class c = this.findLoadedClass(name);      if (c != null) return c;      c = (Class) customClasses.get(name); // customClasses定義了一些必須由Java原有ClassLoader載入的類      if (c != null) return c;      try {          c = super.findClass(name); // 先嘗試加載這個(gè)類      } catch (ClassNotFoundException cnfe) {          // IGNORE      }      if (c == null) c = super.loadClass(name, resolve); // 加載不到則回到原有的雙親委派模型       if (resolve) resolveClass(c);       return c;  }

RootLoader先嘗試加載類，如果加載不到，再委派給parent加載，所以即使parent已經(jīng)載入了GroovyStarter，RootLoader還會(huì)再加載一次。

為什么要這樣做的？道理很簡(jiǎn)單。在前文中，我一再提醒大家，Java的classpath中只包含了Groovy的jar包，而不包含Groovy依賴的第三方j(luò)ar包，而Groovy的classpath則包含了Groovy以及其依賴的所有第三方j(luò)ar包。如果RootLoader使用雙親委派模型，那么Groovy的jar包中的類就會(huì)由System ClassLoader加載，當(dāng)解析Groovy的類時(shí)，需要加載第三方的jar包，這時(shí)System ClassLoader并不知道從哪里加載，導(dǎo)致找不到類。因此RootLoader并沒(méi)有使用雙親委派模型。

可能你有疑問(wèn)：為什么不把這些jar包都加入Java的classpath中？這樣不就不會(huì)有這個(gè)問(wèn)題了嗎？確實(shí)如此，但是Groovy可以通過(guò)多種方式更靈活的往自己的classpath中添加路徑（你甚至可以通過(guò)代碼往RootLoader的classpath中添加路徑），而Java的classpath只能通過(guò)命令行添加，因此就有了RootLoader這樣的設(shè)計(jì)。

GroovyClassLoader

GroovyClassLoader主要負(fù)責(zé)在運(yùn)行時(shí)編譯groovy源代碼為Class的工作，從而使Groovy實(shí)現(xiàn)了將groovy源代碼動(dòng)態(tài)加載為Class的功能。

GroovyClassLoader編譯groovy代碼的工作重要集中到doParseClass方法中：

private Class doParseClass(GroovyCodeSource codeSource) {      validate(codeSource); // 簡(jiǎn)單校驗(yàn)一些參數(shù)是否為null      Class answer;  // Was neither already loaded nor compiling, so compile and add to cache.      CompilationUnit unit = createCompilationUnit(config, codeSource.getCodeSource());      SourceUnit su = null;      if (codeSource.getFile() == null) {          su = unit.addSource(codeSource.getName(), codeSource.getScriptText());      } else {          su = unit.addSource(codeSource.getFile());      }       ClassCollector collector = createCollector(unit, su); // 這里創(chuàng)建了InnerLoader      unit.setClassgenCallback(collector);      int goalPhase = Phases.CLASS_GENERATION;      if (config != null && config.getTargetDirectory() != null) goalPhase = Phases.OUTPUT;      unit.compile(goalPhase); // 編譯groovy源代碼       // 查找源文件中的Main Class      answer = collector.generatedClass;      String mainClass = su.getAST().getMainClassName();      for (Object o : collector.getLoadedClasses()) {          Class clazz = (Class) o;          String clazzName = clazz.getName();          definePackage(clazzName);          setClassCacheEntry(clazz);          if (clazzName.equals(mainClass)) answer = clazz;      }      return answer;  }

如何編譯groovy源代碼已超出本文的范疇，因此不再介紹具體過(guò)程。

GroovyClassLoader.InnerLoader

我們繼續(xù)來(lái)看一下GroovyClassLoader的createCollector方法：

protected ClassCollector createCollector(CompilationUnit unit, SourceUnit su) {      InnerLoader loader = AccessController.doPrivileged(new PrivilegedAction<InnerLoader>() {          public InnerLoader run() {              return new InnerLoader(GroovyClassLoader.this);          }      });      return new ClassCollector(loader, unit, su);  }   public static class ClassCollector extends CompilationUnit.ClassgenCallback {      private final GroovyClassLoader cl;      // &hellip;&hellip;      protected ClassCollector(InnerLoader cl, CompilationUnit unit, SourceUnit su) {          this.cl = cl;          // &hellip;&hellip;      }      public GroovyClassLoader getDefiningClassLoader() {          return cl;      }      protected Class createClass(byte[] code, ClassNode classNode) {          GroovyClassLoader cl = getDefiningClassLoader();          Class theClass = cl.defineClass(classNode.getName(), code, 0, code.length, unit.getAST().getCodeSource()); // 通過(guò)InnerLoader加載該類          this.loadedClasses.add(theClass);          // &hellip;&hellip;          return theClass;      }      // &hellip;&hellip;  }

我們可以看出，ClassCollector的作用，就是在編譯的過(guò)程中，將編譯出來(lái)的字節(jié)碼，通過(guò)InnerLoader進(jìn)行加載。另外，每次編譯groovy源代碼的時(shí)候，都會(huì)新建一個(gè)InnerLoader的實(shí)例。 

InnerLoader是如何加載這些類的呢？它將所有的加載工作又委派回給GroovyClassLoader。由于InnerLoader的代碼簡(jiǎn)單，這里就不貼出來(lái)了。 

那有了GroovyClassLoader，為什么還需要InnerLoader呢？主要有兩個(gè)原因： 

•  由于一個(gè)ClassLoader對(duì)于同一個(gè)名字的類只能加載一次，如果都由GroovyClassLoader加載，那么當(dāng)一個(gè)腳本里定義了C這個(gè)類之后，另外一個(gè)腳本再定義一個(gè)C類的話，GroovyClassLoader就無(wú)法加載了。
  

• 由于當(dāng)一個(gè)類的ClassLoader被GC之后，這個(gè)類才能被GC，如果由GroovyClassLoader加載所有的類，那么只有當(dāng)GroovyClassLoader被GC了，所有這些類才能被GC，而如果用InnerLoader的話，由于編譯完源代碼之后，已經(jīng)沒(méi)有對(duì)它的外部引用，除了它加載的類，所以只要它加載的類沒(méi)有被引用之后，它以及它加載的類就都可以被GC了。

總結(jié)

介紹了Groovy中最主要的3個(gè)ClassLoader：

• RootLoader：管理了Groovy的classpath，負(fù)責(zé)加載Groovy及其依賴的第三方庫(kù)中的類，它不是使用雙親委派模型。

• GroovyClassLoader：負(fù)責(zé)在運(yùn)行時(shí)編譯groovy源代碼為Class的工作，從而使Groovy實(shí)現(xiàn)了將groovy源代碼動(dòng)態(tài)加載為Class的功能。

• GroovyClassLoader.InnerLoader：Groovy腳本類的直接ClassLoader，它將加載工作委派給GroovyClassLoader，它的存在是為了支持不同源碼里使用相同的類名，以及加載的類能順利被GC。 

看完上述內(nèi)容是否對(duì)您有幫助呢？如果還想對(duì)相關(guān)知識(shí)有進(jìn)一步的了解或閱讀更多相關(guān)文章，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝您對(duì)億速云的支持。