JVM类加载系统过程解析

最新推荐文章于 2022-08-05 19:26:58 发布

尼獔

最新推荐文章于 2022-08-05 19:26:58 发布

阅读量158

点赞数

文章标签： jvm

本文链接：https://blog.csdn.net/test1_12/article/details/120023362

版权

文章目录

一、类加载系统流程
二、加载过程
- 1.加载阶段
- 3.链接阶段
- 3.初始化阶段

一、类加载系统流程

二、流程解析

1.加载阶段

通过类的全限定名获取定义此类的二进制流，将静态存储结构转化为方法区的运行时数据结构，在内存中生成一个Class对象，作为方法区中类的数据访问口。

2.链接

1、验证：进行正确验证，确保字节码文件包含的信息符合当前JVM的要求

验证的内容则涵盖了类数据信息的格式验证、语义检查、字节码验证，以及符号引用验证等。其中格式验证会和加载阶段一起执行。验证通过之后，类加载器才会成功将类的二进制数据信息加载到方法区中。格式验证之外的验证操作将会在方法区中进行。链接阶段的验证虽然拖慢了加载速度，但是它避免了在字节码运行时还需要进行各种检查

1.格式验证：是否以魔数 OxCAFEBABE开头，主版本和副版本号是否在当前Java虚拟机的支持范围内，数据中每一个项是否都拥有正确的长度等。
2. Java虚拟机会进行字节码的语义检查，但凡在语义上不符合规范的，虚拟机也不会给予验证通过。比如：
是否所有的类都有父类的存在(在Java里，除了Object外，其他类都应该有父类)
是否一些被定义为final的方法或者类被重写或继承了
非抽象类是否实现了所有抽象方法或者接口方法
是否存在不兼容的方法(比如方法的签名除了返回值不同，其他都一样，这种方法会让虚拟机无从下手调度；abstract情况下的方法，就不能是final的了)
3. Java虚拟机还会进行字节码验证，字节码验证也是验证过程中最为复杂的一个过程。它试图通过对字节码流的分析，判断字节码是否可以被正确地执行。比如：
在字节码的执行过程中，是否会跳转到一条不存在的指令
函数的调用是否传递了正确类型的参数
变量的赋值是不是给了正确的数据类型等
栈映射帧(StackMapTable)就是在这个阶段，用于检测在特定的字节码处，其局部变量表和操作数栈是否有着正确的数据类型。但遗憾的是，100%准确地判断一段字节码是否可以被安全执行是无法实现的，因此，该过程只是尽可能地检查出可以预知的明显的问题。如果在这个阶段无法通过检查，虚拟机也不会正确装载这个类。但是，如果通过了这个阶段的检查，也不能说明这个类是完全没有问题的。

4. 校验器还将进行符号引用的验证。Class文件在其常量池会通过字符串记录自己将要使用的其他类或者方法。因此，在验证阶段，虚拟机就会检查这些类或者方法确实是存在的，并且当前类有权限访问这些数据，如果一个需要使用类无法在系统中找到，则会抛出NoClassDefFoundError，如果一个方法无法被找到，则会抛出NoSuchMethodError。
此阶段在解析环节才会执行。

