深入理解Java虚拟机：类加载器子系统与类的生命周期-CSDN博客

本文链接：https://blog.csdn.net/rrq_0324/article/details/107549582

本文详细介绍了Java虚拟机（JVM）的类加载器子系统，包括加载过程的加载、链接（验证、准备、解析）和初始化阶段。类加载器分为引导类加载器、扩展类加载器、系统类加载器和用户自定义类加载器，它们遵循双亲委派机制。此外，文章还探讨了类的使用、类的卸载以及方法区的垃圾回收，阐述了类的生命周期和如何判断一个类可以被卸载。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

1. 内存结构概述

JVM架构（中）

图2-1 JVM架构（中）

JVM架构（英）

图2-2 JVM架构（英）

如果自己想手写一个Java虚拟机的话，主要考虑哪些结构呢？
- 类加载器
- 执行引擎

2. 类加载器与类的加载过程

2.1 类加载器子系统的作用

在 Java 中数据类型分为基本数据类型和引用数据类型。基本数据类型由虚拟机预先定义，引用数据类型则需要进行类的加载。
类加载器的作用：将字节码文件加载到内存中并生成一个Class类型的对象。
类加载器子系统负责从文件系统或者网络中加载class文件，class文件在文件开头有特定的文件标识（CA FE BA BE）。
ClassLoader只负责class文件的加载，至于它是否可以运行，则由执行引擎Execution Engine决定。
加载的类信息存放在一块称为方法区的内存空间。除了类的信息外，方法区中还会存放静态域信息和运行时常量池信息，可能还包括字符串字面量和数字常量（这部分常量信息是class文件中常量池部分的内存映射）。
类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括7个阶段：加载、验证、准备、解析、初始化、使用、卸载。

2.2 类加载器ClassLoader的角色

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

图2-3 类加载器的角色

2.3 类的加载过程

public class HelloLoader {
    public static void main(String[] args) {
        System.out.println("我已经被加载啦！");
    }
}

类的加载过程

图2-4 HelloLoader类的加载过程

2.3.1 加载

所谓加载，简而言之就是将 Java 类的字节码文件加载到机器内存中，并在内存中构建出 Java 类的原型——类模板对象。
在加载类时，Java 虚拟机必须完成以下 3 件事情：
- 通过一个类的全限定名获取定义此类的二进制字节流。
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构（Java类模板）。
- 在堆内存中生成一个代表这个类的java.lang.Class对象，作为方法区中这个类的各种数据的访问入口。该Class 对象是在加载类的过程中创建的，每个类都对应有一个 Class 类型的对象。
外部可以通过访问代表 Order 类的 Class 对象来获取 Order 的类数据结构。
Class 类的构造方法是私有的，只有 JVM 能够创建。java.lang.Class 实例是访问类型元数据的接口，也是实现反射的关键数据、入口。通过 Class 类提供的接口，可以获得目标类所关联的.class 文件中具体的数据结构：方法、字段等信息。
加载 Class 文件的方式：
- 从本地文件系统中直接加载 class 后缀的文件；
- 通过网络获取；
- 从zip压缩包中读取，成为日后jar、war格式的基础；
- 运行时计算生成，使用最多的是：动态代理技术；
- 由其他文件生成，典型场景：JSP应用；
- 从专有数据库中提取.class文件，比较少见；
- 从加密文件中获取，典型的防Class文件被反编译的保护措施。
数组类的加载：数组类本身并不是由类加载器负责创建，而是由 JVM 在运行时根据需要而直接创建的，但数组的元素类型仍然需要依靠类加载器去创建。创建数组类（下述简称 A）的过程：
- 如果数组的元素类型是引用类型，那么就遵循定义的加载过程递归加载和创建数组A的元素类型；
- JVM使用指定的元素类型和数组维度来创建新的数组类。
- 如果数组的元素类型是引用类型，数组类的可访问性就由元素类型的可访问性决定。否则数组类的可访问性将被缺省定义为 public。

2.3.2 链接

1. 验证

