【深刻Java虚拟机】一 JVM类加载过程

时间 2019-11-06

标签深刻Java虚拟机 jvm 加载过程栏目 Java 繁體版

原文原文链接

首先Throws（抛出）几个本身学习过程当中一直疑惑的问题：java

一、什么是类加载？何时进行类加载？程序员

二、什么是类初始化？何时进行类初始化？数组

三、何时会为变量分配内存？缓存

四、何时会为变量赋默认初值？何时会为变量赋程序设定的初值？安全

五、类加载器是什么？网络

六、如何编写一个自定义的类加载器？数据结构

首先，在代码编译后，就会生成JVM（Java虚拟机）可以识别的二进制字节流文件（*.class）。而JVM把Class文件中的类描述数据从文件加载到内存，并对数据进行校验、转换解析、初始化，使这些数据最终成为能够被JVM直接使用的Java类型，这个说来简单但实际复杂的过程叫作JVM的类加载机制。多线程

Class文件中的“类”从加载到JVM内存中，到卸载出内存过程有七个生命周期阶段。类加载机制包括了前五个阶段。函数

以下图所示：学习

其中，加载、验证、准备、初始化、卸载的开始顺序是肯定的，注意，只是按顺序开始，进行与结束的顺序并不必定。解析阶段可能在初始化以后开始。

另外，类加载无需等到程序中“首次使用”的时候才开始，JVM预先加载某些类也是被容许的。（类加载的时机）

1、类的加载

咱们日常说的加载大多不是指的类加载机制，只是类加载机制中的第一步加载。在这个阶段，JVM主要完成三件事：

一、经过一个类的全限定名（包名与类名）来获取定义此类的二进制字节流（Class文件）。而获取的方式，能够经过jar包、war包、网络中获取、JSP文件生成等方式。

二、将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构。这里只是转化了数据结构，并未合并数据。（方法区就是用来存放已被加载的类信息，常量，静态变量，编译后的代码的运行时内存区域）

三、在内存中生成一个表明这个类的java.lang.Class对象，做为方法区这个类的各类数据的访问入口。这个Class对象并无规定是在Java堆内存中，它比较特殊，虽为对象，但存放在方法区中。

相对于类加载的其余阶段而言，加载阶段（准确地说，是加载阶段获取类的二进制字节流的动做）是可控性最强的阶段，由于开发人员既可使用系统提供的类加载器来完成加载，也能够自定义本身的类加载器来完成加载。

加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，并且在Java堆中也建立一个java.lang.Class类的对象，这样即可以经过该对象访问方法区中的这些数据。

2、类的链接

类的加载过程后生成了类的java.lang.Class对象，接着会进入链接阶段，链接阶段负责将类的二进制数据合并入JRE（Java运行时环境）中。类的链接大体分三个阶段。

一、验证：验证被加载后的类（Class文件的字节流）是否有正确的结构，类数据是否会符合虚拟机的要求，确保不会危害虚拟机安全。

不一样的虚拟机对类验证的实现可能会有所不一样，但大体都会完成如下四个阶段的验证：文件格式的验证、元数据的验证、字节码验证和符号引用验证。

文件格式的验证：验证字节流是否符合Class文件格式的规范，而且能被当前版本的虚拟机处理，该验证的主要目的是保证输入的字节流能正确地解析并存储于方法区以内。通过该阶段的验证后，字节流才会进入内存的方法区中进行存储，后面的三个验证都是基于方法区的存储结构进行的。
元数据验证：对类的元数据信息进行语义校验（其实就是对类中的各数据类型进行语法校验），保证不存在不符合Java语法规范的元数据信息。
字节码验证：该阶段验证的主要工做是进行数据流和控制流分析，对类的方法体进行校验分析，以保证被校验的类的方法在运行时不会作出危害虚拟机安全的行为。
符号引用验证：这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身之外的信息（常量池中的各类符号引用）进行匹配性的校验。

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

这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在Java堆中。
这里所设置的初始值一般状况下是数据类型默认的零值（如0、0L、null、false等），而不是被在Java代码中被显式地赋予。

