Java类加载

最新推荐文章于 2023-12-03 23:13:49 发布

我是128位的

最新推荐文章于 2023-12-03 23:13:49 发布

阅读量243

点赞数

文章标签： java jvm

本文链接：https://blog.csdn.net/qq_44971346/article/details/128191289

版权

JVM 类加载过程

先来看一张图——可以将类加载分为如下图的几个阶段

一个类型从加载到虚拟机内存开始，到卸载出内存为止，它的整个生命周期可分为以下的阶段：加载、验证、准备、解析、初始化、使用、卸载七个阶段。其中验证、准备、解析三个阶段被称为连接阶段，这7个阶段发生的顺序如上图所示。

首先回忆一下，通过命令行如何编译并运行一个Hello.java文件？

#第一步：编译
javac Hello.java
#第二步：
#编译完成生成一个Hello.class的字节码文件,字节码文件需要加载到JVM虚拟机
#中才能够允许，而加载到虚拟机的这个过程，其实就是一个类加载的过程
java Hello

#也即在执行上述的java Hello 命令时，便经过了JVM类加载的过程

类加载机制的定义？

答：JVM把描述类的数据从一个class文件中读取出来，然后加载到内存，并对加载到内存中的数据进行校验、转换、解析和初始化的操作，并最终生成可以被jvm虚拟机直接使用的Java类型，这个过程就叫做虚拟机的类加载机制。
一句话来说就是：把class文件内容按照指定格式识别并放入到Java虚拟机中的过程
什么时候会触发类的加载呢？有如下6种情况（内容摘抄自深入理解Java虚拟机第7章）

当遇到 new getstatic putstatic 或者 invokestatic 这四条字节码指令时,如果对应的类型（类型指的就是类、接口、枚举等）没有进行过初始化，则需要触发其初始化阶段（当然，如果没有经过加载-验证-准备，那么肯定要先经过这些阶段了），可以生成这四条指令的典型Java代码场景有：
- 使用 new 关键字实例化对象
- 读取或设置一个类型的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）
- 调用一个类型的静态方法
  
  如果想要查看字节码指令到底是什么，可以通过对.class文件经过 “javap -verbose class文件名称” 反编译进行查看
使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。
当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
当使用jdk1.7动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokeStatic的方法句柄，并且这个方法句柄所对应的类没有进行初始化，则需要先出触发其初始化。
当一个接口中定义了JDK8新加入的默认方法（被default 关键字修饰的接口方法）时，如果有这个接口的实现类发生了初始化，那该接口要在其之前被初始化。

根据0 和 3 这两个知识点，问你一个问题，父子类之间进行实例化时的顺序？

父类静态代码块–>子类静态代码块–>父类实例化代码块–>父类构造方法–>子类实例化代码块–>子类构造方法

其实可以这样理解：由于继承关系的存在,即使你想要实例化子类，但是子类实质上有可能用到了父类的一些属性内容，为了保证数据的正确性，所以一定要在实例化子类之前先实例化父类的东西，这就是上面黄色部分顺序的原因，前面非黄色的原因是因为那些是处于类加载阶段的内容；

注意：静态代码块只会执行一次，但是后面黄色部分会跟着实例化的次数多次执行
类加载的过程
- 加载阶段是类加载过程中的一个阶段，在加载阶段，虚拟机需要完成以下三件事情：
  
  （1）通过一个类的全限定名（可以理解为绝对路径）来获取其定义的二进制字节流
  
  （2）将这个字节流所代表的的静态存储结构转化为方法区的运行时数据结构
  
  （3）在堆中生成一个代表这个类的Class对象，作为方法区中这些数据的访问入口。
  
  相对于类加载的其他阶段而言，非数组类型的加载阶段（准确来说,是加载阶段中获取类的二进制字节流的动作）是开发人员可控性最强的阶段。加载阶段即可以使用Java虚拟机里内置的引导类加载器完成，也可以使用用户自定义的类加载器完成。（开发人员通过定义自己的类加载器去控制字节流的获取方式，如重写一个类加载器的findClass()或loadClass()方法，这样就可以使得我们的应用程序动态的获取我们想要加载的字节码数据流）。
