JVM笔记6：JVM类加载机制

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

从类被加载到虚拟机内存中开始，到卸载出内存为止，类的生命周期包括加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段

其中验证、准备和解析三部分称为连接，在Java语言中，类型的加载和连接过程都是在程序运行期间完成的（Java可以动态扩展的语言特性就是依赖运行期动态加载、动态连接这个特点实现的），这样会在类加载时稍微增加一些性能开销，但是却为Java应用程序提供高度的灵活性

加载、验证、准备、初始化和卸载这5个阶段的顺序是固定的（即：加载阶段必须在验证阶段开始之前开始，验证阶段必须在准备阶段开始之前开始等。这些阶段都是互相交叉地混合式进行的，通常会在一个阶段的执行过程中调用或激活另一个阶段），解析阶段则不一定，在某些情况下，解析阶段有可能在初始化阶段结束后开始，以支持Java的动态绑定

加载（Loading）

start time:

“加载”阶段是“类加载过程”的一个阶段，虚拟机规范并没有强制约束什么时候开始类加载过程的第一个阶段：加载，而是交由虚拟机的具体实现自由把握，但是虚拟机规范严格规定有且只有4种情况（这4种情况将在后面初始化部分进行介绍）必须立即对类进行初始化，相应的加载、验证和准备阶段自然要在初始化阶段开始之前开始

task:

在加载阶段，虚拟机需要完成以下三件事（虚拟机规范对这三件事的要求并不具体，因此虚拟机实现与具体应用的灵活度相当大）：

1，通过一个类的全限定名获取定义这个类的二进制流

可以从jar包、ear包、war包中获取，可以从网络中获取（Applet），可以运行时生成（动态代理），可以通过其它文件生成（Jsp）等

虚拟机规范并没有指明二进制流要从从一个Class文件中获取，准确的说是没有指明从哪里获取及如何获取（完全可以通过使用自己实现的类加载器读入一二进制流来完成加载阶段，但是一般情况下二进制流的来源还是Class文件，jar中保存的是Class文件，Jsp也是首先被编译成Class文件）

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

虚拟机规范并未规定方法区存储数据的具体数据结构，数据存储格式由虚拟机实现自行定义

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

验证（Verification）

start time:

加载阶段与连接阶段的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段还未结束，连接阶段可能已经开始，这部分夹杂在加载阶段进行的动作，依然属于连接阶段的内容，并且加载阶段必定早于连接阶段开始

task:

连接阶段的第一步，确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全

Java语言本身是相对安全的语言（相对于C/C++），使用纯粹的Java代码无法做到诸如访问数组边界之外的数据、将一个对象转型为它未实现的数据类型、跳转到不存在的代码行等，如果这样做了，编译器将拒绝编译，但是Class文件不一定由Java源码编译而来，完全可以使用任何途径，如：用十六进制编辑器直接编写来产生Class文件，在字节码层面上，上述Java代码无法做到的事情都是可以实现的，此时虚拟机如果不检查输入的字节流，很有可能因为载入了有害的字节流而导致系统崩溃，所以验证时虚拟机对自身保护的一项重要工作

虚拟机规范对该阶段的规定非常笼统，仅要求如果验证到输入的字节流不符合Class文件的存储格式，就抛出一个java.lang.VerifyError异常（JDK1.6的API文档对该异常类的描述为：当“校验器”检测到一个类文件虽然格式正确，但包含着一些内部不一致问题或安全性问题时，抛出该错误）或其子类异常，具体检查哪些方面、如何检查、何时检查，都未做强制要求或明确说明，故不同的虚拟机对验证的实现有所不同，但大致都会完成如下4个阶段的检查过程：

1，文件格式验证

验证字节流是否符合Class文件格式的规范，是否能被当前版本的虚拟机处理（如：是否以魔数0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内等）

该阶段的主要目的是保证输入的字节流能被正确的解析并存储于方法区内，格式上符合描述一个Java类型信息的要求

该阶段的验证是基于字节流的，经过这个阶段的验证后，字节流才会进入内存的方法区中进行存储，故后面的三个验证阶段是基于方法区的存储结构进行的

2，元数据验证

对字节码描述的信息（即类的元数据信息）进行语义分析，以保证其描述的信息符合Java语言规范的要求（如：该类是否有父类、是否继承了不允许被继承的类等）

3，字节码验证

进行数据流和控制流分析，即对类的方法体进行校验分析以保证被校验类的方法在运行时不会做出危害虚拟机安全的行为（如：保证跳转指令不会跳转到方法体以外的字节码指令上等）

即使一个方法通过了字节码验证，也不能说明其一定是安全的（通过程序去校验程序逻辑是无法做到绝对准确的）

