一、概述

前面的一个章节说了Class文件存储文件的具体细节，但是Class文件描述的各种信息，最终都是需要加载到虚拟机中之后才能运行和使用，本章节就来看看虚拟机是如何加载这些Class文件？以及Class文件中的信息进入虚拟机后会发生什么变化？

类加载机制就是虚拟机把描述类的数据从Class文件加载到内存，并对数据进行校验，转换解析和初始化，最终形成可以被虚拟机直接使用的java类型。与那些编译时需要连接工作的语言不同的是，java语言类型的加载、连接和初始化过程都是在程序运行期间完成的，虽然有部分开销，但是提供运行期间动态扩展，从最基础的Applet、JSP到相对复杂的OSGi技术都是利用了这个特性。

类从被加载虚拟机中开始到卸载出内存为止，整个生命周期包括：加载、验证、准备、解析、初始化、使用和卸载7个阶段，其中的验证、准备、解析统称为连接，解析的顺序也不一定是这样，也有可能是初始化之后再进行，主要是为了支持java语言的运行时绑定。

什么时候加载可以交给虚拟机的具体实现来自由把握，但是对于初始化阶段，有且只有下面的几种情况必须立即对类进行初始化：

1. 遇到new、getstatic、putstatic、invokestatic这4条字节指令时，如果类没有初始化，需要先触发其初始化
2. 使用java.lang.reflect包中的方法对类进行反射调用的时候
3. 初始化一个类，发现其父类没有初始化，先初始化其父类
4. 当虚拟机启动时，用户需要指定一个执行的主类（包含main方法），虚拟机会先初始化这个主类
5. 当时使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄对应的类没有进行初始化，需要先初始化

其实上面所说的5种场景的行为是对一个类进行主动引用，除此之外，所有引用类的方式都不会触发初始化，成为被动引用，通过代码演示被动引用的三种情况：

/**
 * 被动引用演示1
 * 通过子类引用父类的静态字段，不会导致子类的初始书化
 */
public class FatherClass {
    static {
        System.out.println("FatherClass init!");
    }
    public static int value = 100;
}

public class SonClass extends FatherClass {
    static {
        System.out.println("SonClass init!");
    }
}

public class Demo2 {
    public static void main(String[] args) {
        System.out.println(SonClass.value);
    }
}

结果展示：
FatherClass init!
100

Process finished with exit code 0


/**
 * 被动引用演示2
 * 通过数组定义来引用类，不会触发此类的初始化
 */
public class Demo2 {
    public static void main(String[] args) {
        FatherClass[] father =new FatherClass[10];
    }
}

结果展示：

Process finished with exit code 0

/**
 * 被动引用演示3
 * 常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用在定义常量的类，因此不会触发定义常量的类的初始化
 */
public class Demo {

    static {
        System.out.println("Demo hello!");
    }

    public static final String HELLO = "hello";
}

public class Demo2 {
    public static void main(String[] args) {
        System.out.println(Demo.HELLO);
    }
}

结果展示：
hello

Process finished with exit code 0

二、类加载过程

1.加载：在加载阶段虚拟机需要完成以下三件事

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

2.验证：连接阶段的第一步，为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。验证阶段其实是非常重要的，这个阶段是否严谨，直接决定了java虚拟机是否能承受恶意代码的攻击，从执行性能的角度上来说，验证阶段的工作量在虚拟机的类加载子系统中又占了相当大的一部分，下面具体说说验证哪些东西

