《深入理解Java虚拟机》(三)类加载机制

1、什么是类的加载

Java虚拟机把描述类的二进制流冲.Class文件中读到内存中，并在这个过程对加载的数据进行校验、转换解析、初始化，最终形成可以被Java虚拟机直接使用的java类型，这个过程叫做虚拟机的类加载机制。类的加载会把类的数据结构信息存放于方法区，并在堆区创建一个java.lang.Class对象，用来封装该类在方法区的数据结构，该类对应的java.lang.Class对象就是类加载的最终产品；Java程序员可以通过该类对应的java.lang.Class对象的接口，访问该类在方法区内的数据结构。

类的加载并不需要在某个类第一次被使用时才被类加载器加载，当JVM预知到某个类将要被使用时就可以对它进行预加载，如果在加载类的过程中发生错误，或文件校验失败等问题，类加载器会在程序首次主动使用该类时报告异常(LinkageError)，换句话说，如果这个类在程序运行期间如果一直没有被调用，那么关于该.class文件错误/损坏的问题就不会被报告。

类加载的.class文件存在的形式：

从本地系统中直接加载
通过网络下载.class文件
从zip，jar等归档文件中加载.class文件
从专有数据库中提取.class文件
将Java源文件动态编译为.class文件

2、类加载的过程

一个类从.Class中开始被加载到内存中直到被卸载一共包括7个阶段：加载、验证、准备、解析、初始化、使用、卸载，其中验证、准备、解析被统称为连接。

graph LR A( 加载 ) ==> B( 验证 ) ==> C(准备) ==>D( 解析 )==>E( 初始化 ) A( 加载 ) -.->L(验证-准备-解析-- --&连接& ) -.->E( 初始化 )==>F( 使用 )==>G( 卸载 )

加载、验证、准备、初始化等阶段时按序开始的，而为了支持Java语言的动态绑定特性，解析可以在初始化前开始也可以在初始化之后开始；需要注意的是，这里提到的概念是按序开始，而非按序进行，这些环节的执行通常都是并发的关系，而非串行，也就是说只知道他们什么时候开始，而不能确定谁先完成，这些阶段会交叉进行，经常会在一个阶段执行的过程中去调用或激活另一个阶段。

加载

加载阶段需要做如下三件事：

通过一个类的全限定名来获取其定义的二进制字节流。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。
在Java堆中生成一个代表这个类的 java.lang.Class对象，作为对方法区中这些数据的访问入口。

当加载完成后，方法区会保存该类的数据结构，而堆区也会保存一个封装了方法区数据结构的java.lang.Class对象。
加载阶段是开发人员可控程度较高的阶段，它既可以由JVM默认的类加载器来完成，也可以由java开发人员自定义的类加载器来完成(从ZIP压缩吧、网络、数据库等等来源获取二进制流)。

连接

验证

验证是连接阶段的第一步，它是为了确保被加载的类的正确性

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

验证阶段大致会完成4个阶段的检验动作：

文件格式验证

验证字节流是否符合Class文件格式的规范；例如：

是否以 0xCAFEBABE开头
主次版本号是否在当前虚拟机的处理范围之内
常量池中的常量是否有不被支持的类型
CONSTANT_Utf8_info型的常量冲是否有不符合UTF-8编码的数据
Class文件中各个部分及文件本身是否有被删除的或附加的其他信息。

文件格式验证是基于二进制流的，文件格式验证之后的验证都是基于方法区存储的数据结构的，通过验证后的二进制流才被允许进入JVM方法区。

元数据验证

对字节码描述的信息进行语义分析例如，要求其必须满足JAVA语法规范；

是否有父类；
该类的父类是否继承了不允许被继承的类；
如果该类不是抽象类，那么它是否实现了其父类或接口中要求实现的方法.......等等。

字节码验证

上一环节的元数据验证是针对类层次的验证，而本环节的字节码验证则是基于类的方法体进行验证的。字节码验证是验证过程中复杂的阶段，它的工作是通过数据流分析和控制流分析，从而确定程序语义是否合法、是否符合逻辑。