JDK1.6之后的Javac编译器进行了一项优化，给方法体的Code属性的属性表中增加了一项新属性：StackMapTable，该属性保存了方法体中的类型信息，可以使字节码验证时的类型推导变为类型检查从而节省时间。在JDK1.6的HotSpot虚拟机中提供了-XX:-UseSplitVerifier选项来关闭这项优化，或者使用-XX:+FailOverToOldVerifier选项在类型检查失败时退回到使用类型推导方式进行校验

4，符号引用验证

对类自身以外的信息进行匹配性校验（如：符号引用中通过字符串描述的全限定名是否能找到对应的类、指定的类中是否存在符合描述符与简单名称描述的方法与字段）

该校验发生于虚拟机将符号引用转化为直接引用的时候，该转化动作发生于连接的第三个阶段：解析阶段，确保解析动作能够正常执行，如果无法通过符号引用验证，将会抛出一个java.lang.IncompatibleClassChangeError异常（特别要注意其继承自java.lang.Error而不是java.lang.Exception）的子类，其子类均为通常由编译器捕获的错误

如果运行的全部代码都已经被反复使用和验证过，在实施阶段可以使用-Xverify:none参数来关闭大部分的类验证措施以缩短虚拟机类加载的时间

准备（Preparation）

task:

虚拟机在准备阶段为类变量（static修饰的变量）分配内存，并设置类变量初始值。这些内存都将在方法区分配

有2个方面需要特别强调：

1，该阶段进行内存分配的仅包括类变量，不包括实例变量，实例变量将在对象初始化时随对象一起分配在堆内存中

2，这里所说的初始值“通常情况下”是指数据类型的零值，如一个类变量定义为：public static int a =1;，变量a在准备阶段之后的值为0而不是1

程序编译后产生将a赋值为1的putstatic指令，并将该条指令存放在类构造器<clinit>()中，故a赋值为1的动作将在初始化阶段完成

如果类字段的字段属性表中包含ConstantValue属性，那在准备阶段变量就会被初始化为ConstantValue属性所指定的值，即如果a变量定义变为public final static int a = 1;，编译时javac会为a生成ConstantValue属性，准备阶段虚拟机就会根据ConstantValue的设置将a的值置为1

基本数据类型零值如下：

数据类型	零值
byte	(byte)0
char	‘\u0000’
short	(short)0
int	0
long	0L
float	0.0f
double	0.0d
boolean	false
reference	null

解析（Resolution）

start time:

虚拟机规范并未规定解析动作发生的具体时间，仅要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析

task:

解析阶段是虚拟机将常量池中的符号引用（见备注一）替换为直接引用（见备注二）的过程

对同一个符号引用进行多次解析请求是很常见的，虚拟机实现可能会对第一次解析的结果进行缓存（将直接引用保存在运行时常量池中），无论是否真正执行了多次解析动作，虚拟机实现必须保证在同一个实体中，如果一个符号引用之前已经被成功解析过，后续的引用解析请求就应当一直成功，反之亦然

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

对字段、类方法、接口方法符号引用解析前，首选会对其所在类的符号引用进行解析（详见常量池常量结构，CONSTANT_Fieldref_info、CONSTAN_Methodref_info、CONSTANT_InterfaceMethodref_info类型常量中均保存了声明该字段、类方法、接口方法的类或接口的描述符的索引：一个CONSTANT_Class_info类型常量的索引）

初始化（Initialization）

start time:

有且只有4种情况必须立即对类进行初始化：

1，遇到new（使用new关键字实例化对象）、getstatic（获取一个类的静态字段，final修饰符修饰的静态字段除外）、putstatic（设置一个类的静态字段，final修饰符修饰的静态字段除外）和invokestatic（调用一个类的静态方法）这4条字节码指令时，如果类还没有初始化，则必须首先对其初始化

2，使用java.lang.reflect包中的方法对类进行反射调用时，如果类还没有初始化，则必须首先对其初始化

3，当初始化一个类时，如果其父类还没有初始化，则必须首先初始化其父类

4，当虚拟机启动时，需要指定一个主类（main方法所在的类），虚拟机会首选初始化这个主类

这4种行为称为对一个类进行主动引用，除此之外所有引用类的方式，都不会触发初始化，称为被动引用

package com.test;

public class SuperClass {
	static{
		System.out.println("super class init!");
	}
	public static int a = 1;
	public final static int b = 1;
}

package com.test;

public class SubClass extends SuperClass{
	static{
		System.out.println("super class init!");
	}
}

测试一：

//-XX:+TraceClassLoading
public class Test {
	static{
		System.out.println("test class init!");
	}

	public static void main(String[] args){
		System.out.println(SubClass.a);
	}
}

运行结果为：

......
[Loaded com.test.Test from file:/D:/eclipseProject/1/bin/]
test class init!
[Loaded com.test.SuperClass from file:/D:/eclipseProject/1/bin/]
[Loaded com.test.SubClass from file:/D:/eclipseProject/1/bin/]
super class init!
1
......

