Groovy深入探索:Groovy的ClassLoader體系
Groovy中定義了不少ClassLoader,本文將介紹其中絕大多數(shù)Groovy腳本都會(huì)涉及到的,也是最主要的3個(gè)ClassLoader:RootLoader、GroovyClassLoader和GroovyClassLoader.InnerLoader。
注:以下分析的Groovy源代碼來(lái)自Groovy 2.1.3。
Java的ClassLoader
顧名思義,Java的ClassLoader就是類(lèi)的裝載器,它使JVM可以動(dòng)態(tài)的載入Java類(lèi),JVM并不需要知道從什么地方(本地文件、網(wǎng)絡(luò)等)載入Java類(lèi),這些都由ClassLoader完成。
可以說(shuō),ClassLoader是Class的命名空間。同一個(gè)名字的類(lèi)可以由多個(gè)ClassLoader載入,由不同ClassLoader載入的相同名字的類(lèi)將被認(rèn)為是不同的類(lèi);而同一個(gè)ClassLoader對(duì)同一個(gè)名字的類(lèi)只能載入一次。
Java的ClassLoader有一個(gè)著名的雙親委派模型(Parent Delegation Model):除了Bootstrap ClassLoader外,每個(gè)ClassLoader都有一個(gè)parent的ClassLoader,沿著parent最終會(huì)追索到Bootstrap ClassLoader;當(dāng)一個(gè)ClassLoader要載入一個(gè)類(lèi)時(shí),會(huì)首先委派給parent,如果parent能載入這個(gè)類(lèi),則返回,否則這個(gè)ClassLoader才會(huì)嘗試去載入這個(gè)類(lèi)。
Java的ClassLoader體系如下,其中箭頭指向的是該ClassLoader的parent:
- Bootstrap ClassLoader
- ↑
- Extension ClassLoader
- ↑
- System ClassLoader
- ↑
- User Custom ClassLoader // 不一定有
更多關(guān)于Java的ClassLoader的信息請(qǐng)參考以下資料:
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è)诿钚休斎?ldquo;groovy 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)加載類(lèi),而該GroovyClassLoader的parent即為GroovyShell的ClassLoader,也就是GroovyMain的ClassLoader,也就是RootLoader。
***來(lái)總結(jié)一下Groovy腳本的啟動(dòng)流程(括號(hào)中表示使用的ClassLoader):
- GroovyStarter
- ↓ (RootLoader)
- GroovyMain
- ↓
- GroovyShell
- ↓ (GroovyClassLoader)
- SomeScript
#p#
RootLoader
RootLoader作為Groovy的根ClassLoader,負(fù)責(zé)加載Groovy及其依賴的第三方庫(kù)中的類(lèi)。它管理了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
- 腳本類(lèi)和C類(lèi)的ClassLoader是GroovyClassLoader.InnerLoader,這是我們預(yù)期內(nèi)的。
- GroovyMain 的ClassLoader是RootLoader,是因?yàn)镚roovyStarter就是用RootLoader來(lái)加載它的;而ClassVisitor 是Groovy依賴的asm庫(kù)中的類(lèi),這個(gè)庫(kù)的jar文件路徑不在Java的classpath中,而是在Groovy的classpath中,所以很自然的,它的ClassLoader也是RootLoader。
- String的ClassLoader是null,這是因?yàn)镴DK中的基本類(lèi)型都必須由Bootstrap ClassLoader加載(如果允許自定義的ClassLoader加載,那就天下大亂了)。
- GroovyStarter 的ClassLoader是RootLoader,這點(diǎn)讓我們很意外,GroovyStarter應(yīng)該已經(jīng)由System ClassLoader載入(systemClassLoader.findLoadedClass證實(shí)了這個(gè)想法),根據(jù)雙親委派模型,System ClassLoader的后代都不會(huì)嘗試去加載這個(gè)類(lèi),為什么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載入的類(lèi)
- if (c != null) return c;
- try {
- c = super.findClass(name); // 先嘗試加載這個(gè)類(lèi)
- } catch (ClassNotFoundException cnfe) {
- // IGNORE
- }
- if (c == null) c = super.loadClass(name, resolve); // 加載不到則回到原有的雙親委派模型
- if (resolve) resolveClass(c);
- return c;
- }
RootLoader先嘗試加載類(lèi),如果加載不到,再委派給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包中的類(lèi)就會(huì)由System ClassLoader加載,當(dāng)解析Groovy的類(lèi)時(shí),需要加載第三方的jar包,這時(shí)System ClassLoader并不知道從哪里加載,導(dǎo)致找不到類(lèi)。因此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;
- // ……
- protected ClassCollector(InnerLoader cl, CompilationUnit unit, SourceUnit su) {
- this.cl = cl;
- // ……
- }
- 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加載該類(lèi)
- this.loadedClasses.add(theClass);
- // ……
- return theClass;
- }
- // ……
- }
我們可以看出,ClassCollector的作用,就是在編譯的過(guò)程中,將編譯出來(lái)的字節(jié)碼,通過(guò)InnerLoader進(jìn)行加載。另外,每次編譯groovy源代碼的時(shí)候,都會(huì)新建一個(gè)InnerLoader的實(shí)例。
InnerLoader是如何加載這些類(lèi)的呢?它將所有的加載工作又委派回給GroovyClassLoader。由于InnerLoader的代碼簡(jiǎn)單,這里就不貼出來(lái)了。
那有了GroovyClassLoader,為什么還需要InnerLoader呢?主要有兩個(gè)原因:
- 由于一個(gè)ClassLoader對(duì)于同一個(gè)名字的類(lèi)只能加載一次,如果都由GroovyClassLoader加載,那么當(dāng)一個(gè)腳本里定義了C這個(gè)類(lèi)之后,另外一個(gè)腳本再定義一個(gè)C類(lèi)的話,GroovyClassLoader就無(wú)法加載了。
- 由于當(dāng)一個(gè)類(lèi)的ClassLoader被GC之后,這個(gè)類(lèi)才能被GC,如果由GroovyClassLoader加載所有的類(lèi),那么只有當(dāng)GroovyClassLoader被GC了,所有這些類(lèi)才能被GC,而如果用InnerLoader的話,由于編譯完源代碼之后,已經(jīng)沒(méi)有對(duì)它的外部引用,除了它加載的類(lèi),所以只要它加載的類(lèi)沒(méi)有被引用之后,它以及它加載的類(lèi)就都可以被GC了。
總結(jié)
本文介紹了Groovy中最主要的3個(gè)ClassLoader:
- RootLoader:管理了Groovy的classpath,負(fù)責(zé)加載Groovy及其依賴的第三方庫(kù)中的類(lèi),它不是使用雙親委派模型。
- GroovyClassLoader:負(fù)責(zé)在運(yùn)行時(shí)編譯groovy源代碼為Class的工作,從而使Groovy實(shí)現(xiàn)了將groovy源代碼動(dòng)態(tài)加載為Class的功能。
- GroovyClassLoader.InnerLoader:Groovy腳本類(lèi)的直接ClassLoader,它將加載工作委派給GroovyClassLoader,它的存在是為了支持不同源碼里使用相同的類(lèi)名,以及加載的類(lèi)能順利被GC。
原文鏈接:http://www.blogjava.net/johnnyjian/archive/2013/04/14/397823.html