目的在于确保Class文件的字节流中包含信息符合当前虚拟机要求，保证被加载类的正确性，不会危害虚拟机自身安全。如果出现不合法的字节码文件，那么将会验证不通过。
主要包括四种验证：文件格式验证，元数据验证，字节码验证，符号引用验证。
- 文件格式校验：基于二进制字节流，验证是否以魔数 OxCAFEBABE 开头，主版本和副版本号是否在当前 Java 虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。只有通过这个阶段的验证后，字节流才会进入内存的方法区进行存储，所以后面的3个阶段全部是基于方法区的存储结构进行的，不会再直接操作字节流。格式验证会和加载阶段一起执行，格式验证之外的验证操作将会在方法区中进行。
- 元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合 Java 语言规范的要求。目的是保证不存在不符合 Java 语言规范的元数据信息。比如：是否所有的类都有父类的存在（在Java里，除了Object外，其他类都应该有父类）；是否一些被定义为final的方法或者类被重写或继承了；非抽象类是否实现了所有抽象方法或者接口方法；是否存在不兼容的方法（比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；abstract情况下的方法，就不能是final的了）。
- 字节码验证：该阶段主要工作是进行数据流和控制流分析，保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。比如：在字节码的执行过程中，是否会跳转到一条不存在的指令；函数的调用是否传递了正确类型的参数；变量的赋值是不是给了正确的数据类型。该过程只是尽可能地检査出可以预知的明显的问题，如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。
- 符号引用验证：最后一个阶段的校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在链接的第三个阶段——解析阶段中发生。符号引用验证的目的是确保解析动作能正常执行。Class 文件在其常量池会通过字符串记录自己将要使用的其他类或者方法，因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用的类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。
可以通过安装IDEA的jclasslib Bytecode viewer插件，来查看我们的.class文件。安装完成后，我们编译生成一个.class文件后，点击IDEA上方的View即可显示我们安装的插件来查看字节码了。也可以使用Binary Viewer工具查看.class字节码文件。

2. 准备

当一个类验证通过时，虚拟机就会进入准备阶段。在这个阶段，虚拟机会为类变量（静态变量）分配内存并且设置该类变量的默认初始值，即零值。
这里不包含基本数据类型的字段用 static final 修饰的情况，因为 final 在编译的时候就会分配了，准备阶段会显式赋值；这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到 Java 堆中。在这个阶段并不会像初始化阶段中那样会有初始化块或者代码被执行。

public class HelloApp {
    private static int a = 1;  // 准备阶段：a = 0; 初始化阶段：a = 1;
    public static void main(String[] args) {
        System.out.println(a);
    }
}

3. 解析

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

2.3.3 初始化

成员变量的赋值顺序：

① 默认初始化
② 显式初始化 / 代码块初始化
③ 构造器初始化
④ 对象.属性 = xxx

非静态代码块：随着对象的创建而执行，每创建一次对象就执行一次非静态代码块
静态代码块：随着类的加载而执行，且只执行一次
静态方法/类方法：随着类的加载而加载
静态属性/类属性：随着类的加载而加载

类的初始化是类装载的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行 Java 字节码。（即：到了初始化阶段，才真正开始执行类中定义的 Java 程序代码，比如：静态代码块随着类的加载而执行）
初始化阶段就是执行类构造器方法＜clinit＞()的过程。此方法无需定义，是javac编译器自动收集类中的所有类变量的赋值动作和静态代码块中的语句合并而来。Java 编译器并不会为所有的类都产生＜clinit＞() 初始化方法，哪些类在编译为字节码后，字节码文件中将不会包含＜clinit＞() 方法呢？
- 一个类中并没有声明任何的类变量，也没有静态代码块时；
- 一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作时；
- 一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式。
类构造器方法＜clinit＞() 中指令按语句在源文件中出现的顺序执行。
＜clinit＞()不同于类的构造器。关联：类的构造器是虚拟机视角下的＜init＞()。
任何一个类在声明后，内部至少存在一个类的构造器，默认是空参构造器。

package com.atguigu.java;
/*
JVM的架构模型：
	基于栈的指令集架构
重新编译：
    Build -> Recompile 'StackTest.java'
字节码反编译过程：
	D:\workspace_idea\jvm\out\production\chapter01\com\atguigu\java>javap -verbose -p StackTest.class > test.txt
 */
