Java基础巩固（二）类加载器和双亲委派模型

类加载的过程

Java的类加载过程分为三个主要步骤:
首先是加载阶段(Loading)，它是Java将字节码数据从不同的数据源读取到JVM中，并映射为JVM认可的数据结构(Class对象)，这里的数据源可能是各种各样的形态，如jar文件、class文件，甚至是网络数据源等;如果输入数据不是ClassFile的结构，则会抛出ClassFormatError。 加载阶段是用户参与的阶段，我们可以自定义类加载器，去实现自己的类加载过程。

第二阶段是链接(Linking)，这是核心的步骤，简单说是把原始的类定义信息平滑地转化入JVM运行的过程中。这里可进一步细分为三个步骤:

• 验证(Verifcation)，这是虚拟机安全的重要保障，JVM需要核验字节信息是符合Java虚拟机规范的，否则就被认为是VerifyError，这样就防止了恶意信息或者不合规的信息危害JVM的运行，验证阶段有可能触发更多class的加载。
• 准备(Preparation)，创建类或接口中的静态变量，并初始化静态变量的初始值。但这里的“初始化”和下面的显式初始化阶段是有区别的，侧重点在于分配所需要的内存空间，不会去执行更进一步的JVM指令。
• 解析(Resolution)，在这一步会将常量池中的符号引用(symbolic
  reference)替换为直接引用。在Java虚拟机规范中，详细介绍了类、接口、方法和字段等各个方面的解析。

最后是初始化阶段(initialization)，这一步真正去执行类初始化的代码逻辑，包括静态字段赋值的动作，以及执行类定义中的静态初始化块内的逻辑，编译器在编译阶段就会把这 部分逻辑整理好，父类型的初始化逻辑优先于当前类型的逻辑。

类加载器

虚拟机团队把类加载中“通过一个类的全限定名来获取描述此类的二进制字符流” 这个动作放在Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类，实现这个动作的代码模块称为类加载器。
对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性，即使两个雷来源于同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不同，那这两个雷就必定不相等。
实现自定义类加载器的小例子

/**
 * 加载和类加载器在同一路径下的类
 *  * @author yzheng
 * @date 2021/10/21 12:01 上午
 */
public class MyClassLoader extends ClassLoader{

    /**
     * 重写loadClass方法
     *
     * @param name 类路径（例：com.yzheng.classloader.MyClassLoader）
     * @return 类对象
     * @throws ClassNotFoundException 无法找到指定类异常
     */
    @Override
    public Class<?> loadClass(String name) throws ClassNotFoundException {
        try {
            // 从类路径中切分出类名，并添加.class(格式：类名.class)
            String fileName = name.substring(name.lastIndexOf('.') + 1) + ".class";
            // 从当前类所在路径下加载指定名称的文件，getClass是到当前类
            InputStream is = getClass().getResourceAsStream(fileName);
            // 如果未读取到类文件，调用父类加载器加载该类
            if(is == null){
                return super.loadClass(name);
            }
            byte[] b = new byte[is.available()];
            is.read(b);
            // 调用默认的将字符数组转化未类对象方法
            return defineClass(name, b, 0, b.length);
        }catch (IOException e){
            throw new ClassNotFoundException(name);
        }
    }
}

自定义类加载器常见的场景

• 实现类似进程内隔离，类加载器实际上用作不同的命名空间，以提供类似容器、模块化的效果。例如，两个模块依赖于某个类库的不同版本，如果分别被不同的容器加载，就可以互不干扰。这个方面的集大成者是Java EE和OSGI、JPMS等框架。
• 应用需要从不同的数据源获取类定义信息，例如网络数据源，而不是本地文件系统。
• 或者是需要自己操纵字节码，动态修改或者生成类型。

简单自定义类加载过程

• 通过指定名称，找到其二进制实现，这里往往就是自定义类加载器会“定制”的部分，例如，在特定数据源根据名字获取字节码，或者修改或生成字节码。
• 然后，创建Class对象，并完成类加载过程。二进制信息到Class对象的转换，通常就依赖defneClass，我们无需自己实现，它是fnal方法。有了Class对象，后续完成加载过程就顺理成章了。