如static int a = 100; 静态变量a就会在准备阶段被赋默认值0。另外，静态常量（static final filed）会在准备阶段赋程序设定的初值，如static final int a = 666; 静态常量a就会在准备阶段被直接赋值为666，对于静态变量，这个操做是在初始化阶段进行的。

下面列出java基本类型和引用类型的默认值：

这里还须要注意以下几点：

对基本数据类型来讲，对于类变量（static）和全局变量，若是不显式地对其赋值而直接使用，则系统会为其赋予默认的零值，而对于局部变量来讲，在使用前必须显式地为其赋值，不然编译时不经过。
对于同时被static和final修饰的常量，必须在声明的时候就为其显式地赋值，不然编译时不经过；而只被final修饰的常量则既能够在声明时显式地为其赋值，也能够在类初始化时显式地为其赋值，总之，在使用前必须为其显式地赋值，系统不会为其赋予默认零值。
对于引用数据类型reference来讲，如数组引用、对象引用等，若是没有对其进行显式地赋值而直接使用，系统都会为其赋予默认的零值，即null。
若是在数组初始化时没有对数组中的各元素赋值，那么其中的元素将根据对应的数据类型而被赋予默认的零值。

三、解析：将类的二进制数据中的符号引用换为直接引用。

解析阶段是虚拟机将常量池中的符号引用转化为直接引用的过程。在 Class类文件结构一文中已经比较过了符号引用和直接引用的区别和关联，这里再也不赘述。前面说解析阶段可能开始于初始化以前，也可能在初始化以后开始，虚拟机会根据须要来判断，究竟是在类被加载器加载时就对常量池中的符号引用进行解析（初始化以前），仍是等到一个符号引用将要被使用前才去解析它（初始化以后）。

对同一个符号引用进行屡次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动做重复进行。

解析动做主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info四种常量类型。

一、类或接口的解析：判断所要转化成的直接引用是对数组类型，仍是普通的对象类型的引用，从而进行不一样的解析。

二、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，若是有，则查找结束；若是没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，尚未，则按照继承关系从上往下递归搜索其父类，直至查找结束，查找流程以下图所示：

3、类的初始化

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的Java程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员经过程序指定的主观计划去初始化类变量和其余资源，或者能够从另外一个角度来表达：初始化阶段是执行类构造器<clinit>()方法的过程。

这里简单说明下<clinit>（）方法的执行规则:

一、<clinit>（）方法是由编译器自动收集类中的全部类变量的赋值动做和静态语句块中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块以前的变量，定义在它以后的变量，在前面的静态语句中能够赋值，可是不能访问。

二、<clinit>（）方法与实例构造器<init>（）方法（类的构造函数）不一样，它不须要显式地调用父类构造器，虚拟机会保证在子类的<clinit>（）方法执行以前，父类的<clinit>（）方法已经执行完毕。所以，在虚拟机中第一个被执行的<clinit>（）方法的类确定是java.lang.Object。

三、<clinit>（）方法对于类或接口来讲并非必须的，若是一个类中没有静态语句块，也没有对类变量的赋值操做，那么编译器能够不为这个类生成<clinit>（）方法。

四、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操做，所以接口与类同样会生成<clinit>（）方法。可是接口鱼类不一样的是：执行接口的<clinit>（）方法不须要先执行父接口的<clinit>（）方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也同样不会执行接口的<clinit>（）方法。

五、虚拟机会保证一个类的<clinit>（）方法在多线程环境中被正确地加锁和同步，若是多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>（）方法，其余线程都须要阻塞等待，直到活动线程执行<clinit>（）方法完毕。若是在一个类的<clinit>（）方法中有耗时很长的操做，那就可能形成多个线程阻塞，在实际应用中这种阻塞每每是很隐蔽的。

如下几种状况不会执行类初始化：

经过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
定义对象数组，不会触发该类的初始化。
常量在编译期间会存入调用类的常量池中，本质上并无直接引用定义常量的类，不会触发定义常量所在的类。
经过类名获取Class对象，不会触发类的初始化。
经过Class.forName加载指定类时，若是指定参数initialize为false时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
经过ClassLoader默认的loadClass方法，也不会触发初始化的动做。

下面给出一个简单的例子，以便更清晰地说明如上规则：