public class StackTest {
    private static int num = 1;

    static {
        num = 2;
        number = 20;
        System.out.println(num);
//        System.out.println(number); //报错：非法的前向引用 ---> Illegal forward reference
    }

    /*
    链接阶段之准备阶段：number = 0;
    初始化阶段：number = 20; ---> number = 10; //类构造器方法＜clinit＞()中指令按语句在源文件中出现的顺序执行。
     */
    private static int number = 10;

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

在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的＜clinit＞() 总是在子类＜clinit＞() 之前被调用。也就是说，父类的 static 块优先级高于子类。口诀：由父及子，静态先行。

package com.atguigu.java;

public class ClinitTest {
    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) {
        //若该类具有父类，JVM会保证子类的＜clinit＞()执行前，父类的＜clinit＞()已经执行完毕。
        //先加载Father类，再加载Son类
        System.out.println(Son.b); //2
    }
}

对于＜clinit＞() 方法的调用，也就是类的初始化，虚拟机会在内部确保其多线程环境中的安全性。
虚拟机会保证一个类的＜clinit＞() 方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的＜clinit＞() 方法，其他线程都需要阻塞等待，直到活动线程执行＜clinit＞() 方法完毕。
正是因为方法＜clinit＞() 带锁线程安全的，因此，如果在一个类的＜clinit＞() 方法中有耗时很长的操作，就可能造成多个线程阻塞，引发死锁。并且这种死锁是很难发现的，因为看起来它们并没有可用的锁信息。
如果之前的线程成功加载了类，则等在队列中的线程就没有机会再执行＜clinit＞() 方法了。那么，当需要使用这个类时，虚拟机会直接返回给它已经准备好的信息。

package com.atguigu.java;

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

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

        t1.start();
        t2.start();
        /*
        输出结果：
        	线程2开始
        	线程1开始
        	线程2初始化当前类
        结果分析：DeadThread类只能够执行一次初始化，这也就是同步加锁的过程。
        */
    }
}

class DeadThread {
    static {
        if (true) {
            System.out.println(Thread.currentThread().getName() + "初始化当前类");
            while (true) {

            }
        }
    }
}

static 与 final 的搭配问题：普通基本数据类型和引用类型（即使是常量）的静态变量，是需要额外调用 putstatic 等 JVM 指令的，这些是在显式初始化阶段执行，而不是准备阶段调用；被 static final 修饰的基本数据类型的字段和被 static final 修饰的并通过字面量的方式赋值的 String 类型的字段，显式赋值通常是在链接阶段的准备环节进行的。

public class InitializationTest {
    public static int a = 1; //在准备阶段赋默认值，在初始化阶段<clinit>()中显式赋值
    public static final int INT_CONSTANT = 10; //在链接阶段的准备环节显式赋值

    public static final Integer INTEGER_CONSTANT_1 = Integer.valueOf(100); //在初始化阶段<clinit>()中显式赋值
    public static Integer INTEGER_CONSTANT_2 = Integer.valueOf(1000); //在初始化阶段<clinit>()中显式赋值

    public static final String s0 = "HelloJava"; //在链接阶段的准备环节显式赋值
    public static final String s1 = new String("HelloWorld"); //在初始化阶段<clinit>()中显式赋值
}

 0 iconst_1
 1 putstatic #2 <com/atguigu/java/InitializationTest.a>
 4 bipush 100
 6 invokestatic #3 <java/lang/Integer.valueOf>
 9 putstatic #4 <com/atguigu/java/InitializationTest.INTEGER_CONSTANT_1>
12 sipush 1000
15 invokestatic #3 <java/lang/Integer.valueOf>
18 putstatic #5 <com/atguigu/java/InitializationTest.INTEGER_CONSTANT_2>
21 new #6 <java/lang/String>
24 dup
25 ldc #7 <HelloWorld>
27 invokespecial #8 <java/lang/String.<init>>
30 putstatic #9 <com/atguigu/java/InitializationTest.s1>
33 return

3. 类加载器的分类

