JVM --- 类加载机制

原文链接：https://blog.csdn.net/m0_38075425/article/details/81627349

类的生命周期：
类被加载到 JVM 虚拟机内存开始，到卸载出内存为止。
他的生命周期可以分为：加载->校验->准备->解析->初始化->使用->卸载。

---

一、类加载过程

1.加载

加载过程主要完成三件事情：

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

Java虚拟机支持两种类加载器：

• 引导类加载器(Bootstrap ClassLoader)
• 用户自定义类加载器(User-Defined Class Loader)

通过使用不同的类加载器，可以从不同来源加载类的二进制数据，通常有如下几种来源。

• 从本地文件系统加载class文件，这是前面绝大部分示例程序的类加载方式。
• 从JAR包加载class文件，这种方式也是很常见的，JDBC编程时用到的数据库驱动类就放在JAR文件中，JVM可以从JAR文件中直接加载该class文件。
• 通过网络加载class文件。
• 把一个Java源文件动态编译，并执行加载。

---

当类被加载之后，系统为之生成一个对应的Class对象，接着将会进入连接阶段，连接阶段负责把类的二进制数据合并到JRE中。类连接又可分为如下3个阶段。

2.校验

验证作为链接的第一步，用于确保类或接口的二进制表示结构上是正确的，从而确保字节流包含的信息对虚拟机来说是安全的。

Java虚拟机规范中关于验证阶段的规则也是在不断增加的，但大体上会完成下面4个验证动作。

1.文件格式验证

主要验证字节流是否符合Class文件格式规范，并且能被当前版本的虚拟机处理。这阶段的验证是基于二进制字节流的，只有通过文件格式验证后，字节流才会进入内存的方法区中进行存储。

• 是否以魔数 0xCAFEBABE 开头（每一个.class文件都是以8个十六进制的 0×CAFEBABE开头）
• 主次版本号是否在当前虚拟机处理范围之内
• 常量池的常量是否有不被支持的类型 (检查常量tag标志)
• 指向常量的各种索引值中是否有指向不存在的常量或不符合类型的常量
• CONSTANT_Utf8_info型的常量中是否有不符合UTF8编码的数据
• Class文件中各个部分及文件本身是否有被删除的或者附加的其他信息
  ……

2.元数据验证

基于方法区的存储结构验证，主要对字节码描述的信息进行语义分析，以保证其提供的信息符合Java语言规范的要求。主要验证点：

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

3.字节码验证

主要是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后，字节码验证将对类的方法体进行校验分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的事件。

4.符号引用验证

最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段解析阶段发生。符号引用是对类自身以外（常量池中的各种符号引用）的信息进行匹配校验。主要验证点：

• 符号引用中通过字符串描述的全限定名是否找到对应的类
• 在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段
• 符号引用中的类、方法、字段的访问性（private,public,protected、default）是否可被当前类访问
• 符号引用验证的目的是确保解析动作能够正常执行，如果无法通过符号引用验证，那么将会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等

---

3.准备

准备阶段的任务是为类或者接口的静态字段分配空间，并且默认初始化这些字段。（此时为默认值，在初始化的时候才会给变量赋值）

如果字段属性表中包含 ConstantValue（常量）属性，那么准备阶段变量value就会被初始化为 ConstantValue 属性所指定的值，比如：

/此时就会为age变量分配内存空间并且为其赋值 0 这个初始值。

public class Student{
    private static int age = 18;
}

/age被final修饰，此时就会为age变量分配内存空间并且为其赋值为 18 。

public class Student{
    private static final int age = 18;
}

---

4.解析

解析阶段就是 JVM 将常量池的符号引用替换为直接引用。

1. 符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
2. 直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在。

主要有以下四种：

• 类或接口的解析
• 字段解析
• 类方法解析
• 接口方法解析

---

5.初始化

在准备阶段我们已经为加载到 JVM 的类分配了内存空间并且为类变量赋予了初始值。

而到了初始化阶段，才真正开始执行类中定义的 Java程序代码。主要有以下步骤：

1. 使用new关键字实例化对象、访问或者设置一个类的静态字段（被final修饰、编译器优化时已经放入常量池的例外）、调用类方法，都会初始化该静态字段或者静态方法所在的类。
2. 初始化类的时候，如果其父类没有被初始化过，则要先触发其父类初始化。
3. 使用 java.lang.reflect 包的方法进行反射调用的时候，如果类没有被初始化，则要先初始化。
4. 虚拟机启动时，用户会先初始化要执行的主类（含有main）
5. jdk1.7后，如果 java.lang.invoke.MethodHandle 的实例最后对应的解析结果是 REF_getStatic、REF_putStatic、REF_invokeStatic方法句柄，并且这个方法所在类没有初始化，则先初始化。

---

二、类加载时机

1. 创建类的实例，也就是new一个对象
2. 访问某个类或接口的静态变量，或者对该静态变量赋值
3. 调用类的静态方法
4. 反射（Class.forName(“com.lyj.load”)）
5. 初始化一个类的子类（会首先初始化子类的父类）
6. JVM启动时标明的启动类，即文件名和类名相同的那个类

