深入理解jvm-类加载过程

野性酷女 2023-07-25 11:29 10阅读 0赞

> 本文为读书笔记,个人觉得相比垃圾回收,这一部分是十分重要的,故做个留存笔记

### 文章目录 ###

*  1.类的生命周期
 *  2.类加载的过程
 *   *  2.1 "加载"阶段
     *  2.2 验证阶段
     *  2.3 准备阶段
     *  2.4 解析阶段
     *  2.5 初始化阶段
 *  3.类加载器
 *   *  3.1 双亲委派模型
     *   *  启动类加载器
         *  扩展类加载器
         *  应用程序类加载器
         *  双亲委派模型
         *  破坏双亲委派
         *  附加:不同classloader 加载同一类,最后getclass equals 判断false案例
 *  上下文类加载器

# 1.类的生命周期 #

加载->验证->准备->解析->初始化->使用->卸载  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]

要点:

*  加载、验证、准备、初始化和卸载这五个阶段的顺序是确定的
 *  解析阶段在某些情况下可以在初始化阶段之后再开始
 *  类加载过程的第一个阶段“加载”的实际没有明确定义
 *  但六种情况必须立即对类进行“初始化” :  
    1.遇到new、getstatic、putstatic或invokestatic这四条字节码指令时，如果类型没有进行过初始化，则需要先触发其初始化阶段。

> 这四条指令触发条件为:·
> 
>  *  使用new关键字实例化对象的时候。
>  *  读取或设置一个类型的静态字段·
>  *  调用类的静态方法时

2.反射调用,若没有初始化则初始化  
3. main方法的执行主类  
4.反射方法句柄解析为REF\_getStatic、REF\_putStatic、REF\_invokeStatic、REF\_newInvokeSpecial对应的类没有进行过初始化  
5.被default关键字修饰的接口方法被实现的类先初始化  
6.初始化类时,父类未初始化则触发父类的初始化  
**有且只有这六种场景表示对一个类型的主动引用**

**实现案例:**

*  通过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化。
 *  常量会在编译的时候加入到类的常量池内,本质上没有直接引用到定义常量的类,因此不会触发初始化
 *  数组不会触发类的初始化,原因为这个类型虚拟机自动生成的、直接继承于java.lang.Object的子类，创建动作由字节码指令newarray触发。  
    **在考虑一个类是否被初始化的时候,考虑一下它是不是被动引用了;即类初始化是懒惰的**  
    这里还有资料测试了,我把它列出来,不会引发初始化的
 *  类对象.class
 *  类加载的loadClass方法
 *  Class.forname()第二个参数为false的时候
 *  接口也有初始化过程,差不多与类一致

> **对于类初始化的个人理解:**  
> 其实上面已经提到了,即类初始化是懒惰的,这样可以节约内存空间,当然,有些程序讲究一个预热过程,如果我们一开始就把它全部预热,到时候就不用了初始化了

例子:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]  
测试1:  
![在这里插入图片描述][2020041520380244.png]  
![在这里插入图片描述][20200415203810844.png]  
测试2:  
![在这里插入图片描述][20200415203847219.png]  
![在这里插入图片描述][20200415203854541.png]  
怎样才能触发MM的初始化呢?  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 2]  
再来执行以上的代码:  
![在这里插入图片描述][20200415204029416.png]  
这样得出了一个结论:**只有基本类型和String能够作为自身常量池的直接引用  
其他引用类型作为final类使用会被触发本类的初始化,即<cinit>,而<cinit>主要做的功夫就是初始化类中中所定义的成员变量。**

> 同时问题来了，final类什么时候会被初始化？  
> 被final修饰的类属性会被作为编译期常量加入常量池，以后访问对应类的常量池，不会在常量池中保存一个指向类str字段的符号引用，不触发类的初始化。

# 2.类加载的过程 #

## 2.1 "加载"阶段 ##

> 请弄清楚“加载”（Loading）阶段是整个“类加载”（Class Loading）过程中的一个阶段

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

注意点:

*  数组类本身不通过类加载器创建,但数组类的元素类型还是由类加载器来加载
 *  加载阶段尚未完成，连接阶段可能已经开始

## 2.2 验证阶段 ##

> 目的是确保Class文件的字节流中包含的信息符合《Java虚拟机规范》的全部约束要求,java语言安全性的保证阶段

1.文件格式验证

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

2.元数据验证(对类的元数据信息进行语义校验)

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

3.字节码验证