JVM支持两种类型的类加载器，分别为引导类加载器（Bootstrap ClassLoader）和自定义类加载器（User Defined ClassLoader）。其中：扩展类加载器（Extension ClassLoader）和系统类加载器/应用程序类加载器（System ClassLoader / App ClassLoader）间接的继承于ClassLoader类，因此这两个类加载器也属于自定义类加载器。
从概念上来讲，自定义类加载器一般指的是程序中由开发人员自定义的一类类加载器，但是Java虚拟机规范却没有这么定义，而是将所有派生于抽象类ClassLoader的类加载器都划分为自定义类加载器。
如下图所示，这里的四者之间的关系是包含关系，不是上层下层，也不是子父类的继承关系。

图2-5 类加载器的分类

package com.atguigu.java;

public class ClassLoaderTest {
    public static void main(String[] args) {
        //获取系统类加载器
        ClassLoader systemClassLoader = ClassLoader.getSystemClassLoader();
        System.out.println(systemClassLoader); //sun.misc.Launcher$AppClassLoader@18b4aac2

        //获取扩展类加载器
        ClassLoader extensionClassLoader = systemClassLoader.getParent();
        System.out.println(extensionClassLoader); //sun.misc.Launcher$ExtClassLoader@1b6d3586

        //试图->获取引导类加载器
        ClassLoader bootstrapClassLoader = extensionClassLoader.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
    }
}

引导类加载器、扩展类加载器、系统类加载器是Java虚拟机自带的加载器。

3.1 引导类加载器（Bootstrap ClassLoader）

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

3.2 扩展类加载器（Extension ClassLoader）

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

3.3 系统类加载器（System ClassLoader）

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

package com.atguigu.java;

import sun.security.ec.CurveDB;
import java.net.URL;
import java.security.Provider;

public class ClassLoaderExer {
    public static void main(String[] args) {
        System.out.println("************启动类加载器************");
        //获取BootstrapClassLoader能够加载的API的路径
        URL[] urls = sun.misc.Launcher.getBootstrapClassPath().getURLs();
        for (URL url : urls) {
            System.out.println(url.toExternalForm());
        }
        /*
        输出结果为：
        ************启动类加载器************
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/resources.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/rt.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/sunrsasign.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/jsse.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/jce.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/charsets.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/lib/jfr.jar
        file:/D:/Java_development_tools/JDK_8u241/jre/classes
         */

        //从上面路径中，随意选择一个类，来看看他的类加载器是什么：得到的是null，说明是引导类加载器
        //例如：找到jsse.jar将其解压，再解压后的文件夹里找到Provider.class
        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);
        }
        /*
        输出结果为：
        ************扩展类加载器************
        D:\Java_development_tools\JDK_8u241\jre\lib\ext
        C:\Windows\Sun\Java\lib\ext
         */

        //从上面路径中，随意选择一个类，来看看他的类加载器是什么：得到的是扩展类加载器
        //例如：找到sunec.jar将其解压，再解压后的文件夹里找到CurveDB.class
        ClassLoader classLoader1 = CurveDB.class.getClassLoader();
        System.out.println(classLoader1); //sun.misc.Launcher$ExtClassLoader@1b6d3586
    }
}

3.4 用户自定义类加载器

在Java的日常应用程序开发中，类的加载几乎是由上述3种类加载器相互配合执行的，在必要时，我们还可以自定义类加载器，来定制类的加载方式。
为什么要自定义类加载器？
- 隔离加载类；
- 修改类加载的方式；
- 扩展加载源；
- 防止源码泄漏。
用户自定义类加载器实现步骤：
- 开发人员可以通过继承抽象类java.lang.ClassLoader类的方式，实现自己的类加载器，以满足一些特殊的需求。
- 在JDK1.2之前，在自定义类加载器时，总会去继承ClassLoader类并重写loadClass()方法，从而实现自定义的类加载器，但是在JDK1.2之后已不再建议用户去覆盖loadClass()方法，而是建议把自定义的类加载逻辑写在findClass()方法中。
- 在编写自定义类加载器时，如果没有太过于复杂的需求，可以直接继承URLClassLoader类，这样就可以避免自己去编写findClass()方法及其获取字节码流的方式，使自定义类加载器编写更加简洁。