1. 验证
  
  验证的主要作用就是确保被加载的类的正确性。也是连接阶段的第一步。说白了也就是我们加载好的.class文件不能对我们的虚拟机有危害，所以先检测验证一下。他主要是完成四个阶段的验证：
  
  （1）文件格式的验证：验证.class文件字节流是否符合class文件的格式的规范，并且能够被当前版本的虚拟机处理。这里面主要对魔数、主版本号、常量池等等的校验（魔数、主版本号都是.class文件里面包含的数据信息、在这里可以不用理解）。
  
  （2）元数据验证：主要是对字节码描述的信息进行语义分析，以保证其描述的信息符合java语言规范的要求，比如说验证这个类是不是有父类，类中的字段方法是不是和父类冲突等等。
  
  （3）字节码验证：这是整个验证过程最复杂的阶段，主要是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在元数据验证阶段对数据类型做出验证后，这个阶段主要对类的方法做出分析，保证类的方法在运行时不会做出威海虚拟机安全的事。
  
  （4）符号引用验证：它是验证的最后一个阶段，发生在虚拟机将符号引用转化为直接引用的时候。主要是对类自身以外的信息进行校验。目的是确保解析动作能够完成。
  
  对整个类加载机制而言，验证阶段是一个很重要但是非必需的阶段，如果我们的代码能够确保没有问题，那么我们就没有必要去验证，毕竟验证需要花费一定的的时间。当然我们可以使用-Xverfity:none来关闭大部分的验证。
- 准备：
  
  为类变量分配内存，并将其初始化为默认值。（此时为默认值，在初始化的时候才会给变量赋值）即在方法区中分配这些变量所使用的内存空间。例如
```
public static int value = 123;
此时在准备阶段过后的初始值为0而不是123``；
特例：
public static final int value = 123;
此时value的值在准备阶段过后就是123。
```
- 解析：
  - 解析阶段将类中符号引用转换为直接引用。符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标即可。
- 初始化：
  - ==初始化阶段是执行类构造器方法的过程。方法是由编译器自动收集类中的类变量的赋值操作和静态语句块中的语句合并而成的。(注意这段话：编译器在收集时，也是按照变量在代码中本身所处的行数进行收集的，也即如果定义时行数靠前，收集后的静态代码块中，该行也是靠前的，这也是为什么6这个模块提出问题时为什么会有那种输出的原因)==虚拟机会保证方法执行之前，父类的方法已经执行完毕。如果一个类中没有对静态变量赋值也没有静态语句块，那么编译器可以不为这个类生成()方法。
  - 既然有clinit收集，那么肯定也会有init构造器的收集，init会自动收集类中的所有非静态变量，也即它会收集所有的实例变量，并生成一个代码块，该代码块会在每次调用构造方法前都调用一次（因为该代码块收集的就是初始化的实力变量，所以每次调用构造方法前该init代码块部分都会执行一次了，这也是4那块出现的原因）
  - JVM初始化步骤
    - 1、假如这个类还没有被加载和连接，则程序先加载并连接该类
    - 2、假如该类的直接父类还没有被初始化，则先初始化其直接父类
    - 3、假如类中有初始化语句，则系统依次执行这些初始化语句

看完以上基础知识后，接下来再看一个问题，如下所示：（注意看6中黄色标注部分的解释）

代码块1

class SingleTon{
    public static int count1;
    public static int count2=0;
    private static SingleTon instance=new SingleTon();
    public SingleTon(){
        count1++;
        count2++;
    }

    public static SingleTon getInstance() {
        return instance;
    }
}
public class JVMTest {
    public static void main(String[] args) {
        SingleTon.getInstance();
        System.out.println(SingleTon.count1);
        System.out.println(SingleTon.count2);
    }
}

代码块2

class SingleTon{
    private static SingleTon instance=new SingleTon();
    public static int count1;
    public static int count2=0;
    public SingleTon(){
        count1++;
        count2++;
    }

    public static SingleTon getInstance() {
        return instance;
    }
}
public class JVMTest {
    public static void main(String[] args) {
        SingleTon.getInstance();
        System.out.println(SingleTon.count1);
        System.out.println(SingleTon.count2);
    }
}

问题：分析代码块1 和代码块2分别输出什么内容？（提示：请严格按照类加载的过程分析）

解析：
- 第一种情况：
连接的准备阶段：为静态变量赋值初始值，SingleTon=null,count1=0,count2=0

初始化阶段：从上到下执行赋值操作和静态代码块（cinit 代码块会根据代码中变量的顺序组织初始化的顺序）

1. 静态变量初始化：count1=0,count2=0
　　 2. 创建对象后，对两个值进行递增结果count1=1,count2=1
- 第二种情况：
连接的准备阶段：为静态变量赋值初始值，SingleTon=null,count1=0,count2=0