保证任意是个操作数栈的数据类型和指令代码序列都能配合工作，不会出现操作数栈中压入了一个int，使用时却按long类型来加载入本地变量表中(非主观问题导致、被篡改)。
保证正任何跳转指令都不会跳转到方法体以外的字节码指令上。
保证方法体中类型转换总是有效的。

符号引用验证

符号引用确保解析动作能正确执行,它发生在虚拟机将符号引用转化为直接引用的时候；这个转化将在连接--解析解析阶段发生。类似之前的验证，符号引用验证可以看作是对类自身以外的各类信息进行匹配性校验，可理解成：检验该类是否缺少或者被禁止访问他所依赖的某些外部类、方法、字段等等资源。其中校验内容有:

符号引用中通过字符串描述的全限定名，是否能找对实际的与之对应的类；
在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
符号引用中的类、字段、方法的可访问性是否可以被当前类访问(private public protected、、、)

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用 -Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

为类的静态变量分配内存(static 定义的类变量，而不包括实例变量)，并将其初始化为默认值，

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，JDK8之前这些内存都将在方法区中分配，JDK8中他们会对着Class对象一起被存放于Java堆中。对于该阶段有以下几点需要注意：

这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。
```
  假设一个类变量的定义为： public static int value=3；
```

那么变量value在准备阶段过后的初始值为0，而不是3，因为这时候尚未开始执行任何Java方法，而把value赋值为3的 putstatic指令是在程序编译后，存放于类构造器（）方法之中的，所以把value赋值为3的动作将在初始化阶段才会执行。
这里还需要注意如下几点：

对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，否则编译时不通过；
而只被final修饰的常量则既可以在声明时显式地为其赋值，也可以在类初始化时显式地为其赋值;
对于引用数据类型reference来说，如数组引用、对象引用等，如果没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
如果在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。
如果类字段的字段属性表中存在 ConstantValue属性，即同时被final和static修饰，那么在准备阶段变量value就会被初始化为ConstValue属性所指定的值。

假设类变量value被定义为： public static final int value=3；

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据 ConstantValue的设置将value赋值为3。可以理解为static final常量在编译期就将其结果放入了调用它的类的常量池中

解析：

解析阶段把类中的符号引用转换为直接引用

它是虚拟机将常量池内的符号引用替换为直接引用的过程，解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行，他们对应常量池中的8种常量类型（ CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info、CONSTANT_Dynamic_info、CONSTANT_InvokeDynamic_info ）。

符号引用就是一组符号来描述目标，可以是任何字面量。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。

以下为前四种解析的过程

类或接口的解析

假设当前代码的类面是D，需要加载一个从未被解析过的，“符号引用N”描述的一个类或接口 C，需要如下步骤：

如果需要加载的C不是数组类型，那么JVM会把代表N的全限定名传给D的类加载器去加载类C。(在加载的过程中需要进行元数据验证、字节码验证，还可能触发其他的类加加载动作，例如加载该类的父类或实现的接口，一旦任何一环节失败即宣告加载失败)。
如果需要加载的C是数组类型,并且元素类型是对象(假设为Integer)，N的描述符号则类似 "[Ljava/lang/Integer"(以区分它和非数据类型)，那么将会按照上一点描述的规则去加载该数组的元素类型(Integer)，接着会由JVM生成一个代表该数组维度和元素的数组对象(例如：数组的length属性就是虚拟机自动生成的)。
如果上述环节都已成功完成，那么虚拟机中就已经存在一个实际的类/接口 C了，但是在解析完成前的最后一步还需要去验证D是否拥有C的访问权限，这才算解析完成。

类D是否拥有类C访问权限需要满足如下规则中任意一条：

被访问类C 是public的，并且与D同一个模块(模块化概念在JDK9引入)。
被访问类C 是public的，与D不在同一模块，但是C所在的模块允许类D所在的模块访问。
被访问类C 不是public的，但是类C 与类D 同包。(适用一般访问权限规则)。

