JVM的类加载机制《简要概述》

一、什么是类加载

        类加载机制就是Java虚拟机把字节码文件中的描述类数据加载到内存中，然后对数据进行校验，转换解析，最后形成可以被虚拟机直接使用的Java类的过程。

说到类加载就不得不提到类的生命周期。

二、类的生命周期

类的生命周期（七个阶段）：

①加载，②验证，③准备，④解析，⑤初始化，⑥使用，⑦卸载

而在加载，验证，准备，初始化和卸载这五个阶段的前后顺序基本是确定的，但是解析的阶段在某些情况下，是可以在初始化阶段之后的。

而类加载分三步：加载、连接、初始化。

1、加载

（1）在加载阶段，虚拟机的三点要求：

1）通过一个类的全限定名来获取到定义该类的二进制字节流；

2）将该字节流所代表的静态存储结构转化成方法区的运行时数据结构；

3）在内存中生成一个代表这个类的java.lang.Class对象作为方法区这个类的各种数据访问入口。

上面虚拟机规范的这三点要求，并没有规定了一定要去哪里获取二进制字节码流，虚拟机可以从运行时计算生成（动态代理技术）中获取，也可以由其他文件生成（jsp应用）等等，灵活度比较大。

【补充】

①class文件并不一定要求就是Java源码编译而来的。

②验证，准备，解析三个部分又习惯性地统称连接阶段。

③加载和连接的部分内容是可以交叉进行的，加载尚未完成，连接阶段可能已经开始（如部分字节码文件格式的验证）。

④加载的类加载过程的第一个阶段，但虚拟机规范没有对此进行强制约束。

（2）类加载器分类

1）从虚拟机的角度，只有两种类加载器：

①启动类加载器（Bootstrap Classloader）：使用c/c++语言实现，是虚拟机自身的一部分。

②其他类加载器：是除了启动类加载器之外的其他类加载器，由Java语言实现，继承于java.lang.ClassLoader，独立于是虚拟机外部。

2）在实际开发中，会把类加载器分得更细一点：

①启动类加载器（Bootstrap ClassLoader）：负责将存在于<JAVA_HOME>\lib目录中，或者配置参数-Xbootclasspath参数指定的路径中，并且能够被虚拟机识别（名字不符合的，就算放在了lib中也不会被夹在）的类库加载到虚拟机内存中。该类加载器无法被java程序直接引用。

②扩展类加载器（Extension ClassLoader）： 这个加载器由sun.miscLauncher$ExtClassLoader实现，负责加载<JAVA_HOME>\lib\ext目录中，或者被java.ext.dirs系统变量所指定的路径中的所有类库。开发者可以直接使用扩展类加载器。

③应用程序类加载器（Application ClassLoader）：这个加载器由sun.misc.Launcher$AppClassLoader实现。也称之为系统类加载器。它负责加载用户类路径（classpath）上所指定的类库，开发者可以直接使用。一般情况下，这个就是程序中默认的类加载器。
 

④自定义的类加载器：除了上面的类加载器，有必要是我们可以加上自定义的类加载器。

对于类的加载，只需加载一次即可。为了保证类只被加载一次，使用了双亲委派。

（3）双亲委派模型

双亲委派模型（Parents Delegation Model）：当父ClassLoader已经加载了该类的时候，子ClassLoader就不会再加载。（这是层次关系而不是继承关系）

双亲委派模型要求，除顶层的启动类加载器外，其他的类加载器都应该有自己的父 类加载器。

工作过程：当一个类加载器收到类加载请求时，它不会先自己去加载这个类，而是把这个请求委派给自己的父 类加载器，层层委派，这时如果父 类加载器决定加载这个类，则这次的加载请求由父 类加载；如果父 类加载器反馈自己不能完成这个加载请求，子 类加载器才会去加载。这是一种有优先级的层级关系，只要父 类加载器能加载，子 类加载器都不会去加载，有效地保证了类只加载一次。

当然，双亲委派模型不是必须遵守的，就像数据库三范式一样，当有必要时，我们可以破坏这一模型，打破双亲委派模型：

1）自定义类加载器，复写loadClass方法

2）使用线程的上下文类加载器对象

2、连接

（1）验证（连接）

验证阶段是为了确保class文件的字节流是符合虚拟机的要求，是安全的。

验证阶段作为连接阶段的第一步，是非常重要的，直接决定了虚拟机能够承受恶意代码的攻击。

在日常开发中，我们也可以看到，如果是纯粹的java源码，代码有问题，在编译时就会报错了，但是class文件并不一定就是java源码编译而来的，载入有害的字节码会导致系统崩溃，所以虚拟机的验证过程是非常有必要的。

但不是一定必要的，如果所运行的代码都已经反复使用和验证过了，那么在正式环境可以考虑使用-Xverify:none参数来关闭大部分的类验证，来缩短虚拟机的类加载的时间。

验证过程主要分四个阶段：①文件格式验证；②元数据验证；③字节码验证；④符号引用验证

1）文件格式验证：

验证字节流是否符合class文件格式的规范，是否能被当前版本的虚拟机处理；

目的是：保证输入的字节流能够在解析阶段可以正确解析并存储到方法区内。

