likes
comments
collection
share

JVM成神之路(2): 类的加载

作者站长头像
站长
· 阅读数 43

前言

理解完 class 文件之后，那它是存放在磁盘上的，如果要在 JVM 中使用 class 文件，需要将它加载到内存中，本文就来详细的介绍下 class 文件加载到内存的过程。

一、类的加载概述

Java 虚拟机把描述类的数据从 Class 文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的 Java 类型，这个过程被称为虚拟机的类加载机制。

与那些在编译时需要进行连接的语言不同，在 Java 语言里面，类型的加载、连接和初始化过程都是在程序运行期完成的。这种策略让 Java 语言进行提前编译会面临额外的困难，也会让类加载时稍微增加一些性能开销，但是却为 Java 应用提供了极高的扩展性和灵活性，Java 天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。

一个类型从被加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期将会经历加载 loading、验证、准备、解析、初始化、使用 和 卸载七个阶段，其中验证、准备、解析三个部分统称为连接。

JVM成神之路(2): 类的加载

加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的，类型的加载过程必须按照这种顺序按部就班的开始。

而解析阶段则不一定，它在某些情况下可以在初始化阶段之后再开始，这是为了支持 Java 语言的运行时绑定特定（也称为动态绑定或晚期绑定）。

请注意，这里写的是按部就班的开始，而不是按部就班的进行或按部就班的完成，强调这点是因为这些阶段经常互相交叉的混合进行的，会在一个阶段执行的过程中调用、激活另一个阶段。

二、加载阶段

2.1 加载完成三件事

加载是类加载过程中的第一个阶段，简单来说就是将 Java 类的 class 文件加载到机器内存中，然后在内存中构建出 Java 类的原型，称为 "类模板对象"，所谓类模板对象，其实就是一个 Java 类在 JVM 内存中的一个快照。

JVM 将从 class 文件中解析出来的常量池、类字段、类方法等信息存储在类模板对象中，Java 在运行时可以通过类模板获取 Java 类的任意信息，反射机制就是基于这点完成的。

在加载阶段，Java 虚拟机需要完成以下三件事情：

  • 1、通过一个类的全限定名来获取定义此类的二进制字节流。

    • 获取 class 文件字节流

  • 2、将这个字节流所代表的静态存储结构转化为方法区的数据结构；

    • 说明：class 文件是一个静态的二进制文件，里面存放的是我们类所有的一些常量、结构、字段、方法、属性，这些都是静态存储在 class 文件中的，转化为方法区所需要的运行时的一种数据结构

  • 3、在内存中生成一个代表这个类的 java.lang.class 对象，作为方法区这个类的各种数据的访问入口

    • 生成的对象在堆内存，我们所有的对象的里面的字段，方法的访问入口会在我们的堆里。这个入口，直通方法区。

《Java 虚拟机规范》对这三点要求其实并不是特别具体，留给虚拟机实现与 Java 应用的灵活度都是相当大的。例如 "通过一个类的全限定名来获取定义此类的二进制字节流"这条规则，它并没有指明二进制字节流必须地从某个 Class 文件中获取，确切地说是根本没有指明要从哪里获取，如何获取。

仅仅这一点空隙，Java虚拟机的使用者们就可以在加载阶段搭构建出一个相当开放广阔的舞台，Java发展历程中，充满创造力的开发人员则在这个舞台上玩出了各种花样，许多举足轻重的Java技术都建立在这一基础之上，例如：

  • 从ZIP压缩包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。

  • 从网络中获取，这种场景最典型的应用就是Web Applet。

2.2 类模型与 Class 实例的位置

加载的类在 JVM 中创建相应的类结构，类的数据结构会存储在方法区中

每个类对象都对应一个 Class 类型的对象，用来封装类位于方法区内的数据结构，类对象存储在堆中。

JVM成神之路(2): 类的加载

外部可以通过访问堆区的 Class 对象来获取 Order 类的数据结构。这个就是反射的流程，通过 Class 对象作为访问方法区的入口，获取具体的数据结构、方法、字段信息。

2.3 数组类的加载

对于数组类而言，情况就有所不同，数组类本身不通过类加载器创建，它是由Java虚拟机直接在内存中动态构造出来的。但数组类与类加载器仍然有很密切的关系，因为数组类的元素类型（Element Type，指的是数组去掉所有维度的类型）最终还是要靠类加载器来完成加载，一个数组类（下面简称为C）创建过程遵循以下规则：

  • 如果数组的组件类型（Component Type，指的是数组去掉一个维度的类型，注意和前面的元素类型区分开来）是引用类型，那就递归采用本节中定义的加载过程去加载这个组件类型，数组 C 将被标识在加载该组件类型的类加载器的类名称空间上（这点很重要，一个类型必须与类加载器一起确定唯一性）。

  • 如果数组的组件类型不是引用类型（例如 int[] 数组的组件类型为int），Java虚拟机将会把数组C标记为与引导类加载器关联。

  • 数组类的可访问性与它的组件类型的可访问性一致，如果组件类型不是引用类型，它的数组类的可访问性将默认为 public ，可被所有的类和接口访问到。

