类的加载总结

类的加载定义:

类的加载其实就是将.class文件加载到jvm虚拟机的内存中,在jvm中并不是一次性把所有的文件都加载到,二十一步一步的,按照是否需要进行加载.
jvm启动时会通过不同的类加载器加载不同的类,而且同一个类也不可能由多个加载器来进行加载,正是由于这种分解加载策略,才能保证各个类在jvm中有条不紊的运行.

我们下面放上一张图来标示一下jvm的大体分布:

我们再简化一下上面的定义:

Java虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的加载机制。

下面再引入一张图:

我们可以从图中大概看出来当类被加载到虚拟机内存中开始至卸载出内存结束,他的生命周期历程.
加载（Loading）->(验证（Verification）、准备（Preparation）、解析（Resolution）)->初始化（Initialization）->使用（using）->和卸载（Unloading）七个阶段。其中验证、准备和解析三个部分统称为连接（Linking）.

下面我们先来看一下类加载器之间有什么关系?

说到类加载器之间的关系,不得不说一个机制:父类委托机制.

那么什么叫做父类委托机制呢? (每一个加载器都有用一个范围进行加载)

我们从图中可以看出,一共有四个类加载器,我们可以这么理解,当我们作为用户自定义加载某些类时,用户加载器并不进行加载,而是委托给他的父级加载器appclassloader进行加载,但是由于父类委托机制的存在,appclassloader委托给他的父类extclassloader进行加载,但是extclassloader也很懒,委托给他的父级bootstrapclassloader进行加载.终于到顶层了,此时顶级加载类在他的范围内进行加载,如果此时没有找到需要加载的类,那么会让他的子类extclassloader进行加载,如上如果还是没有加载那么会让他的子类appclassloader加载,如上,便会让他的子类customclassloader加载,如果此时customclassloader加载不了,便会抛出异常:classnotfound异常

按照这个流程:如果同样在classpath指定的目录中和自己工作目录中存放相同的class,会优先加载classpath目录中的文件

下面我们讲述一下类加载到jvm后的生命周期

1 加载

我们还是抠定义:
类的加载指的是将类的.class文件中的二进制数据读入到内存中,并将其放在运行时数据区的方法区内,然后在堆区创建一个java.lang.class对象,用来封装类在方法区内的数据结构,类的加载的最终产品是位于堆区中的class对象,class对象封装了类在方法区内的数据结构,并且向java程序员提供了访问方法区的数据结构的接口.
类加载器并不需要等到某个类 被"首次加载"时再加载他,jvm规范允许类加载器在预料某个类将要被使用时就预先加载它,如果在预先加载的过程中遇到了.class文件缺失或存在错误,类加载器就必须第一次使用该类时进行错误提示,如果这个类一直没有被程序使用,那么类加载器就一直不会报错.
加载.class文件的方式:

1. 从本地系统中直接加载
2. 通过网络下载.class文件
3. 从zip，jar等归档文件中加载.class文件
4. 从专有数据库中提取.class文件
5. 将Java源文件动态编译为.class文件

那我们来看一下类加载过程中jvm做了什么,那么此时的虚拟机需要做下面的几件事情:

1.通过一个类的全限定名称来获取定义此类的二进制字节流。 

2.将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。 

3.在java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口。 

由于我们可以自定义用户加载类,所以类加载期可控性还是比较强的~

2 验证

当类被jvm加载后,还会机型一次验证,目的是验证该类是否会危害虚拟机自身的安全,不同的虚拟机对类验证的实现可能会有所不同,但大致都会完成四个阶段的验证:

 1）文件格式的验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区之内。经过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。 

 2）元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。 

 3）字节码验证：该阶段验证的主要工作是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会做出危害虚拟机安全的行为。 

 4）符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。 

3 准备

准备阶段其实就是为了把类中的变量进行内存的分配,并且进行类变量初始值的设置阶段,这些内存都是在方法区中进行分配

1）这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。 

2）这里所设置的初始值通常情况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予的值。

4 解析

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

符号引用（Symbolic Reference）：符号引用以一组符号来描述所引用的目标，符号引用可以是任何形式的字面量，符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经在内存中。 

直接引用（Direct Reference） ：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般都不相同，如果有了直接引用，那引用的目标必定已经在内存中存在。 

1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。 
2、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束。 

3、类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。 

4、接口方法解析：与类方法解析步骤类似，只是接口不会有父类，因此，只递归向上搜索父接口就行了。 

5 初始化

在java中对类变量进行初始化值设定有下面两种方式:

①声明类变量时指定初始值

②使用静态代码块为类变量指定初始值

jvm初始化步骤:

1、假如这个类还没有被加载和连接，则程序先加载并连接该类

2、假如该类的直接父类还没有被初始化，则先初始化其直接父类

3、假如类中有初始化语句，则系统依次执行这些初始化语句

初始化阶段时执行类构造器()方法的过程