2）元数据验证：

对字节码描述的信息进行语义分析，保证其描述的信息符合Java语言规范；

目的是：保证不会存在不符合Java语言规范的元数据信息。

3）字节码验证：

对类的方法体进行校验

目的是保证类的方法在运行时不会危害虚拟机安全

4）符号引用验证：

在虚拟机将符号引用转化为直接引用的时进行校验（这个转化动作将在解析阶段中发生）；

比如校验符号引用中的全限定名是否能找到对应的类,是否具备访问权限等等；

目的是确保解析动作能正常执行。

（2）准备（连接）

在准备阶段，会为类变量分配内存和设置初始值。

1）类变量所使用的内存都将在方法区中进行分配

2） 但这时进行内存分配的是类变量（static修饰的变量），不包括实例变量，实例变量在对象实例化时随对象一起分配在Java堆中。

3）准备阶段是设置的初始值并不一定就是零值？

在准备阶段为类变量分配设置初始值，一般情况下都是设置数据类型的初始值，

例如：public static int value = 123;

value在准备阶段过后的初始值为0而不是123，而给value赋值的指令将在初始化阶段才会被执行。

而一些特殊情况（static+final），类字段的字段属性表中存在常量属性，在准备阶段就会初始化为指定的值，

例如：public static final int value = 123;

在准备阶段虚拟机就会将value赋值为123。

（3）解析（连接）

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

虚拟机没有规定解析阶段发生的具体时间，只要求了在执行anewarray，checkcast，getfield，getstatic，instanceof，invokedynamic，invokeinterface，nvokespecial，invokestatic，invokevirtual，ldc/ldc_w，multianewarray，new，putfield，putstatic这16个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。

所以解析阶段一般在初始化前，但也可以在初始化之后。

【注】

anewarray：创建数组
checkcast：检查类型
getfield：获取字段
getstatic：获取类变量
instanceof：检查类型
invokedynamic：动态解析方法
invokeinterface：调用接口方法
invokespecial：调用特殊方法，比如构造方法，初始化方法
invokestatic：调用static方法
invokevirtual：调用实例方法
ldc/ldc_w：将int，float，String常量推至栈顶
multianewarray：创建数组
new：创建对象
putfield：设置字段
putstatic：设置类变量

【注】符号引用（Symbolic References）：以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标即可。符号引用与虚拟机的内存布局无关，引用的目标并不一定加载到内存中。在Java中，一个java类将会编译成一个class文件。在编译时，java类并不知道所引用的类的实际地址，因此只能使用符号引用来代替。

【注】直接引用：直接引用是和虚拟机的布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经被加载入内存中了。

3、初始化

初始化阶段真正地开始执行类中定义的Java程序代码。

（1）在初始化阶段，虚拟机规定了以下五种情况必须立即对类进行“初始化”：

1）遇到new指令(使用关键字new来实例化对象)，getstatic，putstatic(读取或设置一个类的静态字段的时候，除了final修饰，在编译时期就已经把结果放在常量池的静态字段)或invokestatic(调用类的静态方法)这4条字节码指令时，如果类没有进行初始化，则需要先触发其初始化。

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

3）当初始化一个类的时候，如果发现其父类还没有进行初始化，则需要先触发其父类的初始化(接口初始化例外，不要求所有父接口全部都初始化，只有在真正调用到父接口的时候才会初始化)。

4）当启动虚拟机时，用户需要指定一个需要执行的主类，虚拟机先初始化这个主类。

5）当使用java7的动态语言支持时，如果一个MethodHandle实例在解析时，该方法对应的类没有进行初始化，则需要先触发其初始化。

上面的五种情况，都是对一个类的主动引用，除此之外都属于被动引用，被动引用都不会触发初始化。被动引用的例子：

1）通过子类引用父类的静态字段，不会导致子类初始化。
2）通过数组定义来引用类，不会触发此类的初始化。
3）常量在编译阶段会存入调用类的常量池中，本质上并没有直接引用到定义常量的类，因此不会触发定义常量的类的初始化。

（2）初始化阶段是执行类构造器<clinit>()方法的过程。

1）类构造器<clinit>()方法是有编译器自动收集类中的所有类变量的赋值动作和static语句块中的语句合并产生的。编译器收集的顺序是由语句在源文件中出现的顺序所决定的。静态语句块中只能访问到定义在静态语句块之前的变量，定义在其之后的变量，在静态语句块中可以赋值，但是不能访问。

2）类构造器<clinit>()方法与类的构造器<init>()方法不同，虚拟机会保证在子类的<clinit>()方法之前执行，因此，在虚拟机中第一个被执行的<clinit>()方法的类肯定是Object。

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

4）类构造器<clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，编译器就不会为这个类生成<clinit>()方法。

5）接口中也可以定义static变量，生成的<clinit>()方法不需要先执行父接口中的<clinit>()方法，同理，接口的实现类在初始化的时候也一样不会执行接口中的<clinit>()方法。

6）虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确的加锁，同步，如果多线程同时去初始化一个类，只会有一个线程去初始化，其他线程都阻塞。

【注】加载，验证，准备阶段要在初始化之前。