class Father{
    public static int a = 1;
    static{
        a = 2;
    }
}

class Child extends Father{
    public static int b = a;
}

public class ClinitTest{
    public static void main(String[] args){
        System.out.println(Child.b);
    }
}

执行上面的代码，会打印出2，也就是说b的值被赋为了2。

咱们来看获得该结果的步骤。首先在准备阶段为类变量分配内存并设置类变量初始值，这样A和B均被赋值为默认值0，然后再在调用<clinit>（）方法时给他们赋予程序中指定的值。当咱们调用Child.b时，触发Child的<clinit>（）方法，根据规则2，在此以前，要先执行完其父类Father的<clinit>（）方法，又根据规则1，在执行<clinit>（）方法时，须要按static语句或static变量赋值操做等在代码中出现的顺序来执行相关的static语句，所以当触发执行Father的<clinit>（）方法时，会先将a赋值为1，再执行static语句块中语句，将a赋值为2，然后再执行Child类的<clinit>（）方法，这样便会将b的赋值为2.

若是咱们颠倒一下Father类中“public static int a = 1;”语句和“static语句块”的顺序，程序执行后，则会打印出1。很明显是根据规则1，执行Father的<clinit>（）方法时，根据顺序先执行了static语句块中的内容，后执行了“public static int a = 1;”语句。

另外，在颠倒两者的顺序以后，若是在static语句块中对a进行访问（好比将a赋给某个变量），在编译时将会报错，由于根据规则1，它只能对a进行赋值，而不能访问。

被动引用的例子一：

经过子类引用父类的静态字段，对于父类属于“主动引用”的第一种状况，对于子类，没有符合“主动引用”的状况，故子类不会进行初始化。代码以下：

//父类

public class SuperClass {  
    //静态变量value  
    public static int value = 666;  
    //静态块，父类初始化时会调用  
    static{  
        System.out.println("父类初始化！");  
    }  
}  
  
//子类  
public class SubClass extends SuperClass{  
    //静态块，子类初始化时会调用  
    static{  
        System.out.println("子类初始化！");  
    }  
}  
  
//主类、测试类  
public class NotInit {  
    public static void main(String[] args){  
        System.out.println(SubClass.value);  
    }  
}

被动引用的例子之二：

经过数组来引用类，不会触发类的初始化，由于是数组new，而类没有被new，因此没有触发任何“主动引用”条款，属于“被动引用”。代码以下：

//父类
public class SuperClass {
    //静态变量value
    public static int value = 666;
    //静态块，父类初始化时会调用
    static{
        System.out.println("父类初始化！");
    }
}

//主类、测试类
public class NotInit {
    public static void main(String[] args){
        SuperClass[] test = new SuperClass[10];
    }
}

没有任何结果输出！

被动引用的例子之三：

刚刚讲解时也提到，静态常量在编译阶段就会被存入调用类的常量池中，不会引用到定义常量的类，这是一个特例，须要特别记忆，不会触发类的初始化！

//常量类
public class ConstClass {
    static{
        System.out.println("常量类初始化！");
    }
    
    public static final String HELLOWORLD = "hello world!";
}

//主类、测试类
public class NotInit {
    public static void main(String[] args){
        System.out.println(ConstClass.HELLOWORLD);
    }
}

输出：hello world

总结

整个类加载过程当中，除了在加载阶段用户应用程序能够自定义类加载器参与以外，其他全部的动做彻底由虚拟机主导和控制。到了初始化才开始执行类中定义的Java程序代码（亦及字节码），但这里的执行代码只是个开端，它仅限于<clinit>（）方法。类加载过程当中主要是将Class文件（准确地讲，应该是类的二进制字节流）加载到虚拟机内存中，真正执行字节码的操做，在加载完成后才真正开始。

【深刻Java虚拟机】之四：类加载机制： https://blog.csdn.net/ns_code/article/details/17881581

【类的初始化】: https://blog.csdn.net/ns_code/article/details/17845821

【深刻java虚拟机专栏】：https://blog.csdn.net/ns_code/article/category/1823903

【JVM类加载机制详解（一）JVM类加载过程]】https://blog.csdn.net/zhangliangzi/article/details/51319033