字段解析

解析一个从未被解析过的字段符号引用，首先需要对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或接口的符号引用；解析成功后，我们把这个字段所属的类/接口用字母C 表示(例如要解析的字段是类C的域: X)，根据《JVM规范》，后续需要对C 进行如下操作：

如果类(接口) C 本身已经包含了，与简单名称和字段描述符都相匹配的字段，那么直接返回这个字段的直接引用，结束查找。
如第一步不成立，那么会在C实现的接口中，按照继承关系从下往上递归搜索各个接口和其父接口，如果某个接口中包含了，与简单名称和字段描述符都相匹配的字段，那么直接返回这个字段的直接引用，结束查找。
如果第二部依旧不成立，如果类C不是 java.lang.Object类，那么会按照继承关系从下往上递归搜索其父类；如果某个类中包含了，与简单名称和字段描述符都相匹配的字段，那么直接返回这个字段的直接引用，结束查找。
如果步骤三依旧无法查找到结果，那么即宣告查找失败，抛出：java.lang.NoSuchFieldError异常。

类方法解析

需要对方法表内class_index项中索引的方法所属的类或接口的符号引用进行解析；解析成功后，我们把这个方法所属的类/接口用字母C 表示(例如要解析的方法是类C的 X（）方法 )，根据《JVM规范》，后续需要对C 进行如下操作：

*** 为社么特别说是类方法解析呢，由于Class文件格式中，类的方法和接口的方法，符号引用的常量类型定义是分开的，如果在类的方法表中发现class_index中索引的C是个接口的话，那么肯定是错误的，类的方法表中class_index中索引的只能是类，不能是接口；将抛出异常：java.lang.IncompatibleClassChangeError。***
通过第一步后，如果类(接口) C 本身已经包含了，与简单名称和字段描述符都相匹配的方法，那么直接返回这个方法的直接引用，结束查找；否则进入下一步。
按照继承关系从下往上递归搜索其父类；如果某个类中包含了，与简单名称和字段描述符都相匹配的方法，那么直接返回这个方法的直接引用，结束查找；否则进入下一步。
按照继承关系从下往上递归搜索各个接口和其父接口，如果某个接口中包含了，与简单名称和字段描述符都相匹配的方法，那么说明类C是一个抽象类，结束查找，抛出异常：java.lang.AbstractMehtodError；否则执行步骤5。
宣告查找失败(前一环节是异常)。结束查找，抛出异常：java.lang.NoSuchMethodError。

如果在查找成功并返回后，对该方法进行访问权限验证时，如果发现对该方法不具备访问权限，那么将会抛出异常：java.lang.IllegalAccessError.

接口方法解析

接口方法解析与类方法解析异同如下：

接口方法表和类方法表实现不同，参照类接口解析的第一步，如果接口方法表中发现class_index索引的C是类而不是接口是抛出异常：java.lang.IncompatibleClassChangeError。
查找C接口自身，概念同类方法解析。
查找接口C的父接口，概念类似类方法解析。
针对上一步，由于接口允许多继承，如果C的多个父接口中存在多个符合条件的方法定义，那么将会从这些方法中返回任意一个。否则，进入步骤5。
宣告查找失败，抛出异常：java.lang.NoSuchMethodError。

初始化

初始化阶段之前的所有类加载动作，除了用户可以自定义类加载器外，其余的动作都由JAVA虚拟机进行主导，而到了初始化阶段Java虚拟机将真正开始执行类中编写的Java程序代码，将主导权移交应用程序。

初始化为类的静态变量赋予正确的初始值，JVM负责对类进行初始化，主要对类变量进行初始化。

在Java中对类变量进行初始值设定有两种方式：

声明类变量是指定初始值
使用静态代码块为类变量指定初始值

由于在准备阶段，类变量已经分配内存，并赋值为默认值(0,NULL、、、)；而在初始化阶段则会根据程序开发人员制定的主观计划去初始化类变量和其它资源。

