第二章

目录

待补充

1.内存结构概述

第02章_JVM架构-简图

image-20201118110635578

假设我们想自己手写一个Java虚拟机的话，必须考虑哪些结构

  • 类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。

  • ClassLoader只负责class文件的加载，至于它是否可以运行，则由Execution Engine决定。

  • 加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

2.类加载子系统

2.1 类加载器子系统的作用

类加载器子系统负责从文件系统或者网络中加载Class文件，class文件在文件开头有特定的文件标识。

ClassLoader只负责.class文件的加载，至于它是否可以运行，则由Execution Engine决定。

加载的类信息存放于一块称为方法区的内存空间。除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量池部分的内存映射）

面试题：Java8中的JVM元空间是不是方法区？

严格来说，不是。

  1. 首先，方法区是JVM规范的一个概念定义，并不是一个具体的实现，每一个JVM的实现都可以有各自的实现；
  2. 然后，在Java官方的HotSpot 虚拟机中，Java8版本以后，是用元空间来实现的方法区；在Java8之前的版本，则是用永久代实现的方法区；
  3. 也就是说，“元空间” 和 “方法区”，一个是HotSpot 的具体实现技术，一个是JVM规范的抽象定义；

所以，并不能说“JVM的元空间是方法区”，但是可以说在Java8以后的HotSpot 中“元空间用来实现了方法区”。

然后多说一句，这个元空间是使用本地内存（Native Memory）实现的，也就是说它的内存是不在虚拟机内的，所以可以理论上物理机器还有多个内存就可以分配，而不用再受限于JVM本身分配的内存了。参考：http://openjdk.java.net/jeps/122

作者：Butters
链接：https://www.zhihu.com/question/358312524/answer/965401488
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

image-20201118111616428

2.2 类加载器ClassLoader角色

image-20201118115336469

  • class file存在于本地硬盘上，可以理解为设计师画在纸上的模板，而最终这个模板在执行的时候是要加载到JVM当中来根据这个文件实例化出n个一模一样的实例。
  • class file加载到JVM中，被称为DNA元数据模板，放在方法区。
  • 在.class文件 –> JVM –> 最终成为元数据模板，此过程就要一个运输工具（类装载器Class Loader），扮演一个快递员的角色。

2.3 类的加载过程

/**
 * @author xiexu
 * @create 2020-11-18 11:57 上午
 */
public class HelloLoader {

    public static void main(String[] args) {
        System.out.println("谢谢ClassLoader加载我....");
        System.out.println("你的大恩大德，我下辈子再报！");
    }

}

它的加载过程是怎么样的呢?

  • 执行 main( ) 方法（静态方法）就需要先加载承载类 HelloLoader
  • 加载成功，则进行链接、初始化等操作，完成后调用 HelloLoader 类中的静态方法 main
  • 加载失败则抛出异常

第02章_类的加载过程

完整的流程图如下所示：加载 --> 链接（验证 --> 准备 --> 解析） --> 初始化 -->使用 --> 卸载

img

注意：此处的类加载指的是一个.class文件的加载，在Java中.class文件可能是一个类，也可能是一个接口。此处都叫做类加载。整个类加载的过程即：加载→验证→准备→解析→初始化。概括地说即：

img

这里还需要注意：从类的加载→验证→准备→初始化，过程是按顺序依次开始的，但是解析比较特殊。为了支持java语言的晚期绑定/动态绑定，有时解析可以在初始化之后才开始。

而且，这里写的是开始顺序，（不代表是按照这个顺序依次进行或者依次完成）一个阶段通常执行的过程中会激活调用另一个阶段，所以各个阶段只是按照这个顺序开始，而不会等一个阶段完全完成后才进行下一个阶段，各个阶段是交叉混合进行的，所以各阶段并不会严格按照此顺序结束。

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

2.3.1 加载(Loading)阶段

加载

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

将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构

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

某个类的java.lang.Class对象，即通常所说的一个类的类对象，这个类对象作为程序调用这个类中方法和数据调用的入口。

最常见的一种情况是将已存在的类的Class文件（也就是字节码文件）从磁盘上面加载到内存里面，将其放在运行时数据区的方法区中，然后在内存中创建一个java.lang.Class对象用来封装类在方法区中的数据结构

加载.class文件的方式
  • 从本地系统中直接加载
  • 通过网络获取，典型场景：Web Applet
  • 从zip压缩包中读取，成为日后jar、war格式的基础
  • 运行时计算生成，使用最多的是：动态代理技术
  • 由其他文件生成，典型场景：JSP应用
  • 从专有数据库中提取.class文件，比较少见
  • 从加密文件中获取，典型的防Class文件被反编译的保护措施

我们需要注意的是：

  • 对于方法区的认识：被加载的类的信息存储在方法区中，可以被线程所共享，也就是说，加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在了方法区之中。 那个二进制流中都存储了哪些信息吗？

  • 加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式是由虚拟机是实现自行定义的 ,虚拟机并未归档此区域的具体数据结构。

  • 在内存中实例化的java.lang.Class类的对象虽然是在内存中，但并未明确规定是在Java堆中，对于HotSpot来说，Class对象存储在方法区中。它作为程序访问方法区中二进制字节流中所存储各种数据的接口。

    你能大概想到反射机制中的Class对象是怎么一回事了吗？为什么可以在运行期通过反射机制得到那么多的类信息？你能猜测到吗？