4. ClassLoader的使用说明

ClassLoader类，它是一个抽象类，其后所有的类加载器都继承自ClassLoader（不包括引导类加载器 / 启动类加载器，这个类加载器使用C/C++语言实现）。
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 off, int len) 方法：把字节数组b中的内容转换为一个Java类，返回结果为java.lang.Class类的实例。
resolveClass(Class<?> c) 方法：连接指定的一个Java类。

图2-6 自定义类加载器的继承关系

sun.misc.Launcher 是一个java虚拟机的入口应用，其中ExtClassLoader类和AppClassLoader类都是sun.misc.Launcher类的内部类。
获取ClassLoader的途径：
- 获取当前ClassLoader：clazz.getClassLoader()
- 获取当前线程上下文的ClassLoader：Thread.currentThread().getContextClassLoader()
- 获取系统的ClassLoader：ClassLoader.getSystemClassLoader()
- 获取调用者的ClassLoader：DriverManager.getCallerClassLoader()

5. 双亲委派机制

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

5.1 工作原理

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

图2-7 双亲委派机制的工作原理

5.2 应用举例

双亲委派机制的应用举例1

package java.lang;

/**
 * @author rrqstart
 * @Description 自定义一个java.lang包并在其下自定义一个String类
 */
public class String {
	
    static {
        System.out.println("Hello String!");
    }

    public static void main(String[] args) {
        System.out.println("我是自定义java.lang.String类的main()方法。");
		//错误：在java.lang.String中找不到main()方法。
		/*
		原因分析：
		若想执行自定义java.lang.String类的main()方法，则必须加载其class文件，由于双亲委派机制的存在，
		导致在加载其class文件时，在向上委托到引导类加载器时，引导类加载器便将Java API中的String类加载成功了，
		最终导致自定义的String类一直未被加载，因此其内部的main()方法不会被执行。
		又因为Java API中的String类中并没有定义main()方法，所以报错：在java.lang.String中找不到main()方法。
		*/
	}
}

双亲委派机制的应用举例2

图2-8 双亲委派机制的应用举例2

当我们加载jdbc.jar用于实现数据库连接的时候，首先我们需要知道的是jdbc.jar是基于SPI接口进行实现的，所以在加载的时候，会进行双亲委派，最终从引导类加载器中加载SPI核心类，然后再加载SPI接口类，接着再进行反向委派，通过线程上下文类加载器进行实现类 jdbc.jar的加载。

5.3 双亲委派机制的优势

避免类的重复加载，确保一个类的全局唯一性。
保护程序安全，防止核心API被随意篡改。
- 自定义类：java.lang.String
- 自定义类：java.lang.ShkStart（报错：禁止包名为java.lang）

package java.lang;

/**
 * @author rrqstart
 * @version v1.0
 * @date 2020-9-12-18:04
 * @Description 自定义一个java.lang包并在其下自定义一个RrqStart类
 */
public class RrqStart {
    public static void main(String[] args) {
        System.out.println("Hello RRQ!");
        //执行该程序报错：java.lang.SecurityException: Prohibited package name: java.lang
    }
}

5.4 双亲委派机制的劣势

检查类是否加载的委托过程是单向的，这个方式虽然从结构上说比较清晰，使各个 ClassLoader 的职责非常明确，但是同时会带来一个问题，即顶层的 ClassLoader 无法访问底层的 ClassLoader 所加载的类。
通常情况下，启动类加载器中的类为系统核心类，包括一些重要的系统接口，而在应用类加载器中，为应用类。按照这种模式，应用类访问系统类自然是没有问题，但是系统类访问应用类就会出现问题。比如在系统类中提供了一个接口，该接口需要在应用类中得以实现，该接口还绑定一个工厂方法，用于创建该接口的实例，而接口和工厂方法都在启动类加载器中。这时，就会出现该工厂方法无法创建由应用类加载器加载的应用实例的问题。
由于 Java 虚拟机规范并没有明确要求类加载器的加载机制一定要使用双亲委派模型，只是建议采用这种方式而已。比如在 Tomcat 中，类加载器所采用的加载机制就和传统的双亲委派模型有一定区别，当缺省的类加载器接收到一个类的加载任务时，首先会由它自行加载，当它加载失败时，才会将类的加载任务委派给它的超类加载器去执行，这同时也是 Servlet 规范推荐的一种做法。