1）<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序所决定。 

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

3）由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。 

4）<clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。 
5）接口中可能会有变量赋值操作，因此接口也会生成<clinit>()方法。但是接口与类不同，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也不会执行接口的<clinit>()方法。 
6）虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步。如果有多个线程去同时初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其它线程都需要阻塞等待，直到活动线程执行<clinit>()方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，那么就可能造成多个进程阻塞。

类初始化的触发条件:只有对当类的主动使用的时候才会导致类的初始化

(1)遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候，读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

(2) 使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。

(3) 当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

(4) 当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。

只有上面的四种情况会触发初始化
但是也可以进行简化

(1) 创建类的实例，也就是new的方式

(2) 访问某个类或接口的静态变量，或者对该静态变量赋值

(3) 调用类的静态方法

(4) 反射（如Class.forName(“com.shengsiyuan.Test”)）

(5) 初始化某个类的子类，则其父类也会被初始化

(6) Java虚拟机启动时被标明为启动类的类（Java Test），直接使用java.exe命令来运行某个主类

那么什么时候会结束生命周期呢?

1. 执行了System.exit()方法 
2. 程序正常执行结束 
3. 程序在执行过程中遇到了异常或错误而异常终止 
4. 由于操作系统出现错误而导致Java虚拟机进程终止

下面我们进行实际的操作

我们经常会在面试中碰到下面的这种类型的题:

public class demo1 {

    // 静态变量
    public static String staticField = "静态变量-----1-----";

    // 变量
    public String field = "变量-----2-----";

    // 静态代码块
    static {
        System.out.println(staticField);
        System.out.println("静态初始化块-----3-----");
    }

    // 初始化块
    {
        System.out.println(field);
        System.out.println("初始化块-----4-----");
    }

    // 构造器
    public demo1() {
        System.out.println("构造器-----5-----");
    }

    public static void main(String[] args) {

        new demo1();

    }
}

实际输出结果为:

静态变量-----1-----
静态初始化块-----3-----
变量-----2-----
初始化块-----4-----
构造器-----5-----

上面我们所写的是无继承关系的输出结果顺序:我们可以从中总结出:
无继承的初始化顺序依次是:

(静态变量/静态初始化块)>(变量/初始化块)>构造器

那么对于继承父类后的初始化类顺序呢?

class demo2 {
    // 静态变量

    public static String p_StaticField = "父类--静态变量";

    // 变量

    public String p_Field = "父类--变量";

    // 静态初始化块

    static {
        System.out.println(p_StaticField);
        System.out.println("父类--静态初始化块");
    }

    // 初始化块

    {
        System.out.println(p_Field);
        System.out.println("父类--初始化块");
    }

    // 构造器

    public demo2() {
        System.out.println("父类--构造器");
    }
}

class SubClass extends demo2 {

    // 静态变量

    public static String s_StaticField = "子类--静态变量";

    // 变量

    public String s_Field = "子类--变量";
    // 静态初始化块

    static {
        System.out.println(s_StaticField);
        System.out.println("子类--静态初始化块");
    }
    // 初始化块

    {
        System.out.println(s_Field);
        System.out.println("子类--初始化块");
    }

    // 构造器

    public SubClass() {
        System.out.println("子类--构造器");
    }

    // 程序入口

    public static void main(String[] args) {

        new SubClass();
    }
}

下面为输出结果:

父类--静态变量
父类--静态初始化块
子类--静态变量
子类--静态初始化块
父类--变量
父类--初始化块
父类--构造器
子类--变量
子类--初始化块
子类--构造器

现在，结果已经不言自明了。大家可能会注意到一点，那就是，并不是父类完全初始化完毕后才进行子类的初始化，实际上子类的静态变量和静态初始化块的初始化是在父类的变量、初始化块和构造器初始化之前就完成了。

那么对于静态变量和静态初始化块之间、变量和初始化块之间的先后顺序又是怎样呢？是否静态变量总是先于静态初始化块，变量总是先于初始化块就被初始化了呢？实际上这取决于它们在类中出现的先后顺序。我们以静态变量和静态初始化块为例来进行说明。

我们接下来在进行分析:

public class demo3 {
    // 静态变量

    public static TestA a = new TestA();


    // 静态初始化块

    static {
        System.out.println("静态初始化块");
    }

    // 静态变量

    public static TestB b = new TestB();


    public static void main(String[] args) {

        new demo3();
    }
}

class TestA {
    public TestA() {
        System.out.println("Test--A");
    }
}

class TestB {
    public TestB() {
        System.out.println("Test--B");
    }
}

下面为输出顺序:

Test--A
静态初始化块
Test--B

大家可以随意改变变量a、变量b以及静态初始化块的前后位置，就会发现输出结果随着它们在类中出现的前后顺序而改变，这就说明静态变量和静态初始化块是依照他们在类中的定义顺序进行初始化的。同样，变量和初始化块也遵循这个规律。