JVM II —— 类加载

最新推荐文章于 2022-04-10 00:27:26 发布

爱得恋

最新推荐文章于 2022-04-10 00:27:26 发布

阅读量126

点赞数 1

分类专栏： JAVA Web

本文链接：https://blog.csdn.net/yuiop123455/article/details/109271841

版权

JAVA Web 专栏收录该内容

24 篇文章 1 订阅

订阅专栏

类加载

一、类加载的理解
二、类的生命周期
二、类加载器
三、类加载机制——双亲委派机制

一、类加载的理解

什么时候会进行类加载？
---------->当用到一个类，但是这个类不在内存中，这个时候就需要发生类加载。

那麽问题来了，什么时候会用到一个类呢？

构造一个对象（new对象）
调用静态属性/方法 即 类.xxx操作
子类触发父类 即包括：初始化一个子类对象（该子类对象继承了父类）、子类向上转型为父类/接口等

什么是类加载？
那么就可以解释什么是类加载了，类加载： 就是将编译好的.class字节码文件读入到Java内存中，并为之创建一个java.lang.Class对象（也就是说程序使用任何类时，系统都会为之建立一个java.lang.Class对象），并完成对类的初始化工作，来使得这个类可以被程序使用！

类加载的目的：
简单的理解：程序中使用某个类的时候，内存中，没有这个类，所有JVM就会进行类加载，使得这个类可以被程序使用！！！ 当然了类加载又包括加载，连接，初始化三个步骤。

二、类的生命周期

Java是一门面向对象的语言，离不开类和对象；那么一个类的生命周期是如何的呢？

类的生命周期主要包括7个阶段：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）。

其中验证、准备、解析3个部分统称为连接（Linking）。
在这里插入图片描述
【注意】：

我们这里所说的类的生命周期是从Java类编译之后的.class字节码文件开始的，JVM加载类也是加载的是字节码文件。
解析阶段在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定），即多态过程中发生的动态绑定。
类的生命周期包括上面七个，前五个阶段叫做类加载阶段。

接下来我们详细讲解一下Java虚拟机中类加载的全过程：加载、验证、准备、解析和初始化这5个阶段所执行的具体动作。

1、加载

加载阶段：就是将.class字节码文件加载到java虚拟机内存中。

类加载的条件：通过类.静态方法/静态变量都会导致类加载。

加载过程：

通过一个类的全限定名（类的全名）来获取定义此类的二进制字节流。
将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。--------->
- 只是对数据结构的转换，不设计引用指向方面的操作。
- 对于静态变量只是对其定义了一下，放在运行时的数据结构，并没有对其进行赋值
在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口。
- Java虚拟机需要管理类，是通过类对象来管理的，所以生成一个类对象（就是这里的class对象）；访问类里边的变量/静态方法都是通过这个对象进行调用

在这里插入图片描述

2、验证

这一阶段的目的是为了确保Class字节码文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。

3、准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。

我们假设一个类变量的定义为：

public static int value=200;

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

4、解析

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

符号引用： 符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中。
- 文件在编译成字节码文件的时候存在符号引用了，在class文件常量池里，和内存无关，这个时候进程也不存在，类也没有加载到内存中去；所以符号引用和内存无关。
直接引用： 直接引用是和虚拟机实现的内存布局相关的。如果有了直接引用，那引用的目标必定已经在内存中存在。(是在内存中有了这些变量，所以要存在一个直接引用。)

我们上边还提到了解析阶段在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定），即多态过程中发生的动态绑定。

5、初始化

准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源.

从另外一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

就比如上面定义类变量的例子：

public static int value=200;

准备阶段value系统的初始值是0，初始化阶段value的值才是200；

< clinit>()方法介绍：

1 ) < clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的

编译器收集的顺序是由语句在源文件中出现的顺序所决定的;
静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值不能访问
如：

public class Test{
    static{
        i=0; //给变量赋值可以正常编译通过
        System.out.print(i); //这句编译器会提示"非法向前引用"
    }
    static int i=1；
}

