其他分享
首页 > 其他分享> > 谈谈双亲委派模型的第四次破坏-模块化

谈谈双亲委派模型的第四次破坏-模块化

作者:互联网

前言

JDK9引入了Java模块化系统(Java Platform Module System)来实现可配置的封装隔离机制,同时JVM对类加载的架构也做出了调整,也就是双亲委派模型的第四次破坏。前三次破坏分别是:双亲委派模型推出之前,SPI机制,以及OSGI为代表的热替换机制,这里不细说。

双亲委派模型

简介

在JDK9引入之前,绝大多数Java程序会用下面三个类加载器进行加载

工作顺序

解释

如果一个ClassLoader收到了类加载的请求,他会先首先将请求委派给父类加载器完成,只有父类加载器加载不了,子加载器才会完成加载。

双亲委派模型

源代码

下面代码保留了核心逻辑,并添加了注释,主要是2个步骤

  1. 如果父类加载器不为空则用父类加载器加载
  2. 父类加载器加载不成功则本身再加载
            Class<?> c = findLoadedClass(name);
            //如果该类没加载过
            if (c == null) {
                try {
                //如果有父类加载器
                    if (parent != null) {
                    //使用父类加载器加载
                        c = parent.loadClass(name, false);
                        ...
                    } 
                } 
                   if (c == null) {
                    ...
                    //父类加载器没有加载成功则调用自身的findClass进行加载
                    c = findClass(name);
										...
                }
            }
       

值得注意的是这里的parent并不是继承上的父子关系,而是组合关系的父子,parent只是类加载器的一个参数。

图示

如果觉得上面的解释比较抽象可以看看下面比较形象的图示,这里的敌人就是我们要加载的jar包

工作顺序

缺点

通过上面的漫画不言而喻,当真正的敌人来了,靠这种低效的传达机制,怎么可能打一场胜仗呢?

既然一切都是各司其职,为什么不能加载类的时候一步到位呢?

通过分析JDK9的类加载器源码,我发现最新的类加载器结构在一定程度上是缓解了这种情况的

JDK的模块化

在JDK9之前,JVM的基础类以前都是在rt.jar这个包里,这个包也是JRE运行的基石。这不仅是违反了单一职责原则,同样程序在编译的时候会将很多无用的类也一并打包,造成臃肿。

在JDK9中,整个JDK都基于模块化进行构建,以前的rt.jar, tool.jar被拆分成数十个模块,编译的时候只编译实际用到的模块,同时各个类加载器各司其职,只加载自己负责的模块。

moudle

模块化加载源码

  Class<?> c = findLoadedClass(cn);
      if (c == null) {
         // 找到当前类属于哪个模块
         LoadedModule loadedModule = findLoadedModule(cn);
         if (loadedModule != null) {
            //获取当前模块的类加载器
            BuiltinClassLoader loader = loadedModule.loader();
            //进行类加载
            c = findClassInModuleOrNull(loadedModule, cn);
         } else {
            // 找不到模块信息才会进行双亲委派
         if (parent != null) {
           c = parent.loadClassOrNull(cn);
         }
       }

上面代码就是破坏双亲委派模型的“铁证”,而当我们继续跟进findLoadedModule,会发现是根据路径名找到对应的模块,而维护这一数据结构的就是下面这个Map。

Map<String, LoadedModule> packageToModule
        = new ConcurrentHashMap<>(1024);

可以看到LoadedModule里面不仅有该模块的loader信息,还有用于描述依赖模块,对外暴露模块的信息的mref,LoadedModule也是模块化实现封装隔离机制的一块重要实现。

moduleMap

每一个module信息都有一个BuiltinClassloader,这个类有三个子类,我们通过源码分析他们的父子关系

image-20200329162147803

在ClassLoaders类中可以发现,PlatformClassLoader的parent是BootClassLoader,而AppClassLoader的parent则是PlatformClassLoader。

public class ClassLoaders {

    // the built-in class loaders
    private static final BootClassLoader BOOT_LOADER;
    private static final PlatformClassLoader PLATFORM_LOADER;
    private static final AppClassLoader APP_LOADER;

    static {
        BOOT_LOADER =
            new BootClassLoader((append != null && !append.isEmpty())
                ? new URLClassPath(append, true)
                : null);
                
        PLATFORM_LOADER = new PlatformClassLoader(BOOT_LOADER);
        ...
        APP_LOADER = new AppClassLoader(PLATFORM_LOADER, ucp);
    }
  }

结论

  1. 经过破坏后的双亲委派模型更加高效,减少了很多类加载器之间不必要的委派操作
  2. JDK9的模块化可以减少Java程序打包的体积,同时拥有更好的隔离线与封装性
  3. 每个module拥有专属的类加载器,程序在并发性上也会更加出色

标签:委派,null,parent,模块化,LOADER,JDK9,双亲,父类,加载
来源: https://www.cnblogs.com/yangkw/p/12615114.html