相对于类加载过程 的其他阶段:

  • 一个 非数组类的加载阶段 (准确来说,是加载阶段中获取类的二进制字节流的动作) 是开发人员可控性最强的

    因为加载阶段既可以使用系统提供的类加载器来完成,也可以由通过用户自定义的类加载器来完成,

    开发人员可以通过定义一个自己的类加载器从而控制字节流的获取方式 (即重写一个类加载器的loadClass()方法)

类对象生成的方式:具体可以看这篇文章：深入理解Java对象的创建过程：类的初始化与实例化

  • 1). 使用new关键字创建对象

  • 2). 使用Class类的newInstance方法(反射机制)

  • 3). 使用Constructor类的newInstance方法(反射机制)

  • 4). 使用Clone方法创建对象

  • 5). 使用(反)序列化机制创建对象。

2.3.2 链接(Linking)阶段(后续需要补充)

链接分为三个子阶段：验证 --> 准备 --> 解析

在这里插入图片描述

验证(Verify)

验证原因：

目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全

连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

Java语言本身是相对安全的语言，使用Java编码是无法做到如访问数组边界以外的数据、将一个对象转型为它并未实现的类型等，如果这样做了，编译器将拒绝编译。但是，Class文件并不一定是由Java源码编译而来，可以使用任何途径，包括用十六进制编辑器(如UltraEdit)直接编写来产生Class文件。

在字节码语言层面上，上述Java代码无法做到的事情都是可以实现的，至少语义上是可以表达出来的。

如果直接编写了有害的“代码”(字节流)，而虚拟机在加载该Class时不进行检查输入的字节流的话，就有可能危害到虚拟机或程序的安全。

验证阶段对于虚拟机的类加载机制来说，不一定是必要的阶段。如果所运行的全部代码确认是安全的， 可以使用 -Xverify：none 参数来关闭大部分的类验证措施，以缩短虚拟机类加载时间。

验证阶段 的四个动作：

不同的虚拟机，对类验证的实现可能有所不同，但大致都会完成下面四个阶段的验证 ：文件格式验证，元数据验证，字节码验证，符号引用验证。

img

文件格式验证:

是要验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。

  • 如验证魔数是否0xCAFEBABE开头；
  • 主、次版本号是否正在当前虚拟机处理范围之内；
  • 常量池的常量中是否有不被支持的常量类型……
  • 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
  • CONSTANT_Utf8_info型的常量中是否有不符合Utf8编码的数据
  • 该验证阶段的主要目的是保证输入的字节流能正确地解析并存储于方法区中，经过这个阶段的验证后，字节流才会进入内存的方法区中存储，所以后面的三个验证阶段都是基于方法区的存储结构进行的。
元数据验证

是对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。

这里有的朋友可能会比较疑惑，什么是元数据呢？一般情况下，一个文件中都数据和元数据。数据指的是实际数据，而元数据（Metadata）是用来描述数据的数据。用过Java注解的朋友应该对元数据这种叫法并不陌生，对应的元注解，其实说的差不多都是一个意思。

举个例子：比如说我们定义了一个变量 int a = 1；可以理解成数据就是1，而元数据就是堆1的具体描述：有一个字符串变量“a”，这个“a”的类型是int型的，它的值也是一个int型的1，这就是描述数据的数据，就是元数据。

可能包括的验证如：

  • 这个类是否有父类；
  • 这个类的父类是否继承了不允许被继承的类；
  • 如果这个类不是抽象类，是否实现了其父类或接口中要求实现的所有方法……
  • 类中字段，方法是否与父类产生矛盾
字节码验证

主要工作是进行数据流和控制流分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。

第二阶段中对元数据信息中的数据类型作完校验后，这个阶段将会对类的方法体进行校验分析。

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

但如果一个方法体通过了字节码验证，也不能说明其一定就是安全的。

  • 保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作，例如不会出现类似这样的情况：在操作数栈放置了一个int类型的数据，使用时却按long类型来加载入本地变量表中。
  • 保证跳转指令不会跳转到方法体以外的字节码指令上。
  • 保证方法体中的类型转换是有效的，例如可以把一个子类对象赋值给父类数据类型，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个数据类型，则是危险不合法的。
符号引用验证

链接的第三个阶段--解析阶段中发生。虚拟机将符号引用转换成为直接引用

符号引用验证可以看作是类对自身以外（常量池中的各种符号引用）的信息进行匹配性校验，通常需要校验以下内容：

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

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

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

使用 BinaryViewer 查看字节码文件，其开头均为 CAFE BABE ，如果出现不合法的字节码文件，那么将会验证不通过

image-20200727154651965