2）< clinit>()方法与类的构造函数（或者说实例构造器()方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的<init>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的()方法的类肯定是java.lang.Object。

3）< clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成< clinit>()方法。

4）接口中定义的变量使用时，接口才会初始化： 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此

相同点：接口与类一样都会生< clinit>()方法。
但接口与类不同的是：执行接口的< clinit>()方法不需要先执行父接口的< clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的< clinit>()方法。

5）虚拟机会保证一个类的< clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的< clinit>()方法，其他线程都需要阻塞等待，直到活动线程执行< clinit>()方法完毕。如果在一个类的< clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

< clinit>()方法和< init>()方法：

<clinit>()方法是类对象初始化方法，通过调用clinit方法生成类对象
<init>()方法是对象初始化方法，他是一个字节码方法，表示类具体的new操作，生成一个实例对象的构造方法

初始化顺序

对于初始化顺序我们从三个角度来考虑，分别是父类和子类的顺序、类里边静态变量/代码块顺序、对象的构造方法和构造代码块（实例代码块）的顺序。

1)父类和子类的顺序：父类初始化永远先于子类。

2)类静态代码块顺序：按照静态代码块的书写顺序(静态变量和静态代码块也是按照书写顺序执行)

静态代码块只会执行一次

3）对象：构造代码块（也叫实例代码块，类中不加任何关键字的代码块）先于构造方法，多个构造代码块按照书写顺序。

总的顺序就是：父类静态代码块、子类静态代码块、父类构造代码块、父类构造方法、子类构造代码块、子类构造方法。

示例代码：

public class Parent {
    static {
        A = 200;
    }
    public static int A = 100;
    static {
        System.out.println("父类静态代码块：A="+A);
    }
    public int c = 100;
    public String name;
    {
        System.out.println("父类构造代码块（实例代码块）："+c);
    }
    public Parent(int c, String name){
        this.c = c;
        this.name = name;
        System.out.println("父类构造方法");
        print();
    }
    public void print(){
        System.out.println("Parent print, c="+c+", name=Parent");
    }
    public static void main(String[] args) {
        new Child(200);
    }
}
class Child extends Parent {
    static {
        A = 400;
    }
    public static int A = 300;
    {
        System.out.println("子类构造代码块（实例代码块）："+c);
    }
    static {
        System.out.println("子类静态代码块：A="+A);
    }
    public Child(int c) {
        super(c, "Child");
        System.out.println("子类构造方法");
    }
    @Override
    public void print() {
        System.out.println("Child print, c="+c+", name="+name);
    }
}

执行结果：

在这里插入图片描述

需要初始化的5种情况：

如果类没有进行过初始化，则需要先触发其初始化。虚拟机规范则是严格规定了有且只有5种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在此之前开始）：

创建类的实例(new 的方式)，即构造实例对象。访问某个类或接口的静态变量，或者对该静态变量赋值，调用类的静态方法（类.xxx调用）========》只要是类.xxx操作都需要进行类加载（初始化是类加载的一个过程）
反射的方式
初始化某个类的子类，则其父类也会被初始化；否则找不到父类
Java虚拟机启动时被标明为启动类的类，直接使用java.exe命令来运行某个主类（包含main方法的那个类）
使用JDK1.7的动态语言支持（动态语言即：类型检查的主体过程是在运行期而不是编译期进行）

二、类加载器

类加载器可以分为：启动类加载器、扩展类加载器、应用程序类加载器、自定义类加载器。在这里插入图片描述

1、启动类加载器（Bootstrap ClassLoader）

启动类加载器加载的类：

有些类，是所有应用程序都需要的，并且是基础部分，那么启动类加载器就负责加载这些类（也就是JDK中的所有类），比如String类。
这个类加载器负责将存放在＜JAVA_HOME＞\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。
启动类加载器无法被Java程序直接引用

用户如何直接指定使用启动类加载器：

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

public class MyClassLoader extends ClassLoader{

    protected MyClassLoader(ClassLoader parent) {
        super(parent);
    }