• 文件格式验证：验证字节流是否符合Class文件格式的规范，包括魔数、版本号、tag标志等，只有通过了这个的阶段的验证，字节流才会进入内存的方法区中进行存储，所以后面的验证全部是基于方法区的存储结构进行的
• 元数据验证：对字节码描述的信息进行语义分析，保证描述的信息符合java语言规范的要求
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的，符合逻辑的，主要是对方法体进行校验分析，保证被校验类的方法在运行的时候不会做出危害虚拟机安全的事件，，但是从准确度上来说，一个方法即使通过字节码验证也不能说明其一定就是安全的，由于这个阶段的验证非常耗内存耗时间，所以在JDK1.6之后的javac编译器和java虚拟机中进行了一项优化，给方法体的Code属性的属性列表中增加了一项名为“StackMapTable”的属性，这个属性描述了方法体中所有的基本快开始时本地变量表和操作栈应有的状态，在字节码验证期间，就不需要根据程序推导出这些状态的合法性，只需要检查StackMapTable属性中记录是否合法即可，节省了很多时间。当然理论上这个属性也有被篡改的可能性，但是问题不大，并且在JDK1.7之后，对于主版本号大于50的Class文件，都是只能采用这种暗示进行校验
• 符号引用验证：可以看做是对类自身以外（常量池中的各种符合引用）的信息进行匹配性校验，确保解析动作能够正常执行

3.准备：主要是为类变量分配内存并设置类变量初始值，这个类变量（被Static修饰）不包括实例变量（在实例化时随对象一起分配在java堆中），初始值通常情况下是数据类型的零值，但是如果字段属性表中存在ConstantValue属性（被final修饰），就会初始化为ConstantValue属性所指定的值

4.解析：将常量池中的符号引用替换成直接引用的过程。符号引用是以一组来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。解析动作主要是针对类和接口、字段、类方法、接口方法、方法类型、方法句柄和调用限定符7类符号引用进行，分别对应常量池中的7中常量类型。

5.初始化：真正开始执行类中定义的java程序代码（字节码），其实初始化就是执行类构造器<clinit>()方法的过程。

三、类加载器

类加载器可以说是java的一种创新，也是java语言流行的重要原因之一，最初是为了满足 jJava Applet的需求而开发出来的，但是后来却在类层析划分、OSGi、热部署、代码加密等领域大放异彩，成为java体系中的一块重要基石。

1.类与类加载器：对于任意的一个类，都需要由加载他的类加载器和这个类本身一同确定其在java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间，也就是说比较两个类相等，首先需要确定他们是不是由同一个类加载器加载的，然后在比较其他的。这里的相等代表的是Class对象的equals（）方法、isAssignableForm()方法、isInstance（）方法返回的结果

2.双亲委派模型：从java虚拟机的角度来说，只存在两种不同的加载器，一种是启动类加载器，使用C++语言实现，是虚拟机自身的一部分；另一种就是所有其他的类加载器，这些类加载器都是由java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader。其实对于java开发人员来说主要划分为以下三类

• 启动类加载器：负责将存放在<JAVA_HOME>\lib目录中，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的类库加载到虚拟机内存中。
• 扩展类加载器：由sun.misc.Launcher$ExtClassLoader实现，它负责加载<IAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器
• 应用程序类加载器：这个类加载器由sun.misc.Launcher$App-ClassLoader实现，由于这个ClassLoader中的getSystemClassLoader（）方法的返回值，所以一般称他为系统类加载器。

如果以上三种类加载器都能满足你的需求，你可以自己定义类加载器，这些类加载器之间的层次关系我们称为类加载器的双亲委派模型，也就是除了顶层的启动类加载器外，其余的类加载器都应当有自己的父类加载器，这些类加载器之间一般不会以继承的关系来实现，而是使用组合关系来复用父加载器的代码。

双亲委派模型的工作过程：如果一个类加载器收到类加载的请求，他首先不会自己去加载这个类，而是把这个请求委托给父类加载器去加载，每一个层次的加载器都是如此，所以所有的请求最终都应该传递到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求的时候，子类加载器才会尝试自己去加载。

优点：java类随着他的类加载器一起具备了带有优先级的层次关系，保证了java体系中最基础的行为，程序稳定运行。

3.破坏双亲委派模型：上面的双亲委派模型并不是一个强制性的约束模型，而是java设计者推荐给开发者的类加载器实现方式，历史总共出现过三次大规模的破坏

• 双亲委派模式是在java1.2之后才被引入的，为了向前兼容1.0版本，在java.lang.ClassLoader添加了一个新的protected方法findClass（）
• 外部服务的整合，如JDNI服务接口，为了让启动启动类认识这些代码，引入线程上下文加载器
• 在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为更加复杂的网状结构