类加载子系统

在这里插入图片描述从上图我们可以发现类加载子系统分为三个阶段，分别是加载、链接和初始化

加载阶段即将字节码文件加载到我们的内存中，在这过程中使用到了几个加载器，比如：引导类加载器、扩展类加载器、应用类(系统类)加载器

链接阶段分为验证、准备和解析三个环节

类加载器子系统的作用

类加载器子系统负责从文件系统或者网络中加载Class文件，Class文件在文件开头有特定的文件标识。
ClassLoader只负责Class文件的加载，至于它是否可以运行，则由Execution Engine决定。
加载的类信息存放于一块称为方法区的内存空间，除了类的信息外，方法区中还会存放运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是Class文件中常量部分的内存映射）

类加载器ClassLoader的角色

在这里插入图片描述

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

类的加载过程

阶段一：Loading

在这里插入图片描述

加载（Loading）：

通过一个类的全限定名（全限定名 = 包名 + 类型）获取定义此类的二进制字节流
将这个字节流所代表的静态存储结构转化为方法区（1.7以上的是方法区也叫元空间，1.7以下的是永久代）的运行时数据结构
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口

补充：加载.class文件的方式

从本地系统中直接加载

通过网络获取，典型场景：Web Applet

从zip压缩包中读取，称为日后jar、war格式的基础

运行时计算生成，使用最多的是：动态代理技术

由其他文件生成，典型场景：JSP应用

阶段二：Linking

链接（Linking）阶段我们分为三个具体的子阶段，分别是：验证（Verify）、准备（Prepare）和解析（Resolve）

验证（Verify）

目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全
主要包括四种验证，文件格式验证，元数据验证，字节码验证，符号引用验证

比如文件格式验证前面我们说到Class文件开头都会有一个特定的文件标识，也叫class文件魔数CAFEBABE，如下图：

在这里插入图片描述

没有这个开头的CAFEBABE的Class文件就不是一个可以被JVM所识别的、合法的Class文件，关于CAFEBABE的由来可以看一下这篇文章 class文件魔数CAFEBABE的由来

准备（Prepare）

为类变量(静态变量)分配内存并且设置该类变量的默认初始值，即零值，如下代码：

/**
 * @author 小关同学
 * @create 2021/7/25
 */
public class StackStruTest {

    //这里我们给静态变量a赋值为1，
    //但在类加载子系统中的链接阶段的第二个子阶段的准备(prepare)中，a其实会被赋值为0
    //而在初始化(Initialization)阶段它才会被赋值为1
    private static int a = 1;

    //被final修饰的值它就不能算是变量了，它可以算是一个常量类型
    final private static int b = 1;

    public static void main(String[] args) {

        System.out.println("hello");

    }
}

这里不包含用final修饰的static，因为final在编译的时候就会分配了，准备阶段会显式初始化
这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中

解析（Resolve）

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

阶段三：Initialization

初始化阶段就是执行类构造器方法< clinit >()的过程，此方法不需要定义，是 javac 编译器自动收集类中的所有类变量(静态变量) 的赋值动作和静态代码块中的语句合并而来

例： Java编译器不会为所有的类都产生＜clinit＞初始化方法我们先看以下代码和他们反编译的结果的区别代码1：

public class StackStruTest {
    
    private static int a = 1;
    final private static int b = 1;

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

反编译结果：

在这里插入图片描述

代码2：

/**
 * @author 小关同学
 * @create 2021/7/25
 */
public class StackStruTest {

    private int a = 1;
    final private static int b = 1;
    