准备(Prepare)

  • 为类变量分配内存并且设置该类变量的默认初始值，即零值，这些类变量所使用的内存都将在方法区中进行分配。

  • 这时候进行内存分配的仅仅包括类变量（被static修饰的变量），而不包括实例变量

  • 这里不包含用final修饰的static，因为final在编译的时候就会分配好了默认值，准备阶段会显式初始化

  • 这里说的“初始值”通常情况下数据类型的零值

    假设一个类变量的定义为：

    public static int value =123;

    那变量value在准备阶段过后的初始值为0而不是123，因为这时候尚未开始执行任何Java

    方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器＜clinit＞（）方

    法之中，所以把value赋值为123的动作将在初始化阶段才会执行。

    表7-1列出了Java中所有基本数据类型的零值。

    img

    上面提到，在“通常情况”下初始值是零值，那相对的会有一些“特殊情况”：如果类字段

    的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为

    ConstantValue属性所指定的值，假设上面类变量value的定义变为：

    public static final int value=123；

    编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据

    ConstantValue的设置将value赋值为123。

  • 注意：这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中

举例：

// 变量a在准备阶段会赋初始值，但不是1，而是0，在初始化阶段会被赋值为 1
    
public class HelloApp {
    private static int a = 1;   //prepare：a = 0 ---> initial : a = 1

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

解析(Resolve)

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，在Class文件中他以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量飙戏那，那解析阶段中所说的直接引用与符号引用又有什么关联呢？

符号引用（Symbolic References）：

  • 符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。

  • 各种虚拟机实现的内存布局可以各不相同，但是他们能接受的符号引用必须都是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。

image-20201118122836935

直接引用（Direct References）：

  • 直接引用可以是直接指向目标的指针、相对偏移量或是一个能简介定位到目标的句柄。

  • 直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

    ​

    ​

解析时机

虚拟机规范之中并未规定解析阶段发生的具体实现，只要求了:

  • 在执行anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield和putstatic这16个用于操作符号引用的字节码指令之前，先对他们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类被加载器加载时就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前才去解析他。

对解析结果进行缓存

  • 对同一个符号引用进行多次解析请求是很常见的事情
  • 除invokedynamic指令以外，虚拟机实现可以对第一次解析的结果进行缓存
    • （在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。
    • 无论是否真正执行了多次解析动作，虚拟机需要保证的是在同一个实体中，如果一个符号引用之前已经被成功解析过，那么后续的 引用解析请求就应当一直成功；
    • 如果第一次解析失败了，那么其他指令对这个符号的解析请求也应该受到相同的异常。

特殊例外对解析结果不用缓存

  • 对于invokedynamic指令，上面规则则不成立。
    • 当碰到某个前面已经由invokedynamic指令触发过解析的符号引用时，并不意味着这个解析结果对于其他invokedynamic指令也同样生效。
    • 因为invokedynamic指令的目的本来就是用于动态语言支持（目前仅使用Java语言不会生成这条字节码指令），它所对应的引用称为“动态调用点限定符”（Dynamic Call Site Specifier）
    • 这里“动态”的含义就是必须等到程序实际运行到这条指令的时候，解析动作才能进行。
    • 相对的，其余可触发解析的指令都是“静态”的，可以在刚刚完成加载阶段，还没有开始执行代码时就进行解析。

解析动作针对的符号引用有哪些?

	解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行，

	分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、
	
	CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和  
    