对于静态字段，只有直接定义这个字段的类才会被初始化，故只有父类会被初始化，子类不会被初始化（子类的调用方式不符合4种直接引用中的任何一种）；Test类为程序入口，故也会进行初始化

是否会触发子类的加载和验证，虚拟机规范没有明确规定，视虚拟机具体实现而定，对Hotspot虚拟机，可通过-XX:+TraceClassLoading参数看到此操作会导致子类的加载

测试二：

public class Test {
	public static void main(String[] args){
		SuperClass[] temp = new SuperClass[10];
	}
}

输出结果为空

测试三：

public class Constant {
	static{
		System.out.println("constant class init!");
	}
	public final static int a = 1;
}

public class Test {
	public static void main(String[] args){
		System.out.println(Constant.a);
	}
}

运行结果：

1

在编译阶段，常量a的值1将会放入Test类的常量池中，对常量Constant.a的引用实际上被转化为Test类对自身常量池的引用，这2个类在编译为Class文件后就没有任何关系了

task:

类初始化阶段是“类加载过程”中最后一步，在之前的阶段，除了加载阶段用户应用程序可以通过自定义类加载器参与，其它阶段完全由虚拟机主导和控制，直到初始化阶段，才真正开始执行类中定义的Java程序代码

在准备阶段，变量已经赋过一次初始值，在初始化阶段，则是根据程序员通过程序制定的主观计划去初始化类变量和其它资源，简单说，初始化阶段即虚拟机执行类构造器<clinit>()方法的过程，下面详细介绍下<clinit>方法：

<clinit>由编译器自动收集类中所有类变量的赋值动作和静态语句块中的语句合并产生的，编译器收集的顺序由语句在源文件中出现的顺序决定，特别注意的是，静态语句块只能访问到定义在它之前的类变量，定义在它之后的类变量只能赋值，不能访问

public class Test {
	public static int a = 1;
	static{
		a += 1;
		System.out.println(a);
		b = 2;
		//Cannot reference a field before it is defined
		//b += 1;
		//System.out.println(b);
	}
	public static int b = 1;

	public static void main(String[] args) {
		Test test = new Test();
		System.out.println(Test.b);
	}
}

运行结果为（收集顺序由其在原文件中的顺序决定，故这里b的值为1而不是2）：

2
1

与实例构造器<init>()方法不同，<clinit>方法不需要显式的调用父类的<clinit>()方法，虚拟机会自动保证在子类的<clinit>()方法运行之前，父类的<clinit>()方法已经执行结束，虚拟机中第一个执行<clinit>()方法的类为java.lang.Object

public class SuperClass {
	static{
		System.out.println("super class init!");
	}
}

public class SubClass extends SuperClass{
	static{
		System.out.println("sub class init!");
	}

	public static void main(String[] args) {
		SubClass sub = new SubClass();
	}
}

运行结果为：

super class init!
sub class init!

<clinit>()方法对于类或接口不是必须的，如果一个类中不包含静态语句块，也没有对类变量的赋值操作，编译器可以不为该类生成<clinit>()方法

接口中不可以使用静态语句块，但是可以有类变量的赋值操作，故编译器也会对接口生成<clinit>()方法，执行接口的<clinit>()方法之前不要求首先执行父接口的<clinit>()方法，除非接口中使用了父接口中初始化的类变量，同理，接口实现类在初始化时也不一定要求首先执行接口的<clinit>()方法

虚拟机会保证一个类的<clinit>()方法在多线程环境下被正确的加锁和同步，如果多个线程同时初始化一个类，只会有一个线程执行这个类的<clinit>()方法，其它线程都会阻塞等待，直到活动线程执行<clinit>()方法完毕

public class A {
	static{
		System.out.println(Thread.currentThread().getName()
				+" "+new Date());
		try {
			Thread.sleep(5000);
		} catch (InterruptedException e) {
			e.printStackTrace();
		}
	}
}

public class T implements Runnable {
	public void run() {
		A a = new A();
		System.out.println(Thread.currentThread().getName()
				+" "+new Date());
	}

	public static void main(String[] args){
		T t1 = new T();
		T t2 = new T();
		Thread thread1 = new Thread(t1);
		Thread thread2 = new Thread(t2);
		thread1.start();
		thread2.start();
	}
}

运行结果（只有一个线程执行了A类中静态语句块中的代码）：

Thread-0 Fri Dec 06 10:25:00 CST 2013
Thread-1 Fri Dec 06 10:25:05 CST 2013
Thread-0 Fri Dec 06 10:25:05 CST 2013

PS：

1，符号引用：以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时可以无歧义的定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用目标并不一定已经加载到内存中

2，直接引用：直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄，直接引用与虚拟机实现的内存布局相关，如果有了直接引用，引用目标必定已经加载到内存中