*  保证任意时刻操作数栈的数据类型与指令代码序列都能配合工作
 *  保证任何跳转指令都不会跳转到方法体以外的字节码指令上。
 *  ·保证方法体中的类型转换总是有效的，例如可以把一个子类对象赋值给父类数据类型，这是安全的，但是把父类对象赋值给子类数据类型，甚至把对象赋值给与它毫无继承关系、完全不相干的一个数据类型，则是危险和不合法的。
 *  …等等

4.符号引用验证

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

## 2.3 准备阶段 ##

> 准备阶段是正式为类中定义的变量（即静态变量，被static修饰的变量）分配内存并设置类变量初始值的阶段

注意点:  
进行内存分配的仅包括类变量，而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。  
举例:

public static int value = 123;

变量value在准备阶段过后的初始值为0而不是123，因为这时尚未开始执行任何Java方法，而把value赋值为123的**putstatic指令是程序被编译后**，存放于类构造器()方法之中，所以把**value赋值为123的动作要到类的初始化阶段才会被执行。**  
但是对于:

public static final int value = 123;

果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量值就会被初始化为ConstantValue属性所指定的初始值

## 2.4 解析阶段 ##

> 解析阶段是Java虚拟机将常量池内的符号引用替换为直接引用的过程

弄清一下概念:  
符号引用:符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。

直接引用:直接引用是可以直接指向目标的指针、相对偏移量或者是一个能间接定位到目标的句柄。  
1.类或接口的解析  
2.字段解析  
3.方法解析

## 2.5 初始化阶段 ##

> 直到初始化阶段，Java虚拟机才真正开始执行类中编写的Java程序代码，将主导权移交给应用程序。  
> 初始化阶段就是执行类构造器()方法的过程。

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

Java虚拟机会保证在子类的<clinit>()方法执行前，父类的<clinit>()方法已经执行完毕。

<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。  
执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，因为只有当父接口中定义的变量被使用时，父接口才会被初始化。

Java虚拟机必须保证一个类的<clinit>()方法在多线程环境中被正确地加锁同步

# 3.类加载器 #

> Java虚拟机设计团队有意把类加载阶段中的“通过一个类的全限定名来获取描述该类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需的类。实现这个动作的代码被称为“类加载器”（Class Loader）。

对于任意一个类，都必须**由加载它的类加载器和这个类本身一起共同确立其在Java虚拟机中的唯一性**，每一个类加载器，都拥有一个独立的类名称空间。

即:较两个类是否“相等”，**只有在这两个类是由同一个类加载器加载的前提下才有意义**，否则，即使这两个类来源于同一个Class文件，被同一个Java虚拟机加载，只要加载它们的类加载器不同，那这两个类就必定不相等。

**假如存在有两个类加载器加载出来的类对象,并由生成了对应的对象,那么在做对象所属类型检查的时候,结果就是false**

## 3.1 双亲委派模型 ##

类别:  
启动类加载器（BootstrapClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；  
其他所有的类加载器，这些类加载器都由Java语言实现，独立存在于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。

### 启动类加载器 ###

负责加载存放在<JAVA\_HOME>\\lib目录，或者被-Xbootclasspath参数所指定的路径中存放的，而且是Java虚拟机能够识别的（按照文件名识别，如rt.jar、tools.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机的内存中。  
**启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 3]

### 扩展类加载器 ###

> 这个类加载器是在类sun.misc.Launcher$ExtClassLoader中以Java代码的形式实现的。它负责加载<JAVA\_HOME>\\lib\\ext目录中，或者被java.ext.dirs系统变量所指定的路径中所有的类库。

### 应用程序类加载器 ###

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

### 双亲委派模型 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 4]

双亲委派模型要求除了顶层的启动类加载器外，其余的类加载器都应有自己的父类加载器。  
不过这里类加载器之间的父子关系一般不是以继承（Inheritance）的关系来实现的，而是通常使用组合（Composition）关系来复用父加载器的代码。

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

好处:  
一个显而易见的好处就是Java中的类随着它的类加载器一起具备了一种带有优先级的层次关系。

> 例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给处于模型最顶端的启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都能够保证是同一个类。

如果任由其他的类加载器去加载的话,最后类型判定肯定会出现迷惑行为

代码实现:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 5]

### 破坏双亲委派 ###

loadclass -> findclass  
JNDI服务 ->基础类型又要调用回用户的代码  
热部署->收到类加载请求时,扫描类并加载

### 附加:不同classloader 加载同一类,最后getclass equals 判断false案例 ###

