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

Posted 2021-12-12 ProChick

类加载器的变动

• • 一、变动①
  • 二、变动②
  • 三、变动③
  • 四、变动④
  • 五、变动⑤
  • 六、变动⑥

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

一、变动①

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

启动类加载器

平台类加载器

应用类加载器

二、变动②

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

🎈原因： JDK9是基于模块化进行构建的，它将原来的rt.jar和tools.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之后的版本中，当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载。