5.5 破坏双亲委派机制

5.5.1 破坏双亲委派机制1

双亲委派模型的第一次“被破坏”其实发生在双亲委派模型出现之前——即 JDK 1.2 面世以前的“远古”时代。
由于双亲委派模型在 JDK 1.2 之后才被引入，但是类加载器的概念和抽象类 java.lang.ClassLoader 则在 Java 的第一个版本中就已经存在，面对已经存在的用户自定义类加载器的代码，Java 设计者们引入双亲委派模型时不得不做出一些妥协，为了兼容这些已有代码，无法再以技术手段避免 loadClass() 被子类覆盖的可能性，只能在 JDK1.2 之后的 java.lang.ClassLoader 中添加一个新的 protected 方法 findClass()，并引导用户编写类加载逻辑时尽可能去重写这个方法，而不是在 loadClass() 中编写代码。双亲委派的具体逻辑就实现在 loadClass()方法里面，按照 loadClass() 方法的逻辑，如果父类加载失败，会自动调用自己的 findClass() 方法来完成加载，这样既不影响用户按照自己的意愿去加载类，又可以保证新写出来的类加载器是符合双亲委派规则的。

5.5.2 破坏双亲委派机制2

第二次破坏双亲委派机制：线程上下文类加载器。
线程上下文类加载器（Thread Context ClassLoader）。这个类加载器可以通过 java.lang.Thread 类的 setContextClassLoader()方法进行设置，如果创建线程时还未设置，它将会从父线程中继承一个，如果在应用程序的全局范围内都没有设置过的话，那这个类加载器默认就是应用程序类加载器。
这是一种父类加载器去请求子类加载器完成类加载的行为，这种行为实际上是打通了双亲委派模型的层次结构来逆向使用类加载器，已经违背了双亲委派模型的一般性原则。

5.5.3 破坏双亲委派机制3

双亲委派模型的第三次“被破坏”是由于用户对程序动态性的追求而导致的。如：代码热替换（Hot Swap）、模块热部署（Hot Deployment）等。

5.6 热替换的实现

热替换是指在程序的运行过程中，不停止服务，只通过替换程序文件来修改程序的行为。热替换的关键需求在于服务不能中断，修改必须立即表现正在运行的系统之中。基本上大部分脚本语言都是天生支持热替换的，比如：PHP，只要替换了 PHP 源文件，这种改动就会立即生效，而无需重启 Web 服务器。
但对 Java 来说，热替换并非天生就支持，如果一个类已经加载到系统中，通过修改类文件，并无法让系统再来加载并重定义这个类。因此，在 Java 中实现这一功能的一个可行的方法就是灵活运用 ClassLoader。
注意：由不同 ClassLoader 加载的同名类属于不同的类型，不能相互转换和兼容。即两个不同的 ClassLoader 加载同一个类，在虚拟机内部，会认为这 2 个类是完全不同的。
根据这个特点，可以用来模拟热替换的实现，基本思路如下图所示：

5.7 沙箱安全机制

沙箱安全机制：保证程序安全；保护Java原生的JDK代码。
Java 安全模型的核心就是 Java 沙箱（sandbox）。什么是沙箱？沙箱是一个限制程序运行的环境。
沙箱机制就是将 Java 代码限定在虚拟机（JVM）特定的运行范围中，并且严格限制代码对本地系统资源访问。通过这样的措施来保证对代码的有限隔离，防止对本地系统造成破坏。
沙箱主要限制系统资源访问，那系统资源包括什么？CPU、内存、文件系统、网络。不同级别的沙箱对这些资源访问的限制也可以不一样。
所有的 Java 程序运行都可以指定沙箱，可以定制安全策略。
自定义String类，但是在加载自定义String类的时候会率先使用引导类加载器加载，而引导类加载器在加载的过程中会先加载jdk自带的文件（rt.jar包中java\lang\String.class），报错信息说没有main方法，就是因为加载的是rt.jar包中的String类。这样可以保证对java核心源代码的保护，这就是沙箱安全机制。