    // 使用ClassLoader父类的构造方法：根据ClassLoader中loadClass可以知道，设置父类加载器为null会使用Bootstrap ClassLoader来加载
    protected MyClassLoader() {
        this(null);
    }
}

2、扩展类加载器（Extension ClassLoader）

扩展类加载器加载的类：

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

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

这个类加载器由sun.misc.Launcher $App-ClassLoader实现。由于这个类加载器是ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般也称它为系统类加载器。

应用程序类加载器加载的类：

它负责加载用户类路径（ClassPath）上所指定的类库，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。
开发者可以直接使用这个类加载器

三、类加载机制——双亲委派机制

双亲委派机制顾名思义，每次类加载都会需要通过父类加载器，那么它具体的过程是如何呢？

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

双亲委派机制查找类加载器过程：
在这里插入图片描述
我们以JVM需要加载String类为例具体说一下该过程：

jvm双亲委派机制查找类加载器过程：

首先会请求加载它的父类加载器（ApplicationClassLoader）
ApplicationClassLoader再请求它的父类加载器（Extension ClassLoader）
Extension ClassLoader在请求加载他的父类加载器（Bootstrap ClassLoader），然后Bootstrap ClassLoader在rt.jar中找到java\lang\String.class,因此就是用启动类加载器来加载该类。

那么问题来了，如果我在当前目录自己定义了一个String类型的类（不是系统的）呢？

==========> 如果没有双亲委派就会直接将自己定义的String加载到；
因此，JVM每次都是和 ApplicationClassLoader（应用程序类加载器）先打交道，一层一层先往上直到启动类加载器（Bootstrap ClassLoader），如果启动类加载器没有，再一层一层向下退（寻找该类）；
如果退到最后一层类加载器（即应用程序类加载器）还是没有找到该类，就会抛一个ClassNotFoundException

双亲委派的好处：
如果没有双亲委派机制，一上来就直接在ApplicationClassLoader加载就会加载到我自定义的类（和系统类定义的名字相同），这就会出现问题。

====》JVM每次只和应用程序类加载器（Application ClassLoader）打交道，并且为了保证正确的类加载，所以有双亲委派机制。使得Java类随着它的类加载器一起具备了一种带有优先级的层次关系。

双亲委派逻辑实现：
双亲委派模型对于保证Java程序的稳定运作很重要，但它的实现却非常简单，实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass () 方法之中，逻辑清晰易懂

实现逻辑：

先检查是否已经被加载过，若没有加载则调用父加载器的loadClass（）方法，若父加载器为空则默认使用启动类加载器作为父加载器。
如果父类加载失败，抛出ClassNotFoundException异常后，再调用自己的findClass（）方法进行加载。

以下为ClassLoader中的代码：

// 父类加载器
private final ClassLoader parent;
protected Class<?> loadClass(String name, boolean resolve)
    throws ClassNotFoundException
{
    synchronized (getClassLoadingLock(name)) {
        // First, check if the class has already been loaded
        // 首先检查是否已经加载了该类
        Class<?> c = findLoadedClass(name);
        if (c == null) {
            long t0 = System.nanoTime();
            try {
                // 父类加载器加载，如果父类加载器为空，使用最顶级的Bootstrap类加载器来加载
                if (parent != null) {
                    c = parent.loadClass(name, false);
                } else {
                    c = findBootstrapClassOrNull(name);
                }
            } catch (ClassNotFoundException e) {
                // ClassNotFoundException thrown if class not found
                // from the non-null parent class loader
            }

            if (c == null) {
                // If still not found, then invoke findClass in order
                // to find the class.
                // 如果以上步骤还没找到类，就按照自己定义的类加载器中重写的findClass方法加载------》子类自己来加载
                long t1 = System.nanoTime();
                c = findClass(name);
                // this is the defining class loader; record the stats
                sun.misc.PerfCounter.getParentDelegationTime().addTime(t1 - t0);
                sun.misc.PerfCounter.getFindClassTime().addElapsedTimeFrom(t1);
                sun.misc.PerfCounter.getFindClasses().increment();
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
}