public static void main(String[] args) throws ClassNotFoundException, IllegalAccessException, InstantiationException {
            ClassLoader myClassLoader = new ClassLoader() {
                @Override
                public Class<?> loadClass(String name) throws ClassNotFoundException {
                    try {
                        String filename = name.substring(name.lastIndexOf(".") + 1) + ".class";
                        InputStream is = getClass().getResourceAsStream(filename);
                        if (is == null) {
                            return super.loadClass(name);
                        }
                        byte[] b = new byte[is.available()];
                        is.read(b);
                        return defineClass(name, b, 0, b.length);
                    } catch (IOException e) {
                        e.printStackTrace();
                    }
                    return null;
                }
            };
    
            Class<?> aClass = myClassLoader.loadClass("com.lyq.boot.lexicalanalysis.A");
            Object o =  aClass.newInstance();
            A a = new A();
            System.out.println(o.getClass().equals(a.getClass()));
        }

# 上下文类加载器 #

即父类加载器加载的类需要用到子类加载的类  
子类加载器都保留了父类加载器的引用。但如果父类加载器加载的类需要访问子类加载器加载的类该如何处理？最经典的场景就是JDBC的加载。

JDBC是Java制定的一套访问数据库的标准接口，它包含在Java基础类库中，由根类加载器加载。而各个数据库厂商的实现类库是作为第三方依赖引入使用的，这部分实现类库是由应用类加载器进行加载的。

获取Mysql连接的代码：

//加载驱动程序

Class.forName("com.mysql.jdbc.Driver");

//连接数据库

Connection conn = DriverManager.getConnection(url, user, password);

DriverManager由启动类加载器加载，它使用到的数据库驱动（com.mysql.jdbc.Driver）是由应用类加载器加载的，这就是典型的由父类加载器加载的类需要访问由子类加载器加载的类。

这一过程的实现，看DriverManager类的源码：

//建立数据库连接底层方法
    private static Connection getConnection(
            String url, java.util.Properties info, Class<?> caller) throws SQLException { 
        //获取调用者的类加载器
        ClassLoader callerCL = caller != null ? caller.getClassLoader() : null;
        synchronized(DriverManager.class) { 
            //由启动类加载器加载的类，该值为null，使用上下文类加载器
            if (callerCL == null) { 
                callerCL = Thread.currentThread().getContextClassLoader();
            }
        }
    ```java
        //...
    
        for(DriverInfo aDriver : registeredDrivers) { 
            //使用上下文类加载器去加载驱动
            if(isDriverAllowed(aDriver.driver, callerCL)) { 
                try { 
                    //加载成功，则进行连接
                    Connection con = aDriver.driver.connect(url, info);
                    //...
                } catch (SQLException ex) { 
                    if (reason == null) { 
                        reason = ex;
                    }
                }
            } 
            //...
        }
    }
    在上面的代码中留意改行代码：
    
    ```java
    callerCL = Thread.currentThread().getContextClassLoader();

这行代码从当前线程中获取ContextClassLoader，而ContextClassLoader在哪里设置呢？就是在上面的Launcher源码中设置的：

// 设置上下文类加载器  
Thread.currentThread().setContextClassLoader(this.loader);  
这样一来，所谓的上下文类加载器本质上就是应用类加载器。因此，上下文类加载器只是为了解决类的逆向访问提出来的一个概念，并不是一个全新的类加载器，本质上是应用类加载器。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70]: /images/20230528/6f67717c3621437d802115c044e75f86.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 1]: /images/20230528/3048a36d2a364542aaabb20bab4f8e56.png
[2020041520380244.png]: /images/20230528/f21c1157cf284123b7e8f551337f06f5.png
[20200415203810844.png]: /images/20230528/d315363339574b06a7b7a5bf78fc5099.png
[20200415203847219.png]: /images/20230528/8aa68494e96b43d994114abb8ca88ea8.png
[20200415203854541.png]: /images/20230528/dcad5952165a4ddb9a56994ac6a68836.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 2]: /images/20230528/7d25ecb161584e0290b69555e8d35ac6.png
[20200415204029416.png]: /images/20230528/c95350fdebd04268b92418196e643707.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 3]: /images/20230528/1c26127d696941a5931c7494af953ab1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 4]: /images/20230528/8188cdf2cd4a49ec95a1bdb7f201e018.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2xpdHRsZXdoaXRldmc_size_16_color_FFFFFF_t_70 5]: /images/20230528/4282ad0578d24e98b65741de7866a9a3.png