6. 类的使用

在JVM中表示两个 Class 对象是否为同一个类存在两个必要条件：
- 类的完整类名必须一致，包括包名。
- 加载这个类的ClassLoader（指ClassLoader实例对象）必须相同。
换句话说，在JVM中，即使这两个类对象（class对象）来源同一个Class文件，被同一个虚拟机所加载，但只要加载它们的ClassLoader实例对象不同，那么这两个类对象也是不相等的。
JVM必须知道一个类型是由启动类加载器加载的还是由用户类加载器加载的。如果一个类型是由用户类加载器加载的，那么JVM会将这个类加载器的一个引用作为类型信息的一部分保存在方法区中。当解析一个类型到另一个类型的引用的时候，JVM需要保证这两个类型的类加载器是相同的。
如果针对代码，设置参数-XX:+TraceClassLoading，可以追踪类的加载信息并打印出来。
任何一个类型在使用之前都必须经历过完整的加载、链接和初始化3个类加载步骤。一旦一个类型成功经历过这3个步骤之后，开发人员就可以在程序中访问和调用它的静态类成员信息（比如：静态字段、静态方法），或者使用 new 关键字为其创建对象实例。
类的主动使用：＜clinit＞() 方法会被调用。
类的被动使用：＜clinit＞() 方法不会被调用。

6.1 主动使用

Class 只有在必须要首次使用的时候才会被装载，Java 虚拟机不会无条件地装载 Class 类型。Java 虚拟机规定，一个类或接口在初次使用前，必须要进行初始化。这里指的“使用”，是指主动使用，主动使用只有下列几种情况：（即：如果出现如下的情况，则会对类进行初始化操作，而初始化操作之前的加载、验证、准备已经完成。）
（1）当创建一个类的实例时，比如使用 new 关键字，或者通过反射、克隆、反序列化。
（2）当调用类的静态方法时，即当使用了字节码 invokestatic 指令。
（3）当使用类、接口的静态字段时（final 修饰特殊考虑），比如，使用 getstatic 或者 putstatic 指令（对应访问变量、赋值变量操作）。
（4）当使用 java.lang.reflect 包中的反射类的方法时。比如：Class.forName(“com.atguigu.java.Test”)
（5）当初始化子类时，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
（6）如果一个接口定义了 default 方法，那么直接实现或者间接实现该接口的类的初始化，该接口要在其之前被初始化。
（7）当虚拟机启动时，用户需要指定一个要执行的主类（包含 main() 方法的那个类），虚拟机会先初始化这个主类。
（8）当初次调用 MethodHandle 实例时，初始化该 MethodHandle 指向的方法所在的类。（涉及解析 REF_getStatic、REF_putStatic、REF_invokeStatic 方法句柄对应的类）

针对（5）补充说明：

当 Java 虚拟机初始化一个类时，要求它的所有父类都已经被初始化，但是这条规则并不适用于接口。
在初始化一个类时，并不会先初始化它所实现的接口。
在初始化一个接口时，并不会先初始化它的父接口。
因此，一个父接口并不会因为它的子接口或者实现类的初始化而初始化。只有当程序首次使用特定接口的静态字段时，才会导致该接口的初始化。

针对（7）补充说明：

JVM 启动的时候通过引导类加载器加载一个初始类。这个类在调用 public static void main(String[] args) 方法之前被链接和初始化。这个方法的执行将依次导致所需的类的加载，链接和初始化。

6.2 被动使用

除了以上的情况属于主动使用，其他的情况均属于被动使用。被动使用不会引起类的初始化。也就是说：并不是在代码中出现的类，就一定会被加载或者初始化。如果不符合主动使用的条件，类就不会初始化。
（1）当访问一个静态字段时，只有真正声明这个字段的类才会被初始化。当通过子类引用父类的静态变量，不会导致子类初始化，但子类会被加载。
（2）通过数组定义类引用，不会触发此类的初始化。
（3）引用常量不会触发此类或接口的初始化。因为常量在链接阶段的准备环节就已经被显式赋值了。
（4）调用 ClassLoader 类的 loadClass() 方法加载一个类，并不是对类的主动使用，不会导致类的初始化。

