理解JVM（四）：JVM类加载机制

时间 2019-11-30

标签理解 jvm 加载机制栏目 Java 繁體版

原文原文链接

Class文件

咱们写的Java代码，通过编译器编译以后，就成为了.class文件，从本地机器码变成了字节码。Class文件是一组以8位字节为基础单位的二进制流，各个数据项目严格按照顺序紧凑地排列在Class文件之中，中间没有添加任何分隔符，这使得整个Class文件中存储的内容几乎所有是程序运行的必要数据，没有空隙存在。Class文件中只有2种数据结构：无符号数和表。html

每一个Class文件的头4个字节称为魔数（Magic Number），值为0xCAFEBABE。紧接着4个字节是Class文件的版本号。再日后，就是类的具体信息了，好比常量池、类索引、父类索引、接口索引、字段、方法等信息了。java

所谓类的加载，就是把Class文件读到内存中。mysql

类的生命周期

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。其中验证、准备、解析3个部分统称为链接（Linking）。

加载、验证、准备、初始化和卸载这5个阶段的顺序是肯定的，类的加载过程必须按照这种顺序循序渐进地开始，而解析阶段则不必定：它在某些状况下能够在初始化阶段以后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。注意，是循序渐进地“开始”，而不是循序渐进地“进行”或“完成”，强调这点是由于这些阶段一般都是互相交叉地混合式进行的，一般会在一个阶段执行的过程当中调用、激活另一个阶段。sql

加载

在加载阶段，虚拟机作3件事：缓存

经过一个类的全限定名来获取定义此类的二进制字节流。
将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构。
在内存中生成一个表明这个类的java.lang.Class对象，做为方法区这个类的各类数据的访问入口。

验证

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

验证阶段大体上会完成4个阶段的检验动做数据结构

文件格式验证：验证字节流是否符合Class文件格式的规范，而且能被当前版本的虚拟机处理。好比是否以魔数0xCAFEBABE开头，主、次版本号是否能被当前虚拟机处理，常量类型，指向常量的索引是否符合要求等。这阶段的验证是基于二进制字节流进行的，只有经过了这个阶段的验证后，字节流才会进入内存的方法区中进行存储，因此后面的3个验证阶段所有是基于方法区的存储结构进行的，不会再直接操做字节流。
元数据验证：对字节码描述的信息进行语义分析，以保证其描述的信息符合Java语言规范的要求。好比继承关系。
字节码验证：对类的方法体进行校验分析，保证被校验类的方法在运行时不会作出危害虚拟机安全的事件。经过数据流和控制流分析，肯定程序语义是合法的、符合逻辑的。
符号引用验证：对类自身之外（常量池中的各类符号引用）的信息进行匹配性校验，确保解析动做能正常执行。它发生在虚拟机将符号引用转化为直接引用的时候，这个转化动做将在链接的第三阶段——解析阶段中发生。

验证阶段是很是重要的，但不是必须的。它对程序运行期没有影响，若是所引用的类通过反复验证，那么能够考虑采用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。多线程

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中有两个容易产生混淆的概念须要强调一下，首先，这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一块儿分配在Java堆中。其次，这里所说的初始值“一般状况”下是数据类型的零值。jvm

假设一个类变量的定义为：public static int value = 123;源码分析

那变量value在准备阶段事后的初始值为0而不是123，由于这时候还没有开始执行任何Java 方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器＜clinit＞()方法之中，因此把value赋值为123的动做将在初始化阶段才会执行。

固然也有特殊状况：若是类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值。

假设上面类变量value的定义变为：public static final int value = 123;

编译时Javac将会为value生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动做主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标便可。符号引用与虚拟机实现的内存布局无关，引用的目标并不必定已经加载到内存中。各类虚拟机实现的内存布局能够各不相同，可是它们能接受的符号引用必须都是一致的，由于符号引用的字面量形式明肯定义在Java虚拟机规范的Class文件格式中。
直接引用（Direct References）：直接引用能够是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不一样虚拟机实例上翻译出来的直接引用通常不会相同。若是有了直接引用，那引用的目标一定已经在内存中存在。