三、连接阶段

3.1 验证

加载阶段与连接阶段的部分动作（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的一部分，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证是连接阶段的第一步，这一阶段的目的是确保 Class 文件的字节流中包含的信息复合《Java虚拟机规范》的全部约束要求，保证这些信息被当作代码运行后不会危害虚拟机自身的安全。

验证阶段是非常重要的，这个阶段是否严谨，直接决定了 Java 虚拟机是否能承受恶意代码的攻击，从代码量和执行性能的角度上讲，验证阶段的工作量在虚拟机的类加载过程中占了相当大的比重。

从整体上看，验证阶段大致会完成下面四个阶段的校验动作：

  • 文件格式验证
  • 语义检查
  • 字节码验证
  • 符号引用验证

JVM成神之路(2): 类的加载

3.1.1 格式检查

第一阶段要验证字节流是否符号 Class 文件格式的规范，并且能被当前版本的虚拟机处理。这一阶段包括下面验证点：

  • 是否以魔数CAFEBABE开头

  • 主、次版本号是否在当前 Java 虚拟机接收范围内

  • 常量池的常量是否有不被支持的常量类型（检查常量tag标志）

  • 指向常量的各种索引值是否有指向不存在的常量或不符合类型的常量。

  • constant_utf8_info 型的常量中是否有被删除或附加的其他信息。

  • Class 文件中各个部分及文件本身是否有被删除的或附加的其他信息。

实际上第一阶段的验证点还远不止这些，上面所列的只是从HotSpot虚拟机源码中摘抄的一小部分内容，该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区之内，格式上符合描述一个Java类型信息的要求。这阶段的验证是基于二进制字节流进行的，只有通过了这个阶段的验证之后，这段字节流才被允许进入Java虚拟机内存的方法区中进行存储，所以后面的三个验证阶段全部是基于方法区的存储结构上进行的，不会再直接读取、操作字节流了。

3.1.2 语义检查

第二阶段是对字节码描述的信息进行语义分析，以保证其描述的信息符合《Java语言规范》的要求，这个阶段可能包括的验证点如下：

  • 这个类是否有父类（除了java.lang.Object之外，所有的类都应当有父类）。
  • 这个类的父类是否继承了不允许被继承的类（被final修饰的类）。
  • 如果这个类不是抽象类，是否实现了其父类或接口之中要求实现的所有方法。
  • 类中的字段、方法是否与父类产生矛盾（例如覆盖了父类的final字段，或者出现不符合规则的方法重载，例如方法参数都一致，但返回值类型却不同等）。
  • ……

第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在与《Java语言规范》定义相悖的元数据信息。

3.1.3 字节码验证

第三阶段，是整个验证过程中最复杂的，主要目的是通过分析字节码，判断字节码能否被正确执行，不会做出对虚拟机危害动作。

比如 JVM 会验证字节码如下内容：

  • 1、在字节码的执行过程中，是否会跳转到一条不存在的指令

  • 2、函数的调用是否传递了正确类型的参数

  • 3、变量的赋值是不是给了正确的数据类型等

  • 4、保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似于在操作数栈放置了一个 int 类型的数据，使用时却按 long 类型来加载入本地变量表中这样的情况。

如果一个类型中有方法体的字节码没有通过字节码验证，那它肯定是有问题的；

但如果一个方法体通过了字节码验证，也仍然不能保证它一定是安全的。即使字节码验证阶段进行了大量、再严密的检查，也依然不能保证这一点。

3.1.4 符号引用验证

最后一个阶段的校验行为发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。

符号引用验证可以看作是对类自身以外（常量池中的各种符号引用）的各类信息进行匹配性校验，通俗来说就是，该类是否缺少或者被禁止访问它依赖的某些外部类、方法、字段等资源。本阶段通常需要校验下列内容：

  • 符号引用中通过字符串描述的全限定名是否能找到对应的类。

  • 在指定类中是否存在符合方法的字段描述符及简单名称所描述的方法和字段。

  • 符号引用中的类、字段、方法的可访问性（private、protected、public、）是否可被当前类访问。

符号引用验证的主要目的是确保解析行为能正常执行，如果无法通过符号引用验证，