更详细实现可以参考这个用例。

双亲委派模型

双亲委派模型介绍

双亲委派模型，简单说就是当类加载器(Class-Loader)试图加载某个类型的时候，除非父加载器找不到相应类型，否则尽量将这个任务代理给当前加载器的父加载器去做。使用委派模型的目的是避免重复加载Java类。
从Java虚拟机角度，只存在两种不同的类加载器：

1. 启动类加载器（Bootstrap ClassLoader）,这个类加载器使用C++语言实现，是虚拟机自身的一部分
2. 其他所有类加载器，Java实现，独立于虚拟机外部，都继承自抽象类java.lang.ClassLoader

从开发人员角度角度，结合Java 8以前各种类加载器的结构，绝大多数Java程序会用到以下3中系统提供的类加载器。
启动类加载器(Bootstrap Class-Loader)，加载 jre/lib下面的jar文件，如rt.jar。它是个超级公民，即使是在开启了Security Manager的时候，JDK仍赋予了它加载的程序AllPermission。 对于做底层开发的工程师，有的时候可能不得不去试图修改JDK的基础代码，也就是通常意义上的核心类库，我们可以使用下面的命令行参数。

# 指定新的bootclasspath，替换java.*包的内部实现
java -Xbootclasspath:<your_boot_classpath> your_App
# a意味着append，将指定目录添加到bootclasspath后面 
java -Xbootclasspath/a:<your_dir> your_App
# p意味着prepend，将指定目录添加到bootclasspath前面 
java -Xbootclasspath/p:<your_dir> your_App

用法其实很易懂，例如，使用最常见的 “/p”，既然是前置，就有机会替换个别基础类的实现。
我们一般可以使用下面方法获取父加载器，但是在通常的JDK/JRE实现中，扩展类加载器getParent()都只能返回null。

public fnal ClassLoader getParent()

扩展类加载器(Extension or Ext Class-Loader)，负责加载我们放到jre/lib/ext/目录下面的jar包，这就是所谓的extension机制。该目录也可以通过设置 “java.ext.dirs”来 覆盖。

java -Djava.ext.dirs=your_ext_dir HelloWorld

应用类加载器(Application or App Class-Loader)，就是加载我们最熟悉的classpath的内容。这里有一个容易混淆的概念，系统(System)类加载器，通常来说，其默认就是JDK内建的应用类加载器，但是它同样是可能修改的，比如:

java -Djava.sysem.class.loader=com.yourcorp.YourClassLoader HelloWorld

如果我们指定了这个参数，JDK内建的应用类加载器就会成为定制加载器的父亲，这种方式通常用在类似需要改变双亲委派模式的场景。 具体请参考下图:

双亲委派模型的代码实现：

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
    // 首先，检查请求的类是否已经被加载过了
    Class c = findLoadedClass(name); if (c == null) {
        try {
            if (parent != null) {
                c = parent.loadClass(name, false);
            } else {
                c = findBootstrapClassOrNull(name); 
            }
        } catch (ClassNotFoundException e) {
            // 如果父类加载器抛出ClassNotFoundException
            // 说明父类加载器无法完成加载请求
        }
        if (c == null) {
            // 在父类加载器无法加载时
            // 再调用本身的findClass方法来进行类加载
            c = findClass(name);
        }
    }
    // resolve为true进行类加载链接操作，反之不进行
    if (resolve) {
        resolveClass(c);
    }
     return c;
}

如果不同类加载器都自己加载需要的某个类型，那么就会出现多次重复加载，完全是种浪费。
通常类加载机制有三个基本特征:

• 双亲委派模型。但不是所有类加载都遵守这个模型，有的时候，启动类加载器所加载的类型，是可能要加载用户代码的，比如JDK内部的ServiceProvider/ServiceLoader机制，用户可以在标准API框架上，提供自己的实现，JDK也需要提供些默认的参考实现。 例如，Java中JNDI、JDBC、文件系统、Cipher等很多方面，都是利用的这种机制，这种情况就不会用双亲委派模型去加载，而是利用所谓的上下文加载器。
• 可见性，子类加载器可以访问父加载器加载的类型，但是反过来是不允许的，不然，因为缺少必要的隔离，我们就没有办法利用类加载器去实现容器的逻辑。
• 单一性，由于父加载器的类型对于子加载器是可见的，所以父加载器中加载过的类型，就不会在子加载器中重复加载。但是注意，类加载器“邻居”间，同一类型仍然可以被加载多次，因为互相并不可见。 IDEA里的显示jar包加载结构的插件来检查出冲突的jar

破坏双亲委派模型

1. 继承java.lang.ClassLoader直接重写loadClass方法,而双亲委派的具体逻辑就是实现在loadClass方法中的；

2. 自身模型缺陷，存在基础类又要调用回用户的代码，提供类线程上下文类加载器（Thread Context
   ClassLoader）,可以实现父类加载请求子类加载器去完成类加载动作

3. 用户对程序动态行的追求导致OSGI环境下，类加载器不再是双亲委派的模型中的树状结构，而是进一步发展为更加复杂的网状结构，当收到类加载请求时，按照下面的顺序进行类搜索

   • 将以java.*开头的类，委派给父类加载器加载。
   • 否则，将委派列表名单内的类，委派给父类加载器加载。
   • 否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。
   • 否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。
   • 否则，查找类是否在自己的FragmentBundle中，如果在，则委派给Fragment Bundle的类加载器加载。
   • 否则，查找DynamicImport列表的Bundle，委派给对应Bundle的类加载器加载。
   • 否则，类查找失败

上面的查找顺序中只有开头两点仍然符合双亲委派模型的原则，其余的类查找都是在平级的类加载器中进行的

JDK 9中带来的改变

Java模块化系统

在JDK 9中，由于Jigsaw项目引入了Java平台模块化系统(JPMS)，Java SE的源代码被划分为一系列模块。

类加载器，类文件容器等都发生了非常大的变化，我这里总结一下:

• 前面提到的-Xbootclasspath参数不可用了。API已经被划分到具体的模块，所以上文中，利用“-Xbootclasspath/p”替换某个Java核心类型代码，实际上变成了对相应的模块进行的修补，可以采用下面的解决方案:
  首先，确认要修改的类文件已经编译好，并按照对应模块(假设是java.base)结构存放，然后，给模块打补丁:

java --patch-module java.base=your_patch yourApp

• 扩展类加载器被重命名为平台类加载器(Platform
  Class-Loader)，而且extension机制则被移除。也就意味着，如果我们指定java.ext.dirs环境变量，或者lib/ext目录存 在，JVM将直接返回错误!建议解决办法就是将其放入classpath里。
• 部分不需要AllPermission的Java基础模块，被降级到平台类加载器中，相应的权限也被更精细粒度地限制起来。
• rt.jar和tools.jar同样是被移除了，JDK的核心类库以及相关资源，被存储在jimage文件中，并通过新的JRT文件系统访问，而不是原有的JAR文件系统。虽然看起来很惊人，但幸好对于大部分软件的兼容性影响，其实是有限的，更直接地影响是IDE等软件，通常只要升级到新版本就可以了。
• 增加了Layer的抽象，JVM启动默认创建BootLayer，开发者也可以自己去定义和实例化Layer，可以更加方便的实现类似容器一般的逻辑抽象。

JDK 9中的类加载器架构

JDK 9中虽然仍然维持着三层类加载器和双亲委派的架构，但类加载的委派关系也发生了变动。当平台及应用程序类加载器收到类加载请求，在委派给父加载器加载前，要先判断该类是否能够归属到某一个系统模块中，如果可以找到这样的归属关系，就要优先委派给负责那个模块的加载器完成加载，也许这可以算是对双亲委派的第四次破坏，JDK 9以后的三层类加载器的架构如下图所示：