面试备战日记（2.3） - （JVM.类加载机制）-CSDN博客

本文链接：https://blog.csdn.net/weixin_44414492/article/details/122257761

本人本科毕业，21届毕业生，一年工作经验，简历专业技能如下，现根据简历，并根据所学知识复习准备面试。

记录日期：2021.12.30

大部分知识点只做大致介绍，具体内容根据推荐博文链接进行详细复习。

JVM - 类加载机制

参考《深入理解JVM虚拟机》7.3章。

类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段。其中验证、准备、解析3个部分统称为连接。

一般我们主要是要清楚加载、验证、准备、解析、初始化这五个阶段所做的内容。

在这里插入图片描述

类加载时机（加载前）

加载（loading）阶段，java虚拟机规范中没有进行约束，但初始化阶段，java虚拟机严格规定了有且只有如下5种情况必须立即进行初始化（初始化前，必须经过加载、验证、准备阶段）：

使用new实例化对象时，访问和更新类的静态变量、静态非字面值常量（静态字面值常量除外）时以及调用静态方法时。

public staic void main(String[] args) {
	Test1 test = new Test1(); // 使用new实例化对象
	Test2.str = "abc"; // 更新类的静态变量
	Test3.staticMethod(); // 调用静态方法
}

class Test1 {}
class Test2 {
    public static str = "def";
}
class Test3 {
    public static void staticMethod() {
        System.out.println("这是一个静态方法");
    }
}

对某个类进行反射操作时。

public static void main(String[] args) throws ClassNotFoundException {
    //通过反射导致Demo类初始化
    Class.forName("com.demo.test.Demo");
}

当初始化一个类时，如果父类没有进行初始化，需要先初始化父类。

public class Parent {
    static{
        System.out.println("父类初始化");
    }
    public static int x = 10;
}
public class Child{
    static{
        System.out.println("子类初始化");
    }
    public static int y = 100;
}
public class Test {
    public static void main(String[] args) throws ClassNotFoundException {
        System.out.println(Child.y);//输出 父类初始化 子类初始化 100
        //System.out.println(Child.x);//输出 父类初始化 10
    }
}

注意：通过子类使用父类的静态变量只会导致父类的初始化，子类不会初始化，这个在下面被动引用 1 中会提到。

启动程序所使用的main方法所在类。

public class Test05 {
    static {
        System.out.println("main方法入口启动类被初始化");
    }
    public static void main(String[] args) throws ClassNotFoundException {
        Parent[] parent = new Parent[10];
        System.out.println(parent.length);
    }
}

Parent类不会被初始化，这个在下面被动引用 2 中会提到。

当使用1.7的动态语言支持时。

以上的场景都称之为主动引用，除此之外被称为被动引用，有如下三种情况：

通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
构造某个类的数组和集合，不会触发该类的初始化。
类A引用类B的static final常量不会导致类B初始化（注意静态常量必须是字面值常量，否则还是会触发B的初始化）。

public class Simple {
    static{
        System.out.println("进行初始化");
    }
    //访问静态常量MAX不会导致Simple类的初始化
    public final static int MAX = 10;
    //虽然RANDOM是静态常量，但是由于计算复杂，只有初始化后才能得到结果，因此其他类使用RANDOM会导致Simple类的初始化
    public final static int RANDOM = new java.util.Random(10).nextInt();
}

加载

加载的过程主要完成以下三件事：

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

虚拟机规范的这3点要求其实并不算具体，因此虚拟机实现与具体应用的灵活度都是相当大的。

所以加载.class文件的方式就有很多种，如下所示

从网络中获取，这种场景最典型的应用就是Applet。
从ZIP包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。
从数据库中读取，这种场景相对少见些，例如有些中间件服务器（如SAP Netweaver）可以选择把程序安装到数据库中来完成程序代码在集群间的分发。
运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang.reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成形式为“*$Proxy”的代理类的二进制字节流。
由其他文件生成，典型场景是JSP应用，即由JSP文件生成对应的Class类。

相对于类生命周期的其他阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

连接 - 验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。从整体上看，验证阶段大致上会完成下面4个阶段的检验动作：文件格式验证、元数据验证、字节码验证、符号引用验证。

1. 文件格式验证

验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，这一阶段可能包括下面这些验证点：

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

2. 元数据验证

对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求，这个阶段可能包括的验证点如下：

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

3. 字节码验证（最复杂）

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

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

4. 符号引用验证

校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性校验，通常需要校验下列内容：

符号引用中通过字符串描述的全限定名是否能找到对应的类。
在指定类中是否存在符合方法的字段描述符以及简单名称所描述的方法和字段。
符号引用中的类、字段、方法的访问性（private、protected、public、default）是否可被当前类访问。
…

对于虚拟机的类加载机制来说，验证阶段是一个非常重要的、但不是一定必要（因为对程序运行期没有影响）的阶段。如果所运行的全部代码（包括自己编写的及第三方包中的代码）都已经被反复使用和验证过，那么在实施阶段就可以考虑使用**-Xverify：none**参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

连接 - 准备

该阶段是正式为类变量（static修饰的变量）分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这里所说的初始值“通常情况”下是数据类型的零值，下表列出了Java中所有基本数据类型的零值。

在这里插入图片描述

连接 - 解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用（内存地址）的过程。

符号引用就是一组符号来描述目标，可以是任何字面量。属于编译原理方面的概念如：包括类和接口的全限定名、字段的名称和描述符、方法的名称和描述符。
直接引用就是直接指向目标的指针、相对偏移量或一个间接定位到目标的句柄。如指向方法区某个类的一个指针。