Java 虚拟机将会抛出一个 java.lang.IncompatibleClassChangeError 的子类异常，典型的如：

  • java.lang.IllegalAccessError

  • java.lang.NoSuchFieldError

  • java.lang.NoSuchMethodError等。

验证阶段对于虚拟机的类加载机制来说，是一个非常重要的、但却不是必须要执行的阶段，因为验证阶段只有通过或者不通过的差别，只要通过了验证，其后就对程序运行期没有任何影响了。如果程序运行的全部代码（包括自己编写的、第三方包中的、从外部加载的、动态生成的等所有代码）都已经被反复使用和验证过，在生产环境的实施阶段就可以考虑使用-Xverify：none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

3.2 准备

准备阶段是正式为类中定义的变量（静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段，从概念上来讲，这些变量所使用的内存都应当在方法区中进行分配，但必须注意到方法区本身是一个逻辑上的区域，在JDK7及之前，HotSpot 使用永久代来实现方法区时，实现是完全符合这种逻辑概念的；

而在JDK8及之后，类变量则会随着 Class 对象一起存放 Java 堆中，这时候 “类变量在方法区” 就完全是一种对逻辑概念的表述了。

关于准备阶段，还有两个容易产生混淆的概念笔者需要着重强调，

  • 首先是这时候进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在 Java 堆中。
  • 其次是这里所说的初始值 “通常情况” 下是数据类型的零值，假设一个类变量的定义为：

Public static int value = 123;

那变量 value 在准备阶段过后的初始值为 0 而不是 123 ，因为这时尚未开始执行任何 Java 方法，而把 value 赋值为 123 的 putstatic 指令是程序被编译后，存放于类构造器() 方法之中，所以把 value 赋值为 123 的动作要到类的初始化阶段才会被执行。

JVM成神之路(2): 类的加载

  • 最后就是特殊情况，如果类字段被 final 修饰，那么类阻断的属性表中存在 ConstantValue 属性，那在准备阶段变量值就会被初始化为ConstantValue 属性所指定的初始值，假设上面类变量 value 的定义修改为 123 ,而不是 "零值"

    • Public static final int value = 123

3.3 解析

解析阶段是 Java 虚拟机将常量池内的符号引用替换为直接引用的过程。

符号引用就是例如 CONSTANT_Class_info 等类型的常量出现，那解析阶段中所说的直接引用与符号引用又有什么关联呢？

  • 符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可

  • 直接引用（Direct References）：直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局直接相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

四、初始化阶段

类的初始化是类加载过程的最后一个步骤，Java 虚拟机才真正执行类中编写的 Java 程序代码。

进行准备阶段时，类变量已经赋值过一次初始零值，而在初始化阶段，则会初始化类变量和其他资源。

初始化过程就是执行类构造器() 方法的过程。

  • Clinit 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块中的语句合并产生的，父类的static 语句优先级高于子类

  • Clinit 方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量赋值，就不会生成clinit方法

  • Java虚拟机必须保证一个类的()方法在多线程环境中被正确地加锁同步，如果多个线程同时去初始化一个类，那么只会有其中一个线程去执行这个类的()方法，其他线程都需要阻塞等待，直到活动线程执行完毕()方法。

Jvm 规定了六种情况必须对类进行初始化

  • 1、遇到 new、getstatic、putstatic、invokestatic 的字节码指令；
  • 2、使用反射调用的时候，要进行初始化；
  • 3、初始化类的时候，如果父类没有初始化，先触发父类初始化
  • 4、JVM启动时，用户需要指定一个要执行的主类［包含main()方法的那个类］,JVM会先初始化这个主类。这个类在调用main()方法之前被链接和初始化，main()方法的执行将依次加载，链接和初始化后面需要使用到的类。
  • 5、初次创建MethodHandle实例时，初始化该MethodHandle实例时指向的方法所在的类，即涉及解析REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄对应的类的初始化。
  • 6、当一个接口中定义了 JDK8 新加入的默认方法(default) ，那么实现该接口的类需要提前初始化

4.1 案例1

打印结果想想应该是啥呢？

public class SuperClass {

    public static void main(String[] args) {
        System.out.println(Child.value);
    }
}

class Parent{
    static {
        System.out.println("parent init");
    }
    public static int value =123;
}
class Child extends Parent {
    static {
        System.out.println("child init");
    }
}

结果如下：

parent init
123

因为，我们使用的 value 这个 static 属性属于 parent 类，如果要调用 value，就要初始化 parent 类。

4.2 案例2

public class SuperClass {

    public static void main(String[] args) {
        Parent[] parents = new Parent[2];
}
}