    public static void main(String[] args) {
        System.out.println("hello");
    }
}

反编译结果：

在这里插入图片描述

我们通过对比可以发现，代码2中并没有出现< clinit >方法，而代码1中则有< clinit >方法，他们之间的区别仅仅是代码1中的变量a是静态变量（下面由final修饰的默认是常量），代码2中的是普通变量，而< clinit >方法是类的初始化方法，是由Java编译器根据类静态成员的赋值语句以及static语句块共同产生的，在初始化(Initialization)阶段被调用

构造器方法中指令按语句在源文件中出现的顺序执行

我们来看一下下面这段代码

/**
 * @author 小关同学
 * @create 2021/7/28
 */
public class ClassInitTest {

    static {
        num = 10;
        //System.out.println(num);//报错，非法的前向引用
    }
    private static int num = 20; //linking-->prepare:num = 0 -->initialization: 10 --> 20
    public static void main(String[] args) {
        System.out.println(num);
    }
}

反编译结果：

在这里插入图片描述

我们可以看到，反编译的过程中num先被赋值为10，然后再被赋值为20，最后输出的结果也是20，印证了构造器方法中指令按语句在源文件中出现的顺序执行

< clinit >()不同于类的构造器。（关联：构造器是虚拟机视角下的< init >()，< init >()对应的是每个类都存在的默认构造器）

若该类具有父类，JVM会保证子类的< clinit >()执行前，父类的< clinit >()已经执行完毕（自上而下的执行流程）

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

类加载器的分类

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

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

我们看一下源码可以发现，扩展类加载器是继承于URLClassLoader的

在这里插入图片描述

而URLClassLoader更是间接继承ClassLoader的

在这里插入图片描述

而应用类加载器也是继承于URLClassLoader的

在这里插入图片描述

所以应用类加载器也是间接继承ClassLoader抽象类的

在这里插入图片描述

综上扩展类加载器（Extension Class Loader）和系统类/应用类加载器（System Class Loader）都间接继承了ClassLoader，所以他们也算在自定义类加载器里面。

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

引导类加载器（Bootstrap ClassLoader）

虚拟机自带的类加载器
这个类加载器使用C/C++语言实现的，嵌套在JVM内部
它用来加载Java的核心库（JAVA_HOME/jre/lib/rt.jar、resources.jar或sun.boot.class.path路径下的内容），用于提供JVM自身需要的类
并不继承自java.lang.ClassLoader，没有父加载器
加载扩展类和应用类加载器，并指定为他们的父类加载器
出于安全考虑，Bootstrap ClassLoader引导类加载器只加载包名为java、javax、sun等开头的类
出于安全考虑，核心类不允许用自定义加载器，因为自定义加载器是Java写的，可以通过手段监控加载过程，可能会被注入恶意代码

扩展类加载器（Extension ClassLoader）

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

系统类加载器/应用类加载器（AppClassLoader）

Java语言编写，由sun.misc.Launcher$AppClassLoader实现
派生于ClassLoader类
父类加载器为扩展类加载器
它负责加载环境变量classpath或系统属性java.class.path指定路径下的类库
该类加载是程序中默认的类加载器，一般来说，Java应用的类都是由它来完成加载
通过ClassLoader#getSystemClassLoader()方法可以获取到该类加载器

双亲委派机制

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

机制：

如果一个类加载器收到了类加载请求，它并不会自己先去加载，而是把这个请求委托给父类的加载器去执行；
如果父类加载器还存在其父类加载器，则进一步向上委托，依次递归，请求最终将到达顶层的启动类加载器；
如果父类加载器可以完成类加载任务，就成功返回，倘若父类加载器无法完成此加载任务，子加载器才会尝试自己去加载，这就是双亲委派模式；如下图：

在这里插入图片描述

例子：例一：我们自定义了一个java.lang包路径底下的String类，如下图：

在这里插入图片描述

然后我们进行测试：

/**
 * @author 小关同学
 * @create 2021/7/31
 */
public class StringClassTest {
    public static void main(String[] args) {

        java.lang.String str = new java.lang.String();
        System.out.println("hello!!!");

        StringClassTest stringClassTest = new StringClassTest();
        System.out.println(stringClassTest.getClass().getClassLoader());//sun.misc.Launcher$AppClassLoader@18b4aac2

    }
}

输出结果：

在这里插入图片描述

问题：

1.java.lang.String str = new java.lang.String();中使用的为什么不是执行我们自定义的String类呢？ 2.StringClassTest这个类的加载过程是怎么样的？

分析：

1.因为双亲委派机制，每个类的加载都是递归地交由父类加载器去加载，最终到Bootstrap ClassLoader(引导类加载器)。如果引导类加载器能加载，如在java.lang包底下的String类，则由引导类加载器直接加载Java类库里面的API；反之如果引导类加载器不能加载该类，则由子类加载器加载。所以这里加载的String还是Java类库底下的String，而不是我们自定义的String类。

2.StringClassTest是我们自定义的一个类，按照双亲委派机制，它一开始由系统类加载器逐步向上委托给父类加载器，直到委托给了引导类加载器，而引导类加载器只加载Java的核心类库，加载不了我们自定义的StringClassTest，所以又给委派给了扩展类加载器，扩展类加载器也加载不了，继续委派给系统类加载器。最后，由系统类加载器加载我们的StringClassTest类。

例二：我们在例一中的自定义String类里面写一个main方法并执行以下，如下：

/**
 * @author 小关同学
 * @create 2021/7/31
 */
public class String {
    static{
        System.out.println("这是自定义String类的静态代码块");
    }

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

输出结果：

在这里插入图片描述

问题：为什么加载不了这个自定义String类？

分析：我们自定义的String类的路径是java.lang.String，根据双亲委派机制，在该类委派到引导类加载器加载之后，引导类加载器会去Java类库底下的java.lang底下找String类加载，加载完之后发现JavaAPI的String类里面并没有main方法，所以报错：找不到main方法。

例三：加载第三方jar包底下的类

在这里插入图片描述

上图中SPI接口属于Java核心类库底下的API，所以根据双亲委派机制由引导类加载器加载SPI接口，而这过程中涉及到了一些第三方jar包的实现类，这些第三方jar包中的实现类不属于引导类加载器加载，所以就反向委派给了线程上下文类加载器（默认为系统类加载器）加载这些第三方jar包中的实现类。

双亲委派机制的优势：

避免类的重复加载
保护程序安全，防止核心API被随意篡改

沙箱安全机制

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

其他

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

类的完整类名必须一致，包括包名
加载这个类的ClassLoader（指ClassLoader实例对象）必须相同

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

对类加载器的引用

JVM必须知道一个类型是由引导类加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。

类的主动使用和被动使用

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

主动使用，又分为七种情况：

创建类的实例
访问某个类或接口的静态变量，或者对该静态变量赋值。而对于静态常量（static final）不会初始化此类。
调用类的静态方法
反射（如：Class.forName("com.Test")）
初始化一个类的子类
Java虚拟机启动时被标明为启动类的类（存在mian方法的类）
JDK7开始提供的动态语言支持： java.lang.invoke.MethodHandle实例的解析结果 REF_getStatic、REF_putStatic、REF_invokeStatic句柄对应的类没有初始化，则初始化

除了以上七种情况，其他使用Java类的方法都被看作是对类的被动使用，都不会导致类的初始化。如：引用类的静态常量不会导致类的初始化（类的被动使用）

JVM学习2：类加载子系统

类加载子系统

类加载器子系统的作用

类加载器ClassLoader的角色

类的加载过程

阶段一：Loading

阶段二：Linking

验证（Verify）

准备（Prepare）

解析（Resolve）

阶段三：Initialization

类加载器的分类

引导类加载器（Bootstrap ClassLoader）

扩展类加载器（Extension ClassLoader）

系统类加载器/应用类加载器（AppClassLoader）

双亲委派机制

双亲委派机制的优势：

沙箱安全机制

其他

对类加载器的引用

类的主动使用和被动使用

问题交流(QQ群)