初始化阶段：从上到下执行赋值操作和静态代码块

1. 先创建对象时，count1=0,count2=0,然后对两个值进行递增count1=1,count2=1
　　2. 然后根据cinit的初始花步骤对count1和count2进行赋值，再赋值count1没变,count2=0，也即count1=1,count2=0

双亲委派机制详解

首先来看看有那些类加载器？
- 引导类加载器（启动类加载器）
  - 这个类加载器负责加载存放在<JAVA_HOME>\lib 目录，或者被 -Xbootclasspath参数所指定的路劲中存放的，而且名字是可以被Java虚拟机识别的类库（如rt.jar tools.jar 等，名字不符合的类库即使放在lib目录下也不会被加载），然后将可以识别到的那些类库加载到虚拟机内存中。
  - 启动类加载器无法被Java程序直接引用，用户在编写自定义类加载器时，如果需要把加载请求委派给引导类加载器去处理，那直接使用null代替即可。如在自定义类加载器时，可以直接设置父类加载器为null，那么在进行改类的加载时，会首先通过引导类加载器去加载类。
- 扩展类加载器
  - 它负责加载<JAVA_HOME>\lib\ext 目录中，或者被java.ext.dirs系统变量所指定的路径中的所有类库。根据扩展类加载器这个名称，就可以推断出这是一种Java系统类库的扩展机制。
- 应用类加载器
  - 应用类加载器是ClassLoader类中的getSystemClassLoader() 方法的返回值，所以有些场合也称它为”系统类加载器“。它负责加载用户类路径（classPath）上的所有类库。开发者可以同样直接在代码中使用这个类加载器。如果应用程序没有定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器了。
- 自定义类加载器
- 线程上下文类加载器 — 这个比较特殊，其也只存在于概念意义上，是为了更好的解决SPI 加载的问题。
  - 线程上下文类加载器可以通过Thread.setContextClassLoaser()方法设置，如果不特殊设置会从父类继承，一般默认使用的是应用程序类加载器。也即一般的话可以认为线程上下文类加载器就是应用类加载器。
思考一个问题，如下？

JDBC在建立于数据库的连接时，JDBC4.0以前还会通过Class.forName(“driver实现类”)先进行类的加载（此时类的加载时通过应用类加载器），然后通过DriverManager.getConnection(“链接名称”) 获取链接；但是现在确是通过DriverManager.getConnection(“”)直接获取链接的，这样的话驱动类又是如何被加载的呢？它又是怎么能被加载到内存中去呢？
- 在JDBC4.0规范以后，开始支持使用spi的方式来注册这个驱动类Driver，具体的做法就是在mysql的jar包中的META-INF/services/java.sql.Driver 文件中指明当前使用的Driver是哪个，然后使用的时候就直接getConnection(”“)就可以了,其实就是在我们调用DriverManager.getConnection(”“)方法时，会触发器静态代码块的执行，该静态代码块内容如下：
- 看上面的三张图片可知，静态代码块实现的功能其实就是到指定目录下找java.sql.Driver文件（这个其实就是上面第二张图最后一行的迭代器进行遍历时的操作），接着找到其中指定的驱动类，并通过指定的类加载器进行加载，而这个指定的类加载器就是最后一张图片所指定的线程上下文类加载器，这是为什么呢？
  
  答：因为DriverManager是rt.jar中的一个类，所以它的加载肯定是 引导类加载器 进行加载的，但是在加载的过程中，它发现该类还需要加载 Driver的实现类（数据库驱动类），但是数据库的驱动类是不能由它加载的呀，那这怎么办，找一个 应用程序类加载器 呗，让这个应用程序类加载器去加载不久可以了。所以就存在了这个线程上下文类加载器，这个类加载器中一般存储的就是我们的 应用程序类加载器 ，所以在此我们可以通过此方法获取得到该类加载器，然后通过该类加载器去加载应用程序类，也即第三方实现的数据库驱动类。
  
  也即：线程上下文类加载器其实就是为了让引导类、扩展类加载器加载的代码中，有办法去加载一些只能由应用类加载器加载的类，这个线程上下文类加载器的存在使得SPI机制的实现成为了现实。（其实就是线程上下文类加载器中保存了一个加载器变量，使得从引导类加载器-》扩展类加载器=》应用类加载器这个链路中的任意一个步骤都可以取出这个变量进行类的加载，而SPI处这个变量设置的值其实就是一般的应用类加载器，这样的话就可以正常的加载数据库引擎类了）