初始化

这一步开始执行类中定义的Java程序代码（或者说是字节码）。虚拟机会保证一个类的初始化方法在多线程环境中被正确地加锁、同步，若是多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的初始化方法，其余线程都须要阻塞等待，直到活动线程执行完毕。

JVM初始化步骤

假如这个类尚未被加载和链接，则程序先加载并链接该类
假如该类的直接父类尚未被初始化，则先初始化其直接父类
假如类中有初始化语句，则系统依次执行这些初始化语句

类初始化时机

只有当主动使用一个类的时候才会触发这个类的初始化，类的主动使用包括如下六种：

建立类的实例，也就是new的方式
访问某个类或接口的静态变量，或者对该静态变量赋值
调用类的静态方法
反射，好比Class.forName("com.mysql.jdbc.Driver")
初始化某个类的子类，则其父类也会被初始化
Java虚拟机启动时被标明为启动类的类（Java Test），直接使用java.exe命令来运行某个主类

类加载器

虚拟机设计团队把类加载阶段中的“经过一个类的全限定名来获取描述此类的二进制字节流”这个动做放到Java虚拟机外部去实现，以便让应用程序本身决定如何去获取所须要的类。实现这个动做的代码模块称为“类加载器”。

双亲委派模型

从Java虚拟机的角度来说，只存在两种不一样的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现，是虚拟机自身的一部分；另外一种就是全部其余的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，而且全都继承自抽象类java.lang.ClassLoader。

从Java开发人员的角度来看，类加载器能够划分为如下3种：

启动类加载器（Bootstrap ClassLoader）：负责加载存放在JAVA_HOME\lib目录中的，或被-Xbootclasspath参数指定的路径中的，而且能被虚拟机识别的类库（如rt.jar，全部的java.开头的类均被Bootstrap ClassLoader加载）。启动类加载器是没法被Java程序直接引用的。
扩展类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载JAVA_HOME\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的全部类库，开发者能够直接使用扩展类加载器。
应用程序类加载器（Application ClassLoader）：该类加载器由sun.misc.Launcher$AppClassLoader来实现，它负责加载用户类路径（ClassPath）所指定的类，开发者能够直接使用该类加载器，若是应用程序中没有自定义过本身的类加载器，通常状况下这个就是程序中默认的类加载器。

咱们的应用程序都是由这3种类加载器互相配合进行加载的，若是有必要，还能够加入本身定义的类加载器。

双亲委派模型要求除了顶层的启动类加载器外，其他的类加载器都应当有本身的父类加载器。这里类加载器之间的父子关系通常不会以继承的关系来实现，而是都使用组合关系来复用父加载器的代码。它不是强制性的约束模型，而是Java设计者推荐的一种类加载器实现方式。

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

ClassLoader源码分析：

public Class<?> loadClass(String name) throws ClassNotFoundException {
        return loadClass(name, false);
}

protected synchronized Class<?> loadClass(String name, boolean resolve) throws ClassNotFoundException {
        // 首先判断该类型是否已经被加载
        Class c = findLoadedClass(name);
        if (c == null) {
            //若是没有被加载，就委托给父类加载或者委派给启动类加载器加载
            try {
                if (parent != null) {
                     //若是存在父类加载器，就委派给父类加载器加载
                    c = parent.loadClass(name, false);
                } else {
                    //若是不存在父类加载器，就检查是不是由启动类加载器加载的类，经过调用本地方法native Class findBootstrapClass(String name)
                    c = findBootstrapClass0(name);
                }
            } catch (ClassNotFoundException e) {
                // 若是父类加载器和启动类加载器都不能完成加载任务，才调用自身的加载功能
                c = findClass(name);
            }
        }
        if (resolve) {
            resolveClass(c);
        }
        return c;
    }
复制代码

经过分析源码，咱们知道，双亲委派模型能够保证每一个类都只会被加载一次（相似缓存机制）。

参考

《深刻理解Java虚拟机第二版》
纯洁的微笑