可以理解为：初始化阶段就是执行类构造器< client >()方法的过程。

关于< client >()方法

< client >()方法并非开发人员直接编写，它是java文件编译期间由javac编译器自动生成的，< client >()方法是由编译器自动收集类中的所有类变量的赋值动作(准备阶段有提及)，以及静态语句块(static{}块)中的语句合并产生的；编译器收集顺序与源文件中定义顺序相同，静态语句块可以对静态语句块之后定义的静态变量复制，但是它只能访问定义在它之前的静态变量。如下：

public Class Test{
	private static int a = 1;
	private static int c;
	static{
		a = 3;//可以执行
		b = a + 1;//可以执行
		c = a + 2;//可以执行
		c = b + 1;//错误，b定义于static之后，只能对它赋值，不能访问
	}
	private static int b;
}

< client >()方法与类的构造函数不同，它不需要显示的调用父类的< client >()方法，JVM会保证子类的< client >()方法执行前父类的< client >()方法已经执行完。（所以JVM中java.lang.Object的< client >()方法最先被执行）；因此它意味着，父类中定义的静态语句块要优先于子类变量的赋值操作。如下：

public Class Test{
	public static void main(String[] args){
		System.out.println(Son.B); 
		//输出值： 2  而非  1 ， 因为Parent的 < client > () 方法  要比
		// Son 的 < client > () 方法 先执行，那么已知 < client > () 方法 包括静态语句块
		//所以Parent 的 static {} 块 执行完之后 ，才会 到子类中进行赋值： B = A   (A : 2)
	}
}
Class Son extend Parent{
	public static int B = A;
}
Class Parent{
	public static int A = 1;
	static {
		A = 2;
	}
}

虽然接口中不能使用static {} 块，但是接口中也可以定义static 静态变量，所以接口也会生成对应的< client > () 方法(同理，如果方法或者接口中不存在赋值操作，那么就可以不生成对应的 < client > () 方法)。与类不同的是，接口的< client > () 方法不需要先执行父接口的< client > () 方法，因为接口中定义的变量只有被时使用才会被初始化(执行 < client > () 方法)，那么只有通过子接口使用父接口定义的静态变量时才会触发父类的< client > () 方法执行。如下：

public Class Test{
	public static void main(String[] args){
		System.out.println(Son.C); //执行 Son的 < client > () 方法 
		System.out.println(Son.B); // B = A + 998，此时先执行Parent 的 < client > () 方法，
		// 然后执行 Son 的 < client > () 方法
		System.out.println(Son.A); // 执行 Parent的 < client > () 方法
	}
}
interface Son extends Parent{
	public static int B = A + 998;
	public static int C = 100;
	public void sonDoAnyThding();
}
interface Parent{
	public static int A = 2;
	public void parentDoAnyThing();
}

当通过多线程去初始化类时，那么只会有一个线程去执行该类的< client > () 方法，其他的线程将被阻塞，直至当前线程执行 < client > () 方法完毕。

JVM初始化步骤

假如这个类还没有被加载和连接，则程序先加载并连接该类
假如该类的直接父类还没有被初始化，则先初始化其直接父类
假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机：只有当对类的主动使用的时候才会导致类的初始化，类的主动使用包括以下六种：

创建类的实例，也就是new的方式
访问某个类或接口的静态变量，或者对该静态变量赋值
调用类的静态方法
反射（如 Class.forName(“com.shengsiyuan.Test”)）
初始化某个类的子类，则其父类也会被初始化
Java虚拟机启动时被标明为启动类的类（ JavaTest），直接使用 java.exe命令来运行某个主类

结束生命周期

在如下几种情况下，Java虚拟机将结束生命周期
执行了 System.exit()方法
程序正常执行结束
程序在执行过程中遇到了异常或错误而异常终止
由于操作系统出现错误而导致Java虚拟机进程终止

3、类加载器

类与类的加载器