假设：一个类有一个静态变量，该静态变量是一个自定义的类型，那么经过解析后，该静态变量将是一个指针，指向该类在方法区的内存地址。

初始化

到了初始化阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，变量已经赋过一次系统要求的初始零值，而在初始化阶段，则会根据程序员通过程序制定的主观计划去初始化类变量和其他资源。

我们也可以从另外一种更直接的形式来表达：初始化阶段是执行类构造器()方法的过程。() 不是程序员在 Java 代码中直接编写的方法，而是由Javac 编译器自动生成的。

() 方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。

接下来是面试注意点

1.static变量和static final的不同？

这个在《深入理解JVM虚拟机》7.3.3 提到。

主要是赋值阶段不同， static final在解析的阶段就已经进行赋值了，但是static还需要在初始化阶段的时候混合static块中集中进行赋值。这里的的意思就是在方法区运行时常量池中查找。也就是静态变量实际上存在方法区，开辟空间给静态变量赋值。

static final 必须是基本类型才能够在解析的时候初始化。
static在初始化阶段把static块和变量结合成新的新cinit方法进行初始化。

2.区分clinit 与 init？

clinit指的是类构造器，主要作用是在类加载过程中的初始化阶段进行执行，执行内容包括静态变量初始化和静态块的执行。

注意事项：

如果类中没有静态变量或静态代码块，那么clinit方法将不会被生成。
在执行clinit方法时，必须先执行父类的clinit方法。
clinit方法只执行一次。
static变量的赋值操作和静态代码块的合并顺序由源文件中出现的顺序决定。

init指的是实例构造器，主要作用是在类实例化过程中执行，执行内容包括成员变量初始化和代码块的执行。

注意事项：

如果类中没有成员变量和代码块，那么clinit方法将不会被生成。
在执行init方法时，必须先执行父类的init方法。
init方法每实例化一次就会执行一次。
init方法先为实例变量分配内存空间，再执行赋默认值，然后根据源码中的顺序执行赋初值或代码块。

3.考考对初始化顺序的理解？

参考囧辉文章链接：一道有意思的“初始化”面试题

类加载器

从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

从Java开发人员的角度来看，类加载器还可以划分得更细致一些，绝大部分Java程序都会使用到以下3种系统提供的类加载器：

启动类加载器（Bootstrap ClassLoader）

前面已经介绍过，这个类将器负责将存放在＜JAVA_HOME＞\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。

启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器，那直接使用null代替即可。

扩展类加载器（Extension ClassLoader）

这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载＜JAVA_HOME＞\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

应用程序类加载器（Application ClassLoader）

这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

我们的应用程序都是由这3种类加载器互相配合进行加载的，如果有必要，还可以加入自己定义的类加载器。这些类加载器之间的关系一般如图所示。

在这里插入图片描述

双亲委派模型

如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

类加载的代码在java.lang.ClassLoader下：

// 源代码中是String var1 和 boolean var2，这里进行替换
protected Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        synchronized (this.getClassLoadingLock(name)) {
            // 1、检查请求的类是否已经被加载过了
            Class<?> c = this.findLoadedClass(name);
            if (c == null) {
                long t0 = System.nanoTime(); // 记录时间戳
                try {
                    // 2、将类加载请求先委托给父类加载器
                    if (this.parent != null) {
                        // 父类加载器不为空时，委托给父类加载进行加载
                        c = this.parent.loadClass(name, false);
                    } else {
                        // 父类加载器为空，则代表当前是Bootstrap，从Bootstrap中加载类
                        c = this.findBootstrapClassOrNull(name);
                    }
                } catch (ClassNotFoundException e) {
                    // 如果父类加载器抛出ClassNotFoundException
                    // 说明父类加载器无法完成加载请求
                }
 
                if (c == null) {
                    // 3、在父类加载器无法加载的时候，再调用本身的findClass方法来进行类加载
                    long t1 = System.nanoTime();
                    c = findClass(name);
                    sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                    sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                    sun.misc.PerfCounter.getFindClasses().increment();
                }
            }
            if (resolve) {
                this.resolveClass(c); // 调用native方法解析类加载器
            }
            return c;
        }
    }

使用双亲委派模型的目的？

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是 Java 类随着它的类加载器一起具备了一种带有优先级的层次关系，让类的加载有先后。
优先加载核心类，并且共享给下级的类加载器使用。

如果没有使用双亲委派模型，由各个类加载器自行去加载的话，如果用户自己编写了一个java.lang.Object 的类，并放在程序的 ClassPath 中，那系统中将会出现多个不同的 Object 类，Java 类型体系中最基础的行为也就无法保证，应用程序也将会变得一片混乱。

什么场景破坏双亲委派模型？

博客参考链接：面试必问的 JVM 类加载机制，你懂了吗？

1.JDBC

JDBC之所以要破坏双亲委派模式是因为，JDBC的核心在rt.jar中由启动类加载器加载，而其实现则在各厂商实现的的jar包中，根据类加载机制，若A类调用B类，则B类由A类的加载器加载，也就是说启动类加载器要加载jar包下的类，我们都知道这是不可能的，启动类加载器负责加载$JAVA_HOME中jre/lib/rt.jar里所有的class，那么JDBC是如何加载这些Driver实现类的？
通过Thread.currentThread().getContextClassLoader()得到线程上下文加载器来加载Driver实现类。