目录

前言

1.什么是类加载?

2.类加载整体流程

3.一个类什么时候被加载?

4.双亲委派模型

4.1 JVM默认提供了三个类加载器

4.1.1 BootstrapClassLoader

4.1.2 ExtensionClassLoader

4.1.3 ApplicationClassLoader

4.2 破坏双亲委派模型

---

前言

在上一篇文章中，我们主要简述了JVM内存区域划分的相关知识，下面我们将讲述JVM类加载机制

1.什么是类加载?

        类加载就是.class文件(.java通过javac进行编译成class文件)，从文件(硬盘)被加载到内存中(元数据区)的过程。

2.类加载整体流程

• 1.加载：把.class文件找到，打开文件，读文件，把文件内容读到内存中；

• 2.验证：检查下.class文件格式是否规范；

• 3.准备：给类对象分配内存空间(先在元数据占个位置)，也使静态成员被设置成0；

• 4.解析：初始化字符串常量，把符号引用转为直接引用。初始化字符串常量时，首先需要为字符的实际内容分配一块内存空间，并确保有一个引用指向这块内存空间的起始地址。在类加载之前，字符串常量存在于.class文件中，这个"引用"记录的是它在文件中的偏移量（占位符），而不是字符串常量的真正地址。当类加载完成后，字符串常量才会被放入内存中，此时引用会被赋值为实际的内存地址。
  • 举例：假设你得到了一张古老的藏宝图，这张藏宝图标记了一处隐藏的宝藏位置。这个过程与字符串常量的处理有类似之处：

  • 1. 藏宝图的研究（类加载前）：在开始挖掘宝藏之前，藏宝图就像是一个.class文件里的字符串常量。你知道这张图代表了什么，但还没有实际的行动。图中标记的位置不是真实的地址，而是告诉你宝藏可能在哪里的一种“偏移量”或线索；

  • 2. 准备挖掘（类加载）：决定根据藏宝图去探险，就好比是类加载的过程。你开始准备必要的工具，如铲子和地图，这相当于JVM为字符串常量分配内存空间；

  • 3. 定位宝藏（引用转换）：出发后，你按照藏宝图上的线索前进，这如同符号引用被转换为直接引用。你通过解读地图上的线索（可能是一棵树、一块石头或一个特定形状的地标），逐步接近宝藏的实际位置。

  • 4. 挖掘宝藏（访问地址）：当你到达指定地点并开始挖掘时，这就像是JVM访问字符串常量在内存中的实际位置。你挖出宝藏的那一刻，就类似于程序最终使用到这个字符串常量的内容。

    通过这个例子，我们可以看到，藏宝图的使用过程（从解读到实际挖掘出宝藏）与JVM如何处理字符串常量（从类加载到实际使用字符串内容）有着相似的步骤。都是先有一个初步的指引（无论是藏宝图还是符号引用），然后通过一系列的动作（解读和应用），最终达到目的（找到宝藏或获取字符串内容）。

• 5.初始化：调用构造方法，进行成员初始化，执行代码块，静态代码块，加载父类等。

3.一个类什么时候被加载?

• 首先我们要知道，不是Java程序一运行，就把所有的类都加载，而是真正用到才加载(懒汉模式)，一旦加载过后，后续无需再重复加载；

• 加载的内容有:
  • 1.构造类的实例；
  • 2.调用这个类的静态方法/使用静态属性；
  • 3.加载子类，就会先加载其父类

4.双亲委派模型

在上面的类加载的整体流程中，我们说到了加载，

加载:把.class文件找到，打开文件，读文件，把文件内容读到内存中

• 双亲委派模型描述了类加载器在查找和加载.class文件时的基本过程。

• 4.1 JVM默认提供了三个类加载器

  • 4.1.1 BootstrapClassLoader

    • 负责加载标准库的类
      • (Java规范，要求提供哪些类)无论是哪种JVM的实现，都会提供这些一样的类

  • 4.1.2 ExtensionClassLoader

    • 负责加载JVM扩展库中的类
      • (规范之外，由实现JVM的厂商/组织，提供的额外的功能)

  • 4.1.3 ApplicationClassLoader

    • 负责加载用户提供的第三方库/用户项目代码中的类
  • 上述的三个类存在"父子关系"，相当于每个class loader有一个parent属性，指向自己的父 类加载器

    

  • 4.1.4 上述的类加载器如何配合工作?
    • 1.首先，类加载过程是从ApplicationClassLoader开始的。然而，ApplicationClassLoader不会直接进行加载，而是将加载任务委托给自己的父 类加载器。接下来，ExtensionClassLoader接收到委托后，同样不会立即加载，而是再次将自己作为父类加载器，并将加载任务委托给它的父 类加载器BootstrapClassLoader。BootstrapClassLoader在收到委托时，发现自己没有父类加载器（即父类为null），于是它自己执行实际的加载操作。
    • 2.BootstrapClassLoader会搜索自己负责的标准库目录，寻找相关的类。如果找到了目标类，则进行加载；如果没有找到，它会将加载任务委托给子类加载器。ExtensionClassLoader会真正地搜索扩展库相关的目录，同样地，如果找到了目标类，则进行加载；如果没有找到，它也会将加载任务委托给子类加载器。ApplicationClassLoader则会搜索用户相关的目录，如果找到了目标类，则进行加载；如果没有找到，由于此时已经没有其他子类加载器了，所以只能抛出一个类找不到的异常。
    • 3.为什么要有上述顺序?
      • 上述这套顺序实际上是由JVM实现代码的逻辑所决定的，这种逻辑类似于递归的方式；
      • 主要目的是确保Bootstrap能够优先加载，而Application能够稍后加载，以避免用户创建一些奇怪的类，从而引发不必要的bug；
      • 在一方面，类加载器可以由用户自定义。除了JVM自带的Bootstrap ClassLoader、Extension ClassLoader和Application ClassLoader之外，用户可以创建自己的类加载器，并将其加入到类加载流程中。这样，用户可以根据自己的需求决定加载顺序，并且可以与现有的加载器配合使用。

4.2 破坏双亲委派模型

      1.自己编写的类加载器可以根据需求选择是否遵守双亲委派模型。

      2.举例来说，Tomcat是一个Web服务器，它需要加载Web应用程序中的类。在这种情况下，Tomcat可能会使用单独的类加载器来加载Webapp，而不是遵循双亲委派模型。

      3.这样做的好处是可以避免不同Web应用程序之间的类冲突，并且可以更好地控制每个Web应用程序的类加载过程。然而，如果一个自定义的类加载器不遵循双亲委派模型，那么它必须自行处理类的查找和加载，这可能会导致一些额外的复杂性和潜在的问题。因此，是否遵守双亲委派模型主要取决于具体的需求和设计决策。 

 以上就是JVM类加载机制的简单介绍。