类加载器只用于实现： “通过类的全限定名来获取描述该类的二进制流” 的操作，但是他在java程序中起到的作用却远超类加载阶段。对于任意一个类，都必须由加载它的类加载器和这个类一起共同确立一个唯一性的组合，每一个类加载器都有一个独立的类名称空间用来记录它加载的类。这个组合的约束体现在如下例子中，例如要比较两个类是否相等，那么他们必须由同一个加载器加载，即便这两个类加载的二进制流来源相同，如果他们使用了不同的类加载器，那么即认为他们不是相同的两个类。

JVM双亲委派模型中存在如下的各类加载器：

启动类加载器(BootStrap Class Loader)、拓展类加载器(Extension Class Loader)、应用程序类加载器(Application Class Loader)、自定义类加载器(User Class Loader)

假如应用程序中有一个类 com.jvm.loadear.TestLoad，那么默认他是被应用程序类加载器加载的，加载的结果是com.jvm.loadear.TestLoad.Class_app（_app为自定义标识，与实际无关），与此同时用户自定义了一个类加载器--Self Class Loader，使用该加载器加载类com.jvm.loadear.TestLoad的结果是com.jvm.loadear.TestLoad.Class_self，虽然加载的类来自同一个全限定命名空间下相同的二进制流，那么他们就不是同一个类，那么对于他们的实例对象：testLoad_app 和 testLoad_self，存在如下结果：

testLoad_self instanceof com.jvm.loadear.TestLoad_app  =  false;
testLoad_app instanceof com.jvm.loadear.TestLoad_self = false;

类加载器双亲委派模型

从JVM的视角看，类加载器分为两种：

启动类加载器，使用C++实现，是JVM的一部分；
其他所有类加载器，使用Java语言实现，独立于JVM之外，并且全部抽象继承自抽象类java.lang.ClassLoader;

从开发人员的视角看，Java一直保持着三层类加载器、双亲委派的类加载架构。

如下为类加载器双亲委派模型，虽然上层加载器称为下层加载器的父加载器；需要注意的是下图是他们的协同工作的流程图，而不代表他们是父-子类的关系，他们是通过组合来实现对父加载器代码的复用。

graph BT A( 启动类加载器 BootStrap Class Loader ) B( 拓展类加载器 Extension Class Loader ) C( 应用程序类加载器 Application Class Loader ) D( 自定义类加载器 User Class Loader ) E( 自定义类加载器 User Class Loader ) D==>C E==>C C==>B B==>A

启动类加载器： BootstrapClassLoader，负责加载存放在 JDK\jre\lib(JDK代表JDK的安装目录，下同)下，或被 -Xbootclasspath参数指定的路径中的，并且能被虚拟机识别的类库（如rt.jar，所有的java.开头的类均被 BootstrapClassLoader加载）。启动类加载器是无法被Java程序直接引用的。
扩展类加载器： ExtensionClassLoader，该加载器由 sun.misc.Launcher$ExtClassLoader实现，它负责加载 JDK\jre\lib\ext目录中，或者由 java.ext.dirs系统变量指定的路径中的所有类库（如javax.开头的类），开发者可以直接使用扩展类加载器。
应用程序类加载器： ApplicationClassLoader，该类加载器由 sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者可以直接使用该类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

应用程序都是由这三种类加载器互相配合进行加载的，如果有必要，我们还可以加入自定义的类加载器。因为JVM自带的ClassLoader只是懂得从本地文件系统加载标准的java class文件，因此如果编写了自己的ClassLoader，便可以做到如下几点：

在执行非置信代码之前，自动验证数字签名。
动态地创建符合用户特定需要的定制化构建类。
从特定的场所取得java class，例如数据库中和网络中。

双亲委派模型的工作流程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把请求委托给父加载器去完成，依次向上，因此，所有的类加载请求最终都应该被传递到顶层的启动类加载器中，只有当父加载器在它的搜索范围中没有找到所需的类时，即无法完成该加载，子加载器才会尝试自己去加载该类。

双亲委派机制

