JVM扩展之JDK9中有关类加载器的变动

为了保证兼容性,JDK9没有从根本上改变三层类加载器的架构和双亲委派模型,但为了模块化系统的顺利运行,仍然发生了一些值得被注意的变动。

一、变动①

由于引入了模块化概念,所以不同的类加载器回去加载属于不同模块的类

启动类加载器

请添加图片描述

平台类加载器

请添加图片描述

应用类加载器

请添加图片描述

二、变动②

扩展机制被移除,但是扩展类加载器由于向后兼容性的原因被保留,然后被重命名为平台类加载器Platform ClassLoader,可以通过ClassLoader的新增方法getPlatformClassLoader来获取。

🎈原因: JDK9是基于模块化进行构建的,它将原来的rt.jartools.jar拆分成了很多的JMOD文件,文件中的Java类库已经天然地满足了可扩展的需求,所以扩展机制已经没有继续存在的价值了。

public class ClassLoaderTest {
    public static void main(String[] args) {
        System.out.println(ClassLoaderTest.class.getClassLoader());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent());
        System.out.println(ClassLoaderTest.class.getClassLoader().getParent().getParent());
    }
}

请添加图片描述

三、变动③

平台类加载器和应用程序类加载器都不再继承于java.net.URLClassLoader,而是继承于jdk.internal.loader.BuiltinClassLoader,并且连启动类加载器都是。

请添加图片描述

四、变动④

类加载器有了名称属性,该名称可以在构造方法中进行指定,通过getName方法来获取。应用类加载器的默认名称是app,平台类加载器的默认名称是platform。

五、变动⑤

启动类加载器现在是由JVM内部和Java类库共同协作实现的类加载器,但为了与之前代码进行兼容,在尝试获取启动类加载器时仍然会返回null,而不会得到对应的BootClassLoader实例。

六、变动⑥

类加载的委派关系发生了变动。

请添加图片描述

👉在JDK9之前的版本中,当扩展及应用程序类加载器收到类加载请求,会委派给父加载器加载,只有当父加载器反馈自己无法完成这个加载请求时,才会由子类加载器尝试进行加载。

👉在JDK9之后的版本中,当平台及应用程序类加载器收到类加载请求,在委派给父加载器加载前,要先判断该类是否能够归属到某一个系统模块中,如果可以找到这样的归属关系,就要优先委派给负责那个模块的加载器完成加载。

  • 2
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

编程小吉

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值