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

Posted 2021-04-30 Hollis

“ JDK9引入了模块化系统来实现可配置的封装隔离机制，同时JVM对类加载的架构也做出了调整，也就是双亲委派模型的第四次破坏”

01 双亲委派模型

简介

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

• 启动类加载器(Bootstrap Class Loader)：由C++编写，负责加载<JAVA_HOME>\jre\lib目录下的类，例如最基本的Object，Integer，这些存在于rt.jar文件中的类，一般这些类都是Java程序的基石。
• 扩展类加载器(Extension Class Loader)：负责加载<JAVA_HOME>\jre\lib\ext目录下的类，在JDK9之前我们可以将通用性的类库放在ext目录来扩展JAVA的功能，但实际的工程都是通过maven引入jar包依赖。并且在JDK9取消了这一类加载器，取而代之的是平台类加载器(Platform Class Loader)，下面会对其介绍。
• 应用类加载器(Application Class Loader)：负责加载ClassPath路径下的类，通常工程师编写的大部分类都是由这个类加载器加载。

工作顺序

解释

如果一个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);
...
               }
           }
      
 
   
   
 

图示

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

缺点

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

• 启动类加载器负责加载<JAVA_HOME>\jre\lib目录

• 扩展类加载器负责加载<JAVA_HOME>\jre\lib\ext目录

• 应用类加载器负责加载ClassPath目录。

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

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

02 JDK的模块化

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

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

03 模块化加载源码

 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也是模块化实现封装隔离机制的一块重要实现。

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

在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 {
   
     
     
           //BootClassLoader
   
     
     
    BOOT_LOADER =
   
     
     
    new BootClassLoader((append != null && !append.isEmpty())
   
     
     
    ? new URLClassPath(append, true)
   
     
     
    : null);
   
     
     
           //PlatformClassLoader
   
     
     
    PLATFORM_LOADER = new PlatformClassLoader(BOOT_LOADER);
   
     
     
           ...
   
     
     
           //AppClassLoader
   
     
     
    APP_LOADER = new AppClassLoader(PLATFORM_LOADER, ucp);
   
     
     
    }
   
     
     
    }
  
    
    
  

04 结论

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

有道无术，术可成；有术无道，止于术

好文章，我在看❤️