2. 准备: 为非final修饰的类变量(静态变量)分配内存并设置初始值(整形=0，浮点型=0.0，布尔=false,字符型='\0000' 引用数据类型= null）

注意：
        1. 这里不包含基本数据类型的字段用static final修饰的情况，因为final在编译的时候就会分配了，准备阶段会显式赋值。
        2. 注意这里不会为实例变量分配初始化，类变量会分配在方法区中，而实例变量是会随着对象一起分配到Java堆中。
        3. 在这个阶段并不会像初始化阶段中那样会有初始化或者代码被执行。

3. 解析: 将常量池内的符号引用转化为直接引用。

符号引用就是一些字面量的引用，和虚拟机的内部数据结构和和内存布局无关。比较容易理解的就是在Class类文件中，通过常量池进行了大量的符号引用。但是在程序实际运行时，只有符号引用是不够的。

3.初始化阶段

    初始化阶段，简言之，为类的静态变量赋予正确的初始值。
1. 具体描述
        类的初始化是类装我的最后一个阶段。如果前面的步骤都没有问题，那么表示类可以顺利装载到系统中。此时，类才会开始执行Java字节码。(即：到了初始化阶段，才真正开始执行类中定义的Java程序代码。)
初始化阶段的重要工作是执行类的初始化方法：<clinit>()方法。
·该方法仅能由Java编译器生成并由JVM调用，程序开发者无法自定义一个同名的方法，更无法直接在Java程序中调用该方法，虽然该方法也是由字节码指令所组成。
.它是由类静态成员的赋值语句以及static语句块合并产生的。
2. 说明
        2.1在加载一个类之前，虚拟机总是会试图加载该类的父类，因此父类的<clinit>总是在子类<clinit>之前被调用。也就是说，父类的static块优先级高于子类。
        2.2 Java编译器并不会为所有的类都产生<clinit>()初始化方法。哪些类在编译为字节码后，字节码文件中将不会包含<clinit>()方法？
·一个类中并没有声明任何的类变量，也没有静态代码块时
·一个类中声明类变量，但是没有明确使用类变量的初始化语句以及静态代码块来执行初始化操作一个类中包含static final修饰的基本数据类型的字段，这些类字段初始化语句采用编译时常量表达式.

总结：使用static+final修饰并且赋值中不涉及到方法或构造器调用的基本数据类型或String类型的显示赋值,是在链接阶段的准备环节进行.

以下几种都是在client中执行:

public class TestClient {
    static int a  = 1;
    static final  Integer g = new Integer(13);
    static Integer h = new Integer(14);
    static  String j = "abc";
    static  final  String k = new String("AB");
}

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

类的主动使用和被动使用:

一：主动使用：执行clinit过程

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方法句柄对应的类)

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

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

三.类的Using

开发人员可以在程序中访问和调用它的静态类成员信息(比如：静态字段、静态方法)，或者使用new关键字为其创建对象实例

四.类的Unloading(卸载)

一、类、类的加载器、类的实例之间的引用关系
在类加载器的内部实现中，用一个Java集合来存放所加载类的引用。另一方面，一个Class对象总是会引用它的类加载器，调用Class对象的getClassLoader()方法，就能获得它的类加载器。由此可见，代表某个类的Class实例与其类的加载器之间为双向关联关系。
一个类的实例总是引用代表这个类的Class对象。在Object类中定义了getClass()方法，这个方法返回代表对象所属类的Class对象的引用。此外，所有的Java类都有一个静态属性class，它引用代表这个类的Class对象。
二、类的生命周期
当Sample类被加载、链接和初始化后，它的生命周期就开始了。当代表Sample类的Class对象不再被引用，即不可触及时，Class对象就会结束生命周期，Sample类在方法区内的数据也会被卸载，从而结束Sample类的生命周期。
一个类何时结束生命周期，取决于代表它的Class对象何时结束生命周期。

类的卸载：
         (1)启动类加载器加载的类型在整个运行期间是不可能被卸载的(jvm和jls规范)
        (2)被系统类加载器和扩展类加载器加载的类型在运行期间不太可能被卸载，因为系统类加载器实例或者扩展类的实例基
本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。
        (3)被开发者自定义的类加载器实例加载的类型只有在很简单的上下文环境中才能被卸载，而且一般还要借助于强制调用虚拟机的垃圾收集功能才可以做到。可以预想，稍微复杂点的应用场景中(比如：很多时候用户在开发自定义类加载器实例的时候采用缓存的策略以提高系统性能)，被加载的类型在运行期间也是几乎不太可能被卸载的(至少卸载的时间是不确定的)。
100%