    CONSTANT_InvokeDynamic_info 7种常量类型。
Symbolic Reference to Structure in class file
class CONSTANT_Class_info
field CONSTANT_Fieldref_info
class method CONSTANT_Methodref_info
interface method CONSTANT_InterfaceMethodref_info
method handle CONSTANT_MethodHandle_info
method type CONSTANT_MethodType_info
call site specifier CONSTANT_InvokeDynamic_info

下面将讲解前面4种引用的解析过程。

类或接口的解析
假设当前代码所处的类为D，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机完成整个解析的过程需要以下3个步骤：
  1. 如果C不是一个数组类型，那虚拟机将会把代表N的全限定名传递给D的类加载器去加载这个类C。在加载过程中，由于元数据验证、字节码验证的需要，又可能触发其他相关类的加载动作，例如加载这个类的父类或实现的接口。一旦这个加载过程出现了任何异常，解析过程就宣告失败。
  2. 如果C是一个数组类型，并且数组的元素类型为对象，也就是N的描述符会是类似“[Ljava/lang/Integer”的形式，那将会按照第1点的规则加载数组元素类型。如果N的描述符如前面所假设的形式，需要加载的元素类型就是“java.lang.Integer”，接着由虚拟机生成一个代表此数组维度和元素的数组对象。
  3. 如果上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成之前还要进行符号引用验证，确认D是否具备对C的访问权限。如果发现不具备访问权限，将抛出java.lang.IllegalAccessError异常。
字段解析
要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或接口的符号引用。如果在解析这个类或接口符号引用的过程中出现了任何异常，都会导致字段符号引用解析的失败。如果解析成功完成，那将这个字段所属的类或接口用C表示，虚拟机规范要求按照如下步骤对C进行后续字段的搜索。

  1. 如果C本身就包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

  2. 否则，如果在C中实现了接口，将会按照继承关系从下往上递归搜索各个接口和他的父接口，如果接口中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段的直接引用，查找结束。

  3. 否则，如果C不是java.lang.Object的话，将会按照继承关系从下往上递归搜索其父类，如果在父类中包含了简单名称和字段描述符都与目标相匹配的字段，则返回这个字段直接引用，查找失败。

  4. 否则，查找失败，抛出java.lang.NoSuchFieldError异常。

    如果查找过程成功返回了引用，将会对这个字段进行权限验证，如果发现不具备对字段的访问权限，将抛出java.lang.IllegalAccessError异常。

    在实际应用中，虚拟机的编译器实现可能会比上述规范要求的更加严格一些，如果有一个同名字段同时出现在C的接口和父类中，或者同时在自己或父类的多个接口中出现，那编译器将可能拒绝编译。在下面代码示例中，如果注释了Sub类中的“public static int A=4; ”，接口与父类同时存在字段A，那编译器将提示“The field Sub.A is ambiguous”，并且拒绝编译这段代码。

    public class FieldResolution {

interface Interface0 {
int A = 0;
}

interface Interface1 extends Interface0 {
int A = 1;
}

interface Interface2 {
int A = 2;
}

static class Parent implements Interface1 {
public static int A = 3;
}

static class Sub extends Parent implements Interface2 {
public static int A = 4;
}

public static void main(String[] args) {
System.out.println(Sub.A);
}
}
类方法解析
类方法解析的第一个步骤与字段解析一样，也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，我们依然用C表示这个类，接下来虚拟机将会按照如下步骤进行后续的类方法搜索。

  1. 类方法和接口方法符号引用的常量类型定义是分开的，如果在类方法表中发现class_index中索引的C是个接口，那就直接抛出java.lang.IncompatibleClassChangeError异常。

  2. 如果通过了第1步，在类C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。

  3. 否则，在类C的父类中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。

  4. 否则，在类C实现的接口列表及他们的父接口之中递归查找是否有简单名称和描述符都与目标相匹配的方法，如果存在匹配的方法，说明类C是一个抽象，这时查找结束，抛出java.lang.AbstractMethodError异常。

  5. 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError。

    最后，如果查找过程成功返回了直接引用，将会对这个方法进行权限验证，如果发现不具备对此方法的访问权限，将抛出java.lang.IllegalAccessError异常。

接口方法解析
接口方法也需要先解析出接口方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，依然用C表示这个接口，接下来虚拟机将会按照如下步骤进行后续的接口方法搜索。
  1. 与类方法解析不同，如果在接口方法表中发现class_index中的索引C是个类而不是接口，那就直接抛出java.lang.IncompatibleClassChangeError异常。
  2. 否则，在接口C中查找是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
  3. 否则，在接口C的父接口中递归查找，直到java.lang.Object（查找范围会包括Object类）为止，看是否有简单名称和描述符都与目标相匹配的方法，如果有则返回这个方法的直接引用，查找结束。
  4. 否则，宣告方法查找失败，抛出java.lang.NoSuchMethodError异常。
  5. 由于接口中的所有方法默认都是public，所以不存在访问权限的问题，因此接口方法的符号解析应当不会抛出java.lang.IllegalAccessError异常。

总结

  • 将常量池内的符号引用转换为直接引用的过程
  • 事实上，解析操作往往会伴随着JVM在执行完初始化之后再执行
  • 符号引用就是一组符号来描述所引用的目标。符号引用的字面量形式明确定义在《java虚拟机规范》的class文件格式中。
  • 直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄
  • 解析动作主要针对类或接口、字段、类方法、接口方法、方法类型等。对应常量池中的CONSTANT Class info、CONSTANT Fieldref info、CONSTANT Methodref info等

2.3.3 初始化(Initialization)阶段 （待解释）

一个类 它往内存中加载的话，只需要加载一次就可以了 加载完之后，把它放在 方法区,方法区在jdk8的时候 用的是 元空间
元空间实际使用的是本地内存。也就是我们把类加载在内存中以后，使用的是直接内存给缓存起来了，之后你再使用这个类的话，实际上都是使用 内存中已经存在的类本身。虚拟机执行类加载就只会调用一次()方法

  • 初始化阶段就是执行类构造器方法<clinit>()的过程

  • 此方法不需定义，是javac编译器自动收集类中的两类信息合并而来的：

    • 所有类变量的赋值动作

    • 静态代码块中的语句

      也就是说，当我们代码中包含static变量的时候，就会有<clinit>( )方法；如果当前类不存在static变量，那么它的字节码文件是不会存在<clinit>( )

  • <clinit>()方法中的指令按语句在源文件中出现的顺序执行,静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以进行赋值，但不能访问。

  • <clinit>()不同于类的构造器。（关联：构造器是虚拟机视角下的<init>()）

  • 若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕

  • 虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

    <clinit>方法由静态变量赋值代码和静态代码块组成；

    <init>()方法由非静态变量、非静态代码块以及对应的构造器组成

    作者：cscw 链接：https://zhuanlan.zhihu.com/p/187019875 来源：知乎

    IDEA安装 JClassLib 插件
    image-20201120085537704 image-20201120090718024

    注意点：当我们代码中包含static变量的时候，就会有clinit方法
 /**
 * @author xiexu
 * @create 2020-11-20 8:50 上午
 */
public class ClassInitTest {
    private static int num = 1; // 变量num在准备阶段会赋初始值，但不是1，而是0，在初始化阶段会被赋值为 1

    static {
        num = 3; // <clinit>()方法中的指令按语句在源文件中出现的顺序执行 num先被赋值程 ，后被赋值成3
    }
    

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

image-20201120091316647

clinit方法的指令集：

0 iconst_1    // 将int型1推送至栈顶
1 putstatic #3 <com/atguigu/java/ClassInitTest.num>  // 从栈顶取值，存入静态变量com/atguigu/java/ClassInitTest.num中
4 iconst_3  //// 将int型3推送至栈顶
5 putstatic #3 <com/atguigu/java/ClassInitTest.num> // 从栈顶取值，存入静态变量com/atguigu/java/ClassInitTest.num中
8 return

注意点2：如果当前类不存在static变量，那么它的字节码文件是不会存在( )

public class ClinitTest {
    private int a = 1;

    public static void main(String[] args) {
        int b = 2;
    }

}

image-20201120102529199

注意点3：编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问

即：<clinit>()方法中的指令按语句在源文件中出现的顺序执行

/**
 * @author xiexu
 * @create 2020-11-20 8:50 上午
 */
public class ClassInitTest1 {
   private static int num = 1;

   static{
       num = 3;
       number = 20;
       System.out.println(num);
       //System.out.println(number);//报错：非法的前向引用。
   }

   private static int number = 10;  //prepare: number = 0 ， initial:number= 20 --> 10

    public static void main(String[] args) {
        System.out.println(ClassInitTest1.num);//2
        System.out.println(ClassInitTest1.number);//10
    }
}

静态变量 number 的值变化过程如下

  • 准备阶段时：默认初始化 0
  • 执行静态代码块：20
  • 执行静态变量初始化：10
0 iconst_1 // 将int型1推送至栈顶
1 putstatic #3 <com/atguigu/java/ClassInitTest1.num> // 从栈顶取值，存入静态变量com/atguigu/java/ClassInitTest1.num中
4 iconst_3  //将int型3推送至栈顶
5 putstatic #3 <com/atguigu/java/ClassInitTest1.num> // 从栈顶取值，存入静态变量com/atguigu/java/ClassInitTest1.num中
8 bipush 20 //采用bipush指令将常量20压入栈中
10 putstatic #5 <com/atguigu/java/ClassInitTest1.number> // 从栈顶取值，存入静态变量com/atguigu/java/ClassInitTest1.number中
13 getstatic #2 <java/lang/System.out>  // Get static field from class 
16 getstatic #3 <com/atguigu/java/ClassInitTest1.num> //Get static field from class 
19 invokevirtual #4 <java/io/PrintStream.println>   // 目前暂时未知。。。。。。 Invoke instance method; dispatch based on class
22 bipush 10
24 putstatic #5 <com/atguigu/java/ClassInitTest1.number>
27 return

image-20210823164957814

JVM基本类型字符解释表

字符 类型 含义
B byte 有符号字节型数
C char Unicode字符，UTF-16编码
D double 双精度浮点数
F float 单精度浮点数
I int 整型数
J long 长整数
S short 有符号短整数
L reference 一个名为class的实例
Z boolean 布尔值
[ reference 数组

image-20210823164923592

image-20210823165103088

image-20210823170025995

构造器是虚拟机视角下的()

public class ClinitTest {
    //任何一个类声明以后，内部至少存在一个类的构造器
    private int a = 1;
    private static int c = 3;

    public static void main(String[] args) {
        int b = 2;
    }

    public ClinitTest(){
        a = 10;
        int d = 20;
    }

}

image-20201120100952636

  • 在构造器中：

    • 先将类变量 a 赋值为 10

    • 再将局部变量赋值为 20

注意点4：若该类具有父类，JVM会保证子类的<clinit>()执行前，父类的<clinit>()已经执行完毕

因此在Java虚拟机中第一个被执行的<clinit>()方法的类型肯定是java.lang.Object。

public class ClinitTest1 {
    static class Father{
        public static int A = 1;
        static{
            A = 2;
        }
    }

    static class Son extends Father{
        public static int B = A;
    }

    public static void main(String[] args) {
        //加载Father类，其次加载Son类。
        System.out.println(Son.B); //2
    }
}

  • 如上代码，加载流程如下：

    • 首先，执行 main( ) 方法需要加载 ClinitTest1 类

    • 获取 Son.B 静态变量，需要加载 Son 类

    • Son 类的父类是 Father 类，所以需要先执行 Father 类的加载，再执行 Son 类的加载

注意点5：虚拟机必须保证一个类的<clinit>()方法在多线程下被同步加锁

public class DeadThreadTest {
    public static void main(String[] args) {
        Runnable r = () -> {
            System.out.println(Thread.currentThread().getName() + "开始");
            DeadThread dead = new DeadThread();
            System.out.println(Thread.currentThread().getName() + "结束");
        };

        Thread t1 = new Thread(r, "线程1");
        Thread t2 = new Thread(r, "线程2");

        t1.start();
        t2.start();
          // 同步加锁   线程1   线程2   都启动，但是一个线程一直调用while 出不来， 第二个线程无法进入执行。
    }
}
 // 一直执行 while 块
class DeadThread {
    static { // 一直执行 while 块
        if (true) {
            System.out.println(Thread.currentThread().getName() + "初始化当前类");
            while (true) {

            }
        }
    }
}

  • 程序卡死，分析原因：

    • 两个线程同时去加载 DeadThread 类，而 DeadThread 类中静态代码块中有一处死循环
    • 先加载 DeadThread 类的线程抢到了同步锁，然后在类的静态代码块中执行死循环，而另一个线程在等待同步锁的释放
    • 所以无论哪个线程先执行 DeadThread 类的加载，另外一个类也不会继续执行

image-20201120102242078

面试题：为什么饿汉式单例是线程安全的？

标准回答：我们都知道，饿汉式单例是线程安全的，也就是不会初始化的时候创建出两个对象来，但是为什么呢？

首先定义一个饿汉式单例如下：

  public class Singleton {
    // 私有化构造方法，以防止外界使用该构造方法创建新的实例
    private Singleton(){
    }
    // 默认是public，访问可以直接通过Singleton.instance来访问
    static Singleton instance = new Singleton();
}

之所以是线程安全的，是因为JVM在类加载的过程，保证了不会初始化多个static对象。类的生命周期主要是：

加载-->验证-->准备-->解析-->初始化-->使用-->卸载

上面的代码，实际上类成员变量instance是在初始化阶段的时候完成初始化，所有的类变量以及static静态代码块，都是在一个叫clinit()的方法里面完成初始化。这一点，使用jclasslib可以看出来：

img

clinit()方法是由虚拟机收集的，包含了static变量的赋值操作以及static代码块，所以我们代码中的static Singleton instance = new Singleton();就是在其中。

虚拟机本身会保证clinit()代码在多线程并发的时候，只会有一个线程可以访问到，其他的线程都需要等待，并且等到执行的线程结束后才可以接着执行，但是它们不会再进入clinit()方法，所以是线程安全的。我们可以验证一下：

首先改造一下单例：

class Single {
    // 私有化构造方法，以防止外界使用该构造方法创建新的实例,保证外部获取single只能是同一个
    private Single(){
    }
    // 给外部提供的方法：返回单例instance
    public static Single getInstance() {
        return instance;
    }
   static Single instance;
    static {
        System.out.println( Thread.currentThread().getName()+ " 进入static {} 静态代码块中。。。。");
        try {
            System.out.println(Thread.currentThread().getName() + "正在初始化。。。。。。");
            instance  = new Single();
            Thread.sleep(30);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        System.out.println(Thread.currentThread().getName()+ " 出static {} 静态代码块中。。。。");
    }
}

测试代码：

public class SingleTest {

    public static void main(String[] args) {
        Runnable runnable = new Runnable() {
            @Override
            public void run() {
                Single instance = Single.getInstance();
                System.out.println(instance);
            }
        };
        Thread thread1 = new Thread(runnable, "t1");
        Thread thread2 = new Thread(runnable, "t2");
        thread1.start();
        thread2.start();
    }
}

运行结果，一开始运行的时候，我们可以看到线程1进去了static代码块，它在初始化，线程2则在等待。

image-20210823184551648

待到线程1初始化完成的时候，线程2也不会再进入static代码块，而是和线程1取得同一个对象，由此可见，static代码块实际上就是线程安全的。

image-20210823184616336

3.类加载器的分类

  • JVM支持两种类型的类加载器 。分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User-Defined ClassLoader）

  • 从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器

  • 无论类加载器的类型如何划分，在程序中我们最常见的类加载器始终只有3个，如下所示

image-20201120104305271

为什么 ExtClassLoader 和 AppClassLoader 都属于自定义加载器

  • 规范定义：所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器
    image-20201120104448251

  • ExtClassLoader 继承树
    image-20200727170837538

  • AppClassLoader 继承树
    image-20200727170918037

    /**
 * 注意：getParent() 只是获取上层的加载器，并不是继承关系
 * @author xiexu
 * @create 2020-11-20 10:49 上午
 */
public class ClassLoaderTest {
    public static void main(String[] args) {

        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

        //获取其上层：扩展类加载器
        ClassLoader extClassLoader = systemClassLoader.getParent();
        System.out.println(extClassLoader); //sun.misc.Launcher$ExtClassLoader@61bbe9ba

        //获取其上层：获取不到引导类加载器
        ClassLoader bootstrapClassLoader = extClassLoader.getParent();
        System.out.println(bootstrapClassLoader); //null

        //对于用户自定义类来说：默认使用系统类加载器进行加载
        ClassLoader classLoader = ClassLoaderTest.class.getClassLoader();
        System.out.println(classLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

        //String类使用引导类加载器进行加载的。--> Java的核心类库都是使用引导类加载器进行加载的。
        ClassLoader classLoader1 = String.class.getClassLoader();
        System.out.println(classLoader1); //null

    }
}

  • 我们尝试获取引导类加载器，获取到的值为null，这并不代表引导类加载器不存在，因为引导类加载器是由 C/C++ 语言构成的，所以我们是获取不到

  • 两次获取系统类加载器的值都相同：sun.misc.Launcher$AppClassLoader@18b4aac2 ，这说明系统类加载器是全局唯一的

3.1 虚拟机自带的加载器

3.1.1 启动类加载器(引导类加载器)

启动类加载器（ 引导类加载器，Bootstrap ClassLoader ）

  • 这个类加载使用C/C++语言实现的，嵌套在JVM内部
  • 它用来加载Java的核心库（JAVA_HOME / jre / lib / rt.jar、resources.jar 或 sun.boot.class.path 路径下的内容），用于提供JVM自身需要的类
  • 并不继承自java.lang.ClassLoader，没有父加载器
  • 加载扩展类和应用程序类加载器，并作为他们的父类加载器（当他俩的爹）
  • 出于安全考虑，Bootstrap启动类加载器只加载包名为java、javax、sun等开头的类

3.1.2 扩展类加载器

扩展类加载器（Extension ClassLoader）

  • Java语言编写，由sun.misc.Launcher$ExtClassLoader实现
  • 派生于ClassLoader类
  • 父类加载器为启动类加载器
  • 从java.ext.dirs系统属性所指定的目录中加载类库，或从JDK的安装目录的 jre / lib / ext子目录（扩展目录）下加载类库。如果用户创建的 JAR 放在此目录下，也会自动由扩展类加载器加载

3.1.3 系统类加载器

应用程序类加载器（系统类加载器，AppClassLoader）

  • Java语言编写，由sun.misc.LaunchersAppClassLoader实现

  • 派生于ClassLoader类

  • 父类加载器为扩展类加载器

  • 它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库

  • 该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载的

  • 通过classLoader.getSystemclassLoader( )方法可以获取到该类加载器

    代码说明

public class ClassLoaderTest1 {
    public static void main(String[] args) {

        System.out.println("**********启动类加载器**************");
        //获取BootstrapClassLoader能够加载的api的路径
        URL[] urLs = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL element : urLs) {
            System.out.println(element.toExternalForm());
        }
        //从上面的路径中随意选择一个类,来看看他的类加载器是什么:引导类加载器
        ClassLoader classLoader = Provider.class.getClassLoader();
        System.out.println(classLoader); //null

        System.out.println("***********扩展类加载器*************");
        String extDirs = System.getProperty("java.ext.dirs");
        for (String path : extDirs.split(";")) {
            System.out.println(path);
        }

        //从上面的路径中随意选择一个类,来看看他的类加载器是什么:扩展类加载器
        ClassLoader classLoader1 = CurveDB.class.getClassLoader();
        System.out.println(classLoader1);//sun.misc.Launcher$ExtClassLoader@1540e19d

    }
}

System.out.println(classLoader); //null 再次证明我们无法获取到启动类加载器

**********启动类加载器**************
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/resources.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/rt.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/sunrsasign.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/jsse.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/jce.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/charsets.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/jfr.jar
file:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/classes
null
***********扩展类加载器*************
/Users/xiexu/Library/Java/Extensions:/Library/Java/JavaVirtualMachines/jdk1.8.0_241.jdk/Contents/Home/jre/lib/ext:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
sun.misc.Launcher$ExtClassLoader@d716361

加载器的执行流程图

image-20201120111605341

3.2 用户自定义类加载器

为什么需要自定义类加载器？

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。

  • 隔离加载类

  • 修改类加载的方式

  • 扩展加载源

  • 防止源码泄露

如何自定义类加载器？

  • 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求

  • 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass( )方法，从而实现自定义的类加载类，但是在JDK1.2之后已不再建议用户去覆盖loadClass( )方法，而是建议把自定义的类加载逻辑写在findclass( )方法中

  • 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URIClassLoader类，这样就可以避免自己去编写findclass( )方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

代码举例：

public class CustomClassLoader extends ClassLoader {
    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {

        try {
            byte[] result = getClassFromCustomPath(name);
            if (result == null) {
                throw new FileNotFoundException();
            } else {
                return defineClass(name, result, 0, result.length);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        }

        throw new ClassNotFoundException(name);
    }

    private byte[] getClassFromCustomPath(String name) {
        //从自定义路径中加载指定类:细节略
        //如果指定路径的字节码文件进行了加密，则需要在此方法中进行解密操作。
        return null;
    }

    public static void main(String[] args) {
        CustomClassLoader customClassLoader = new CustomClassLoader();
        try {
            Class<?> clazz = Class.forName("One", true, customClassLoader);
            Object obj = clazz.newInstance();
            System.out.println(obj.getClass().getClassLoader());
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

3.3 关于 ClassLoader

  • ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括启动类加载器）
方法名称 描述
getParent( ) 返回该类加载器的超类加载器
loadClass(String name) 加载名称为name的类，返回结果为java.lang.Class类的实例
findClass(String name) 查找名称为name的类，返回结果为java.lang.Class类的实例
findLoadedClass(String name) 查找名称为name的已经被加载过的类，返回结果为java.lang.Class类的实例
defineClass(String name,byte[ ] b,int len) 把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的实例
resolveClass(Class<?> c) 连接指定的一个Java类
  • sun.misc.Launcher 它是一个java虚拟机的入口应用

image-20200705103636003

3.3.1 获取 ClassLoader 的途径

image-20200727194135198

public class ClassLoaderTest2 {
    public static void main(String[] args) {
        try {

            //1.Class.forName().getClassLoader()
            ClassLoader classLoader = Class.forName("java.lang.String").getClassLoader();
            System.out.println(classLoader); // String 类由启动类加载器加载，我们无法获取

            //2.Thread.currentThread().getContextClassLoader()
            ClassLoader classLoader1 = Thread.currentThread().getContextClassLoader();
            System.out.println(classLoader1); //sun.misc.Launcher$AppClassLoader@18b4aac2

            //3.ClassLoader.getSystemClassLoader().getParent()
            ClassLoader classLoader2 = ClassLoader.getSystemClassLoader().getParent();
            System.out.println(classLoader2); //sun.misc.Launcher$ExtClassLoader@61bbe9ba

        } catch (ClassNotFoundException e) {
            e.printStackTrace();
        }
    }
}

4.双亲委派机制(面试常问)

4.1 双亲委派机制原理

  • Java虚拟机对 class 文件采用的是按需加载的方式，也就是说当需要使用该类时才会将它的 class 文件加载到内存中生成 class 对象。而且加载某个类的class文件时，Java虚拟机采用的是双亲委派模式，即把请求交由父类处理，它是一种任务委派模式

  • 如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；

  • 如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；

  • 如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式。

  • 父类加载器一层一层往下分配任务，如果子类加载器能加载，则加载此类，如果将加载任务分配至系统类加载器也无法加载此类，则抛出异常
    image-20201120145657360

4.2 双亲委派机制代码示例

举例一：

我们自己定义一个java.lang包，在其下面定义一个String类，里面声明了静态代码块

image-20201120145147953

package java.lang;

/**
 * @author xiexu
 * @create 2020-11-20 2:47 下午
 */
public class String {

    static {
        System.out.println("我是自定义的String类的静态代码块");
    }

}

在一个测试类中加载String类，看看加载的String类是JDK自带的，还是我们自己编写的

/**
 * @author xiexu
 * @create 2020-11-20 2:44 下午
 */
public class StringTest {
    public static void main(String[] args) {
        String str = new java.lang.String();
        System.out.println("你好，世界");
    }
}

结果：程序并没有输出我们静态代码块中的内容，可见仍然加载的是 JDK 自带的 String 类

image-20201120145525294

举例二：

在我们自己定义的 String 类中整个 main( ) 方法

public class String {

    static {
        System.out.println("我是自定义的String类的静态代码块");
    }

    //错误: 在类 java.lang.String 中找不到 main 方法
    public static void main(String[] args) {
        System.out.println("hello,String");
    }

}

image-20201120151248533

原因：由于双亲委派机制，我们的String类是由引导类加载器加载的，而引导类加载器并没有main方法，所以会报错

举例三：

SPI接口是由引导类加载器加载的，接口具体的实现类是由线程上下文类加载器加载的，而线程上下文类加载器就是系统类加载器，所以我们在加载的时候，会先进行双亲委派，在引导类加载器加载SPI核心类，然后加载SPI接口，最后在反向委托，通过系统类加载器进行实现类 jdbc.jar 的加载

image-20200705105810107

举例四：

package java.lang; 
public class ShkStart { 
    public static void main(String[] args) {
        System.out.println("hello!"); 
    } 
}

image-20201120152729612

出于保护机制，java.lang 包下不允许我们自定义类, 有校验检查

4.3 双亲委派机制的优势

  • 避免类的重复加载

  • 保护程序安全，防止核心API被随意篡改

  • 自定义类：java.lang.String 没有main方法可以被调用

  • 自定义类：java.lang.ShkStart（报错：阻止创建 java.lang开头的类）

5.沙箱安全机制

  • 自定义String类时：在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java.lang.String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。
  • 这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

6.其他

如何判断两个class对象是否相同？

  • 在JVM中表示两个class对象是否为同一个类存在两个必要条件：

    • 类的完整类名必须一致，包括包名

    • 加载这个类的 ClassLoader（指ClassLoader实例对象）必须相同

  • 换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的 ClassLoader 实例对象不同，那么这两个类对象也是不相等的

    对类加载器的引用

  • JVM必须知道一个类型是由启动加载器加载的还是由用户类加载器加载的

  • 如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中

  • 当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的

    类的主动使用和被动使用

    Java程序对类的使用方式分为：主动使用和被动使用。

  • 主动使用又分为七种情况：
    • 创建类的实例
    • 访问某个类或接口的静态变量，或者对该静态变量赋值
    • 调用类的静态方法
    • 反射（ 比如：Class.forName(“cn.sxt.Test”) )
    • 初始化一个类的子类
    • Java虚拟机启动时被标明为启动类的类
    • JDK7开始提供的动态语言支持：java.lang.invoke.MethodHandle实例的解析结果REF_getStatic、REF putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化
  • 除了以上七种情况，其他使用Java类的方式都被看作是对类的被动使用：都不会导致类的初始化，即不会执行初始化阶段（不会调用 clinit( ) 方法和 init( ) 方法）

待解决问题：jvm指令需要学习？？？？？？？？？？？？？？？？？？？？？？？后面需要继续学习

————————————————
版权声明：本文为CSDN博主「JavaAlenboy」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/sj15814963053/article/details/109851454

关于jvm类加载子系统的博客：

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/tangliMeiMei/p/15168785.html