public class ClassLoadingTest {
	public static void main(String[] args) {
		// 主动引用：一定会导致A和Father的初始化
		A a = new A();
		System.out.println(A.m);
		Class.forName("com.atguigu.java2.A");
		
		// 被动引用
		A[] array = new A[5];//不会导致A和Father的初始化
		System.out.println(A.b);//只会初始化Father
		System.out.println(A.M);//不会导致A和Father的初始化
	}
	static {
		System.out.println("main所在的类");
	}
}

class Father {
	static int b = 2;
	static {
		System.out.println("父类被加载");
	}
}

class A extends Father {
	static {
		System.out.println("子类被加载");
		m = 300;
	}
	static int m = 100;
	static final int M = 1;
}

7. 类的卸载

7.1 类、类的加载器、类的实例之间的引用关系

在类加载器的内部实现中，用一个 Java 集合来存放所加载类的引用。另一方面，一个 Class 对象总是会引用它的类加载器，调用 Class 对象的 getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的 Class 实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的 Class 对象。在 Object 类中定义了 getClass()方法，这个方法返回代表对象所属类的 Class 对象的引用。此外，所有的 Java 类都有一个静态属性 class，它引用代表这个类的 Class 对象。

7.2 类的生命周期

当 Sample 类被加载、链接和初始化后，它的生命周期就开始了。当代表 Sample 类的 Class 对象不再被引用，即不可触及时，Class 对象就会结束生命周期，Sample 类在方法区内的数据也会被卸载，从而结束 Sample 类的生命周期。一个类何时结束生命周期，取决于代表它的 Class 对象何时结束生命周期。

7.3 案例分析

loader1 变量和 obj 变量间接应用代表 Sample 类的 Class 对象，而 objClass 变量则直接引用它。
如果程序运行过程中，将上图左侧三个引用变量都置为 null，此时 Sample 对象结束生命周期，MyClassLoader 对象结束生命周期，代表 Sample 类的 Class 对象也结束生命周期，Sample 类在方法区内的二进制数据被卸载。
当再次有需要时，会检查 Sample 类的 Class 对象是否存在，如果存在会直接使用，不再重新加载；如果不存在Sample类会被重新加载，在 Java 虚拟机的堆区会生成一个新的代表 Sample 类的 Class 实例（可以通过哈希码查看是否是同一个实例）。

7.4 类的卸载

启动类加载器加载的类型在整个运行期间是不可能被卸载的（jvm 和 jls 规范）。
被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基本上在整个运行期间总能直接或者间接的访问的到，其达到 unreachable 的可能性极小。
被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中（比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能），被加载的类型在运行期间也是几乎不太可能被卸载的（至少卸载的时间是不确定的）。
综合以上三点，一个已经加载的类型被卸载的几率很小至少被卸载的时间是不确定的。同时我们可以看的出来，开发者在开发代码时候，不应该对虚拟机的类型卸载做任何假设的前提下，来实现系统中的特定功能。

8. 方法区的垃圾回收

方法区的垃圾收集主要回收两部分内容：常量池中废弃的常量和不再使用的类型。
HotSpot 虚拟机对常量池的回收策略是很明确的，只要常量池中的常量没有被任何地方引用，就可以被回收。判定一个常量是否“废弃”还是相对简单，而要判定一个类型是否属于“不再被使用的类”的条件就比较苛刻了。需要同时满足下面三个条件：
（1）该类所有的实例都已经被回收。也就是Java堆中不存在该类及其任何派生子类的实例。
（2）加载该类的类加载器已经被回收。这个条件除非是经过精心设计的可替换类加载器的场景，如OSGi、JSP的重加载等，否则通常是很难达成的。
（3）该类对应的java.lang.Class对象没有在任何地方被引用，无法在任何地方通过反射访问该类的方法。
Java 虚拟机被允许对满足上述三个条件的无用类进行回收，这里说的仅仅是“被允许”，而并不是和对象一样，没有引用了就必然会回收。