注意：
对于一个final类型的静态变量，如果该变量的值在编译时就可以确定下来，那么这个变量相当于“宏变量”。Java编译器会在编译时直接把这个变量出现的地方替换成它的值，因此即使程序使用该静态变量，也不会导致该类的初始化。反之，如果final类型的静态Field的值不能在编译时确定下来，则必须等到运行时才可以确定该变量的值，如果通过该类来访问它的静态变量，则会导致该类被初始化。

---

三、类加载器

类加载器负责加载所有的类，所有被载入内存中的类生成一个java.lang.Class实例对象。一旦一个类被加载如JVM中，同一个类就不会被再次载入了。正如一个对象有一个唯一的标识一样，一个载入JVM的类也有一个唯一的标识。

在Java中，一个类用其全限定类名（包括包名和类名）作为标识。
但在JVM中，一个类用其全限定类名和其类加载器作为其唯一标识。

例如，如果在pg的包中有一个名为Person的类，被类加载器ClassLoader的实例kl负责加载，则该Person类对应的Class对象在JVM中表示为(Person.pg.kl)。这意味着两个类加载器加载的同名类：（Person.pg.kl）和（Person.pg.kl2）是不同的、它们所加载的类也是完全不同、互不兼容的。

JVM预定义有三种类加载器，当一个 JVM启动的时候，Java开始使用如下三种类加载器：

1. 根类加载器（bootstrap class loader）: 也叫启动类加载器。它用来加载 Java 的核心类，是用原生代码来实现的，并不继承自 java.lang.ClassLoader（负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，由C++实现，不是ClassLoader子类）。由于引导类加载器涉及到虚拟机本地实现细节，开发者无法直接获取到启动类加载器的引用，所以不允许直接通过引用进行操作。
2. 扩展类加载器（extensions class loader）：它负责加载JRE的扩展目录，lib/ext或者由java.ext.dirs系统属性指定的目录中的JAR包的类。由Java语言实现，父类加载器为null。
3. 系统类加载器（system class loader）：被称为系统（也称为应用）类加载器，它负责在JVM启动时加载来自Java命令的-classpath选项、java.class.path系统属性，或者 CLASSPATH 换将变量所指定的JAR包和类路径。程序可以通过ClassLoader 的静态方法 getSystemClassLoader() 来获取系统类加载器。如果没有特别指定，则用户自定义的类加载器都以此类加载器作为父加载器。由Java语言实现，父类加载器为ExtClassLoader。
   

类加载器加载Class大致要经过如下8个步骤：

1. 检测此Class是否载入过，即在缓冲区中是否有此Class，如果有直接进入第8步，否则进入第2步。
2. 如果没有父类加载器，则要么Parent是根类加载器，要么本身就是根类加载器，则跳到第4步，如果父类加载器存在，则进入第3步。
3. 请求使用父类加载器去载入目标类，如果载入成功则跳至第8步，否则接着执行第5步。
4. 请求使用根类加载器去载入目标类，如果载入成功则跳至第8步，否则跳至第7步。
5. 当前类加载器尝试寻找Class文件，如果找到则执行第6步，如果找不到则执行第7步。
6. 从文件中载入Class，成功后跳至第8步。
7. 抛出ClassNotFountException异常。
8. 返回对应的java.lang.Class对象。

---

四、类加载机制

1.JVM的类加载机制主要有如下3种。

1. 全盘负责：所谓全盘负责，就是当一个类加载器负责加载某个Class时，该Class所依赖和引用其他Class也将由该类加载器负责载入，除非显示使用另外一个类加载器来载入。
2. 双亲委派：所谓的双亲委派，则是先让父类加载器试图加载该Class，只有在父类加载器无法加载该类时才尝试从自己的类路径中加载该类。通俗的讲，就是某个特定的类加载器在接到加载类的请求时，首先将加载任务委托给父加载器，依次递归，如果父加载器可以完成类加载任务，就成功返回；只有父加载器无法完成此加载任务时，才自己去加载。
3. 缓存机制：缓存机制将会保证所有加载过的Class都会被缓存，当程序中需要使用某个Class时，类加载器先从缓存区中搜寻该Class，只有当缓存区中不存在该Class对象时，系统才会读取该类对应的二进制数据，并将其转换成Class对象，存入缓冲区中。这就是为很么修改了Class后，必须重新启动JVM，程序所做的修改才会生效的原因。

双亲委派：

1. 双亲委派机制，其工作原理的是，如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行，如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器，如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载。
2. 可理解位：每个儿子都很懒，每次有活就丢给父亲去干，直到父亲说这件事我也干不了时，儿子自己才想办法去完成。

双亲委派的优势：

1. 采用双亲委派模式的是好处是Java类随着它的类加载器一起具备了一种带有优先级的层次关系，通过这种层级关可以避免类的重复加载，当父亲已经加载了该类时，就没有必要子ClassLoader再加载一次。
2. 其次是考虑到安全因素，java核心api中定义类型不会被随意替换，假设通过网络传递一个名为java.lang.Integer的类，通过双亲委托模式传递到启动类加载器，而启动类加载器在核心Java API发现这个名字的类，发现该类已被加载，并不会重新加载网络传递的过来的java.lang.Integer，而直接返回已加载过的Integer.class，这样便可以防止核心API库被随意篡改。