1、当应用程序类加载器 Application Class Loader加载一个class时，它首先不会自己去尝试加载这个类，而是把类加载请求委派给父类加载器:拓展类加载器 Extension Class Loader去完成。

2、当拓展类加载器 Extension Class Loader加载一个class时，它首先也不会自己去尝试加载这个类，而是把类加载请求委派给启动类加载器 Bootstrap Class Loader去完成。

3、如果启动类加载器 Bootstrap Class Loader加载失败（例如在 $JAVA_HOME/jre/lib里未查找到该class），则会向下使用：拓展类加载器 Extension Class Loader来尝试加载；

4、若拓展类加载器 Extension Class Loader也加载失败，则会使用应用程序类加载器 Application Class Loader来加载，如果应用程序类加载器 Application Class Loader也加载失败，则会报出异常ClassNotFoundException。

可以理解成，一个类加载器收到类加载器的请求时，首先会将该请求传递给自己的父加载器，直至顶层的启动类加载器：Bootstrap Class Loader。如果顶层的，启动类加载器无法加载类，则重新将该请求退回给它的子加载器，以此类推，如果最底层的应用程序类加载器也无法加载类时抛出异常: ClassNotFoundException。

结合类与加载器形成唯一确定组合的关系，那么使用双亲委派模型显而易见的好处是：

Java中的类随着它的类加载器一起具备了一种带有优先级的层级关系。例如：rt.jar包内的类java.util.HashMap类，最终会委派给启动类加载器加载，因此HashMap类在程序的各种类加载器环境中都能保证是同一个类。
基于上述理论，双亲委派模型可以保证Java程序的稳定运行。

JVM类加载机制

当一个类加载器负责加载某个Class时，该Class所依赖的和引用的其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
父类委托，先让父类加载器试图加载该类，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。
缓存机制，缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区寻找该Class，只有缓存区不存在，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓存区。这就是为什么修改了Class后，必须重启JVM，程序的修改才会生效。

4、类的加载

类加载有三种方式：

命令行启动应用时候由JVM初始化加载
通过Class.forName()方法动态加载
通过ClassLoader.loadClass()方法动态加载

区别与联系：

Class.forName()：将类的.class文件加载到jvm中之外，还会对类进行解释，执行类中的static块；
ClassLoader.loadClass()：只干一件事情，就是将.class文件加载到jvm中，不会执行static中的内容,只有在newInstance才会去执行static块。

Class.forName(name,initialize,loader) 带参函数也可控制是否加载static块。

 Class.forName("Test2", false, loader);// 不加载static块
 // 此时，只有创建类的对象，才会去加载static块 。

5、自定义类加载器

通常情况下，我们都是直接使用系统类加载器。但是，有的时候，我们也需要自定义类加载器。比如应用是通过网络来传输 Java类的字节码，为保证安全性，这些字节码经过了加密处理，这时系统类加载器就无法对其进行加载，这样则需要自定义类加载器来实现。

自定义类加载器一般都是继承自 ClassLoader类，从上面对 loadClass方法来分析来看，我们只需要重写 findClass 方法即可。

自定义类加载器的核心在于对字节码文件的获取，如果是加密的字节码则需要在该类中对文件进行解密。

传递的文件名需要是类的全限定性名称，即 com.paddx.test.classloading.Test格式的，因为 defineClass 方法是按这种格式进行处理的。
不要重写loadClass方法，因为这样容易破坏双亲委托模式。
这类Test 类本身可以被 AppClassLoader类加载，因此我们不能把 com/paddx/test/classloading/Test.class放在类路径下。否则，由于双亲委托机制的存在，会直接导致该类由 Application Class Loader加载，而不会通过我们自定义类加载器来加载。

本文主要参考《深入理解Java虚拟机一书》
在其基础上我进行了修改，修改了一些内容，也加上了一些我自己的理解。
如有谬误，请务必指正。

posted @ 2021-06-19 15:15 bokerr 阅读(59) 评论(0) 编辑收藏举报

刷新页面返回顶部

bokerr