3、Groovy类加载体系

本文深入探讨Groovy的类加载体系,对比Java的ClassLoader,分析Groovy的RootLoader和GroovyClassLoader,揭示其不采用双亲委派模型的原因,并讨论GroovyClassLoader的InnerLoader在动态编译和类管理中的作用。
摘要由CSDN通过智能技术生成

2021SC@SDUSC

3、Groovy类加载体系

上一篇博客分析了下Groovy是如何在JVM上运行的,这篇博客深入根据源码分析一下Groovy的类加载器。

Java的ClassLoader

顾名思义,Java的ClassLoader就是类的装载器,它使JVM可以动态的载入Java类,JVM并不需要知道从什么地方(本地文件、网络等)载入Java类,这些都由ClassLoader完成。

可以说,ClassLoader是Class的命名空间。同一个名字的类可以由多个ClassLoader载入,由不同ClassLoader载入的相同名字的类将被认为是不同的类;而同一个ClassLoader对同一个名字的类只能载入一次。

Java的ClassLoader有一个著名的双亲委派模型(Parent Delegation Model):除了Bootstrap ClassLoader外,每个ClassLoader都有一个parent的ClassLoader,沿着parent最终会追索到Bootstrap ClassLoader;当一个ClassLoader要载入一个类时,会首先委派给parent,如果parent能载入这个类,则返回,否则这个ClassLoader才会尝试去载入这个类。

Java的ClassLoader体系如下,其中箭头指向的是该ClassLoader的parent:

Bootstrap ClassLoader

Extension ClassLoader

System ClassLoader

User Custom ClassLoader // 不一定有

Groovy的ClassLoader

我们首先通过一个脚本来看一下,一个Groovy脚本的ClassLoader以及它的祖先们分别是什么:

1 def cl = this.class.classLoader
2 while (cl) {
   
3     println cl
4     cl = cl.parent
5 }

输出如下:

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 ClassLoadersun.misc.Launcher.ExtClassLoader      // 即Extension ClassLoadersun.misc
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值