class Parent{
    static {
        System.out.println("parent init");
    }
    public static int value =123;
}
class Child extends Parent {
    static {
        System.out.println("child init");
    }
}

此时不打印结果，即使有 new 关键字，但是我们需要的是 new 的字节码指令，而 new Parent[2] ,对应的字节码指令是 newarray，所以不会初始化。

4.3 案例3

public class SuperClass {

    public static void main(String[] args) {
System.out.println(Child.value2);
    }
}

class Parent{
    static {
        System.out.println("parent init");
    }
    public static int value =123;
    public static final int value2 =456;
}
class Child extends Parent {
    static {
        System.out.println("child init");
    }
}

打印结果为 456， 还是没有触发 parent 的初始化，这是因为 final 在 编译器编译的时候提前存储到 ConstantValue 这个变量中，所以就不会进行初始化了。

五、类加载器

类加载器（ClassLoader）是 Java 虚拟机提供给应用程序去实现获取类和接口字节码数据的技术。

类加载器只参与加载过程中的字节码获取并加载到内存这一部分，至于 class 文件能否运行，则是由执行引擎决定的。

5.1 分类

类加载器分为两类，一类是 Java 代码中实现，一类是 Java 虚拟机底层源码实现。

虚拟机底层实现：

  • 源代码位于 Java 虚拟机的源码，实现语言与虚拟机底层语言一致，比如 Hotspot 使用 C++
  • 保证程序运行时的基础类，保证 Java 程序基础类被正确的架子啊

Java 代码：

  • 自定义类加载器实现，所有的 Java 类实现都需要继承 ClassLoader 这个抽象类

JVM成神之路(2): 类的加载

5.1.1 启动类加载器

  • 启动类加载器（Bootstrap ClassLoader）是由 Hotspot 虚拟机提供的、使用 C++ 编写的类加载器。
  • 用来加载 java 核心库，默认加载 Java 安装目录 /jre/lib 下的类文件，比如 rt.jar，tools.jar，resources.jar等。

JVM成神之路(2): 类的加载

可以通过启动类加载器去加载用户 jar 包

  • 将 jar 包放入 jre/lib 进行扩展（不推荐）：即使放进去，也会出现文件名不匹配的问题而不会正常加载

  • 使用参数进行扩展（推荐）：使用 -Xbootclasspath/a.jar包目录/jar包名 进行扩展

5.1.2 默认加载器

  • 扩展类加载器和应用程序类加载器都是 JDK 中提供的，使用 Java 编写的类加载器。
  • 它们的源码都位于sun.misc.Launcher中，是一个静态内部类。继承自URLClassLoader。具备通过目录或者指定jar包将字节码文件加载到内存中。

扩展类加载器主要负责从java.ext.dirs系统属性所指定的目录或者JDK的安装目录的jre/lib/ext子目录下加载类库。如果用户创建的类放在上述目录下，也会自动由扩展类加载器加载。简言之扩展类加载器主要负责加载Java的扩展库。

JVM成神之路(2): 类的加载

应用程序类加载器：它负责加载用户类路径（ClassPath）上所有的类库，开发者同样可以直接在代码中使用这个类加载器。一般情况下这个就是程序默认的类加载器。

public class ClassLoaderTest1 {

    public static void main(String[] args) {
        // 启动类加载器
        ClassLoader classLoader = Object.class.getClassLoader();
        // 扩展类加载器
        ClassLoader classLoader1 = EventID.class.getClassLoader();
        // 应用类加载器
        ClassLoader classLoader2 = ClassLoaderTest1.class.getClassLoader();
        System.out.println(classLoader);
        System.out.println(classLoader1);
        System.out.println(classLoader2);
    }
}
==================打印结果 ==============
null
sun.misc.Launcher$ExtClassLoader@2437c6dc
sun.misc.Launcher$AppClassLoader@18b4aac2

需要注意的是，启动类加载器结果是null，原因是启动类加载器是 C++语言编写，并不是一个 Java 对象，所以这里用null 展示。

5.1.3 自定义加载器

在 Java 的日常程序开发中，类的加载几乎是前面讲解的3种类加载器相互配合执行的。必要时，还可以自定义类加载器来定制类的加载方式。

自定义类加载器的好处：

  • 插件机制：类加载器对应用程序提供了一种动态增加新功能的机制，这种机制无需重写打包发布应用程序就能实现

  • 隔离加载类：比如 tomcat 内部自定义了好几种类加载器，隔离不同应用同程序，互不干扰

  • 修改类加载的方式：比如可以对 class 文件加密后，再自定义一个类加载器进行解密加载到 jvm

  • 扩展加载源：加载源头可能是db二进制文件、zip文件，加载的文件类型不同，就可以使用不同的类加载器

Java 提供了抽象类 java.lang.ClassLoader, 所有用户自定义的类加载器都应该继承 ClassLoader 类。

在自定义 ClassLoader 子类的时候，常见的两种方式，要么重写 loadClass 方法，或者重写 findClass 方法（推荐）。

注意：不要直接修改 loadClass 方法，最好在双亲委派模型逻辑框架内进行小范围的改动，因此修改 findclass 方法

5.2 双亲委派模型

如果一个类加载器在接到加载类的请求时，它首先不会自己尝试去加载这个类，而是把这个请求任务委托给父类加载器去完成，依次递归，如果父类加载器可以完成类加载任务，就成功返回。只有父类加载器无法完成此加载任务时，才自己去加载。

JVM成神之路(2): 类的加载

5.2.1 作用

1、保证类加载的安全性；（通过双亲委派机制避免恶意代码替换JDK的核心类库，比如Java.lang）

2、避免重复加载；（双亲委派机制可以避免同一个类被多次加载）

5.2.2 核心源码

JVM成神之路(2): 类的加载

public abstract class ClassLoader {
    // 委派的父类加载器
    private final ClassLoader parent;

    public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
    }


    protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // 保证该类只加载一次
        synchronized (getClassLoadingLock(name)) {
            // 首先，检查该类是否被加载
            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);
                }
            }
            if (resolve) {
                resolveClass(c);
            }
            return c;
        }
    }

    protected Class<?> findClass(String name) throws ClassNotFoundException {
        throw new ClassNotFoundException(name);
    }
}

代码的主要步骤如下：

  • 1、先检查类是否已经被加载过

  • 2、若没有加载，则调用父加载器的 loadClass() 方法进行加载

  • 3、若父加载器为空，则默认使用启动类加载器作为父加载器；

  • 4、如果父类加载失败，抛出 ClassNotFoundException 异常后，再调用自己的 findClass（）方法进行加载

5.2.3 打破双亲委派

双亲委派模型并不是一个具有强制性约束的模型，而是Java设计者推荐给开发者的类加载器实现方式。在Java的世界中大部分的类加载器都遵循这个模型，但也有例外的情况，如下所示，注意破坏双亲委派模型并不一定就是一件坏事，如果有特殊需求，完全可以主动破坏双亲委派模型。

a、自定义类加载器

  • 自定义类加载器并且重写 loadClass 方法，就可以将双亲委派机制的代码去除

  • Tomcat 通过这种方式实现应用之间类隔离，每个应用都会有一个独立的类加载器加载对应的类

b、线程上下文加载器

双亲委派模型有一定的局限性，父类加载器无法访问子类加载器路径的类。

双亲委派模型最典型的不适用场景就是 SPI 的使用，所以提供一种线程上下文类加载器，能够使父类加载器调用子类加载器去加载。

JVM成神之路(2): 类的加载

问题：DriverManager 使用 SPI 机制，最终加载 jar 包中对应的驱动类？

答：SPI 中使用了线程上下文中保存的类加载器进行类的加载，这个类加载器一般是应用程序类加载器。

ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();

SPI 机制：

  • SPI 全称为（Service Provider Interface），是JDK内置的一种服务提供发现机制。

  • SPI 的工作原理：

    • 1、在 ClassPath 路径下的 META-INF/services文件夹中，以接口的全限定名来命名文件名，对应的文件里面写该接口的实现。
    • JVM成神之路(2): 类的加载
    • 2、使用ServiceLoader加载实现类；
    • 3、SPI 中利用了线程上下文类加载器（应用程序类加载器）去加载类并创建对象。

思考：JDBC 案例真的打破了双亲委派机制吗？

1、打破了双亲委派机制：

  • 这种由启动类加载器加载的类，委派应用程序类加载器去加载类的方式，打破了双亲委派机制。

2、没有打破双亲委派机制：

  • JDBC 只是在 DriverManager 加载完之后，通过初始化阶段触发了驱动类的加载，类的加载依然遵循双亲委派机制，打破双亲委派机制的唯一方法就是重写 ClassLoad 方法。

小结

本文主要介绍了 JVM 将 class 文件加载到内存中经历的过程，这个过程可分为加载、链接和初始化三步骤。

  • 加载阶段主要负责根据二进制数据创建类模板对象
  • 链接分为验证、准备、解析
  • 初始化为类变量赋值，执行 clinit 方法。

然后介绍加载过程用到的类加载器，以及双亲委派模型。

转载自:https://juejin.cn/post/7341408996598448147
评论
请登录