标签：
本文是《深入理解Java虚拟机》第七章的读书总结。
Class文件中存储了类（或接口）中的元数据信息和编译后的字节码。这些信息需要存入Java虚拟机中才能被虚拟机利用和执行。而Class文件是需要Java虚拟机加载到虚拟机内存中的。这就涉及到几个问题，什么时候需要加在一个Class文件？虚拟机如何加载Class文件到虚拟机内存中？Class文件中的信息进入虚拟机内存中后会发生怎么样的变化？
虚拟机把描述类的数据从Class文件加载到虚拟机内存，并对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型，这就是虚拟机的类加载机制。
与那些在编译时需要进行连接工作的语言不同，在Java语言里，类型的加载、连接和初始化过程都是在程序运行期间完成的，这可能会导致类加载时增加了性能开销，不过这也为Java程序提供了高度的灵活性，Java里天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。这个特性导致了很多有用的功能的出现，比如，可以编写一个面向接口的应用程序，等到运行时再指定接口的实现类；用户可以通过Java预定义的和自定义的类加载器，让一个本地的应用程序可以在运行时从网络或者其他地方加载一个二进制流作为程序代码的一部分。
类的一生就是从被加载到虚拟机内存开始，直到卸载出内存为止。整个生命周期中，一个类经历了加载（Loading）、验证（Verfication）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）等七个阶段。其中，验证、准备、解析三个阶段称为连接（Linking），过程如下所示：
在上面的流程图中，加载、验证、准备、初始化和卸载5个阶段是按顺序开始的，不过不一定按顺序进行，因为这些阶段通常是相互交叉的混合进行的，通常在一个阶段执行的过程中调用、激活另一个阶段。但是解析阶段则不一定，它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也叫动态绑定和晚期绑定）。
接下来就应该考虑一个Class文件会在什么时候进行加载。Java虚拟机规范中并没有进行强制约束，由虚拟机来具体实现。不过对于类的初始化阶段，虚拟机规范严格规定了5种情况下必须对类进行初始化，这样，类的加载、验证、准备就在这之前开始了。
这五种情况是Java虚拟机规范规定的主动初始化一个类的情况，除此之外的任何其他引用一个类的情况都不会主动初始化这个类，这叫做被动引用。下面以三个例子说明什么是被动引用。
（1）通过子类引用父类的静态字段，并不会初始化子类
代码如下：
package ch07;
public class SuperClass {
static{
System.out.println("Super Class init.");
}
public static int value=123;
}
public class SubClass extends SuperClass {
static{
System.out.println("Sub Class init.");
}
}
public class Test1 {
@SuppressWarnings("unused")
public static void main(String[] args) {
System.out.println(SubClass.value);
}
}Super Class init.
123
可以看到，并没有输出“SubClass init.”，对于静态字段，只有直接定义这个字段的类才会被初始化。不过，对于是否会加载并解析子类，Java虚拟机规范没有明确规定，HotSpot虚拟机可以使用-XX:TraceClassLoading参数来查看类加载的情况，结果如下（只显示了涉及到上面两个类的内容）：
[Loaded ch07.SuperClass from file:/G:/Java/UnderstandingJVM/bin/]
[Loaded ch07.SubClass from file:/G:/Java/UnderstandingJVM/bin/]
说明HotSpot虚拟机会加载子类，不过要先加载父类然后加载子类。
（2）通过数组定义来引用类，不会触发此类的初始化
代码如下：
public class Test1 {
@SuppressWarnings("unused")
public static void main(String[] args) {
SuperClass[] sca=new SuperClass[10];
}
}这意味着，数组也是对象，而且是和成员类型不同的一个对象。
这个类代表了SuperClass的一维数组，数组中应有的属性和方法（用户可以访问到的只有length属性和clone方法）都实现在这个类里。Java语言中对数组的访问要比C/C++相对安全是因为这个类封装了数组元素的访问方法，而C/C++直接翻译为对数组指针的移动。在Java语言里，当检查到发生数组越界时会抛出java.lang.ArrayIndexOutOfBoundsException异常。
（3）常量在编译阶段会存入调用类的常量池
代码如下：
public class ConstClass{
static{
System.out.println("ConstClass init.");
}
public static final String GREETING="Hello World.";
}
public class Test1{
public static void main(String[] args){
System.out.println(ConstClass.GREETING);
}
}接口的加载过程和类的加载过程有一些不同，不过接口也有初始化过程，上面的代码都是用静态代码块“static{}”来输出初始化信息的，而接口中不能使用“static{}”语句块，但编译器仍然会为接口生成“<clinit()>”类构造器，用于初始化接口中所定义的成员变量。接口与类真正有所区别的是在前面五种情况中的第三种：当一个类在初始化时，它的所有父类都完成了初始化，但对一个接口初始化时，并不要求所有的父接口都完成初始化，只有在真正用药父接口的时候才会初始化。
接下来就是怎么加载的问题了。这里涉及到前面图中的五个阶段：加载、验证、准备、解析和初始化。
这个加载的步骤只是类加载过程的一个阶段。这在个阶段，虚拟机要做的事情有如下三个：
流程图如下：
虚拟机规范的这三点要求并不具体，虚拟机的实现很自由。
首先要有Class文件。虽然说是文件，但获取Class二进制流的方式非常对，只要能得到这个虚拟机所需要的内容即可。比如可以使用如下的方式获取二进制流：
总之，获取Class文件的方式非常多。
将Class文件加载到内存中是由类加载器完成的。相比于类加载的其他阶段，加载这个阶段的灵活性很大，因为开发者可以自己定义一个类加载器，来达到灵活加载的目的（即重写一个类加载器的loadClass()方法）。
前面提到过，数组也是一个类，但数组类的加载和非数组类不同，它不是通过类加载器创建的，而是由Java虚拟机直接创建的。但数组类和非数组类也有很大的联系，毕竟组成数组的元素就是非数组类（对于一维数组来说，而对于多维数组来说，可以递归加载），非数组类的创建需要类加载器完成。加载创建一个数组类的过程如下：
加载阶段完成后，原来虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，不过方法区中的数据格式Java虚拟机规范没有规定。在这之后，虚拟机会在内存中实例化一个java.lang.Class类的对象。对于HotSpot虚拟机，虽然这是一个对象，按理说应该在Java堆中创建，不过HotSpot虚拟机是在方法区中创建的。这个对象将作为程序访问方法区中的这些数据类型的外部入口。
需要注意的是，加载阶段与连接阶段的部分内容是交叉进行的。
验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
不过，如果Java源代码本身有安全问题的话（比如数组越界访问），编译器就不会编译成功，也就没有Class文件。是不是就是说，如果有Class文件，那么这个Class文件就是安全的呢？如果这样，也就不需要验证了，是不是可以提高虚拟机的执行性能呢？
当然不是，前面的加载阶段提到过，Class文件不一定是编译器生成的，获取Class文件的方式有很多，甚至可以使用十六进制编辑器自己手工写一个Class文件。这样，Java语言方面的安全检查就没有用了，如果虚拟机不检查输入的字节流，很可能会因为载入了有害的字节流导致虚拟机崩溃。即，验证阶段是虚拟机的自我保护的一个手段。
从整体上看，验证阶段大致可以分为四个方面：文件格式验证、元数据验证、字节码验证和符号引用验证。
（1）文件格式验证
首先要验证文件的格式是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。这个阶段可能验证的内容有：
其实这只是一小部分，这个阶段要验证的内容还挺多，主要目的就是保证输入的字节流能正常地解析并存储于方法区内，格式上符合描述一个Java类型信息的要求。这个阶段验证的是基于二进制字节流的，只有通过这个阶段的验证，字节流才会进入方法区中，所以后面的三个验证阶段是基于方法区的存储结构进行的。
从这里可以看出，在虚拟机找到Class文件之后就开始了验证阶段，两个阶段是交叉进行的。如果这两个阶段细分的话，可以是：寻找Class文件——>找到后进行文件格式验证——>验证通过后存入方法区——>进行其他方面的验证与加载工作。
（2）元数据验证
接下来就是对字节码描述的信息进行语义分析，验证这些信息是否符合Java语言规范的要求，这个阶段验证的内容有：
对元数据的验证内容还有很多，主要是保证不存在不符合Java语言规范的元数据信息。
（3）字节码验证
接下来就是字节码验证，这部分是整个验证过程中最复杂的一部分，主要目的是通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段完成对元数据信息中的数据类型的验证后，这个阶段将对类的方法体进行校验分析，保证被校验的类的方法在运行时不会做出危害虚拟机安全的事件，比如：
这部分的验证内容还有很多。如果一个类方法体的字节码没有通过字节码验证，那么这肯定是有问题的；不过，如果字节码通过了字节码验证也不一定是没有问题的。
由于数据流验证的高复杂性，虚拟机设计团队在JDK 1.6之后的Javac编译器和Java虚拟机中进行了一项优化，给方法体的Code属性的属性表中增加了一个叫StackMapTable的属性，这个属性用来描述方法体中所有的基本快（按照控制流拆分的代码块）开始时本地变量表和操作数栈应有的状态，在字节码验证期间，就不需要根据程序员推导这些状态的合法性，只需要检查StackMapTable属性中的记录是否合法即可。不过这个属性也有被篡改的可能。
在JDK 1.6的HotSpot虚拟机中提供了-XX:UseSplitVerifier选项来关闭这项优化，或者使用参数-XX:FailOverToOldVerifier要求在类型校验失败的时候回退到旧的类型推导方式进行校验。而在JDK 1.7之后，对于版本号大于50的Class文件，使用类型检查来完成数据流分析校验是唯一的选择，不允许回退到类型推导的校验方式。
（4）符号引用验证
最后一个验证阶段就是符号引用验证。这一阶段发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段——解析阶段中发生。符号引用验证可以看做是对类自身以外（常量池的各种符号引用）的信息进行匹配性校验，通常要校验如下内容：
符号引用验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，那么就会抛出一个java.lang.IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等。
对于虚拟机的类加载机制来说，验证阶段是一个非常重要但不是必须的阶段。如果所运行的代码都已经被反复使用和验证过，那么在实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这个阶段中需要注意两点，首先，这个时候进行内存分配的仅包括类变量（被static修饰的变量）而不包括实例变量，实例变量就在对象实例化时随着对象一起分配在Java堆中。其次，这里所说的初始值通常是数据类型的零值，比如下面的类变量定义：
public static int value=10;
|
数据类型 |
零值 |
数据类型 |
零值 |
|
int |
0 |
boolean |
False |
|
long |
0L |
float |
0.0f |
|
short |
(short)0 |
double |
0.0d |
|
char |
‘\u0000’ |
reference |
Null |
|
byte |
(byte)0 |
|
|
不过也有特殊情况，将类变量赋值为非零值。如果类字段的字段属性表中存在ConstantValue属性，那么在准备阶段变量value就会被初始化为ConstantValue属性所指定的值，比如：
public static final int value=10;
编译时Javac将会为value生成一个ConstantValue的属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为10。
解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程，在Class文件结构中层多次提到过符号引用，它以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现。在解析阶段的符号引用和直接引用的区别如下：
虚拟机规范没有规定解析阶段发生的具体时间，只要求在执行anewarray、checkcast、getfield、getstatic、instanceof、invokedynamic、invokeinterface、invokeespecial、invokestatic、invokevirtual、ldc、ldc_w、multianewarray、new、putfield和putstatic这16个用于操作符号引用的字节码指令之前，先对它们所使用的符号引用进行解析。所以虚拟机实现可以根据需要来判断到底是在类被加载器加载之前就对常量池中的符号引用进行解析，还是等到一个符号引用将要被使用前再去解析。
对同一个符号引用进行多次解析请求是很常见的事情，除了invokedynamic指令外，虚拟机实现可以对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免重复解析。无论是否真正执行了多次解析动作，虚拟机需要保证的是在同一个实体中，如果一个符号引用之前就已经被成功解析过，那么后续的引用解析请求就应当是一直成功；同样的，如果第一次解析失败了，那么其它指令对这个符号的解析请求也应该收到同样的异常。
解析动作主要是对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行解析，分别对应CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info、CONSTANT_MethodType_info、CONSTANT_MethodHandle_info和CONSTANT_InvokeDynamic_info7种常量类型。这里仅仅介绍前四种，因为后三种和动态类型语言支持有关。
（1） 类或接口的解析
假设当前代码处于类D中，如果要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，虚拟机将经历如下的过程：
（2） 字段解析
要解析一个未被解析过的字段符号引用，首先将会对字段表内class_index项中索引的CONSTANT_Class_info符号引用进行解析，也就是字段所属的类或借口的符号引用。如果解析这个类或接口时发生异常，都会导致解析字段的失败。如果解析成功，才会继续解析这个字段。具体的规则如下：
（3） 类方法解析
类方法解析的第一个步骤和字段解析一样，也需要先解析出类方法表的class_index项中索引的方法所属的类或接口的符号引用，如果解析成功，按照如下步骤继续（同样以C来表示这个类）：
（4） 接口方法解析
接口方法也要解析接口方法表的class_index所属的类或接口引用，如果解析成功，用C表示这个类或接口，虚拟机按照如下的规则搜索：
返回成功后不会验证权限，因为接口的方法都是public的。
类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序。
前面已经知道，在准备阶段变量已经赋值过一次系统初始值了，而在初始化阶段，则会根据程序员通过程序制定的主观计划去初始化类变量和其它内容。即，初始化阶段是执行类构造器<clinit>()方法的过程。下面是<clinit>()方法的特点：
类加载的过程是通过类加载器来完成的。类加载器是Java语言的一个重要创新，许多有用的技术都是基于类加载器实现的，比如类层次划分、OSGi、热部署、代码加密等。
虽然类加载器只用于类的加载动作，但在Java程序中还有着很大的作用。对于任意一个类，都需要加载它的类加载器和这个类本身来确定这个类在Java虚拟机中的唯一性，每一个类加载器都有一个独立的类名称空间。也就是说，如果比较两个类是否是同一个类，除了这比较这两个类本身的全限定名是否相同之外，还要比较这两个类是否是同一个类加载器加载的。即使同一个类文件两次加载到同一个虚拟机中，但如果是由两个不同的类加载器加载的，那这两个类仍然不是同一个类。
这个相等性比较会影响一些方法，比如Class对象的equals方法、isAssignableFrom方法、isInstance方法等，还有instanceof关键字做对象所属关系判定等。下面的代码演示了不同的类加载器对instanceof关键字的影响：
package jvm;
import java.io.IOException;
import java.io.InputStream;
public class ClassLoaderTest {
public static void main(String[] args) throws Exception{
ClassLoader loader=new ClassLoader() {
@Override
public Class<?> loadClass(String name)throws ClassNotFoundException{
try{
String filename=name.substring(name.lastIndexOf(".")+1)+".class";
InputStream is=getClass().getResourceAsStream(filename);
if(is==null){
return super.loadClass(name);
}
byte[] b=new byte[is.available()];
is.read(b);
return defineClass(name,b,0,b.length);
}catch(IOException e){
throw new ClassNotFoundException(name);
}
}
};
Object obj=loader.loadClass("jvm.ClassLoaderTest").newInstance();
System.out.println(obj.getClass());
System.out.println(obj instanceof jvm.ClassLoaderTest);
}
}这里构造了一个简单的类加载器，它可以加载与自己在同一个路径下的Class文件。然后使用这个类加载器去加载全限定名是“jvm.ClassLoaderTest”的类，并实例化了这个类的对象。从第一行输出可以看出，这个对象确实是jvm.ClassLoaderTest类的一个实例，但第二句输出表明在做instanceof检查时出现了false，这是因为这时虚拟机中有两个jvm.ClassLoaderTest类，一个是系统应用程序类加载器加载的，另一个是自定义的类加载器加载的，这两个类虽然来自同一个Class文件，但是加载它们的类加载器不同，导致类型检查时结果是false。
从Java虚拟机的角度看，只有两种不同的类加载器，一种是启动类加载器，这个类加载是由C++实现的，是虚拟机的一部分；另一个是所有其它的类加载器，都是由Java实现的，独立在虚拟机外部，并且全部继承自java.lang.ClassLoader抽象类。
不过在Java开发者看来，类加载器的细致划分可以划分为三种：
用户的应用程序就是在这三个类加载器的配合下加载的。不过，用户还可以加入自己的类加载器，这些类加载器的关系如下图：
这种类加载的层次关系，称为类加载器的双亲委派模型。双亲委派模型要求除了顶层的启动类加载器之外，其余的类加载器都应当有自己的父类加载器。不过这个父子关系不是通过继承实现的，而是使用组合关系来复用父加载器的代码。
双亲委派模型的工作过程如下：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都会传送到顶层的启动类加载器中，只有当父类加载器反馈自己无法完成这个加载请求（它的搜索范围内没找到这个类）时，自加载器才会尝试自己加载。
这种模型的一个好处就是由于类加载器有一种层次关系，导致类也有一种层次关系，从而有了优先级。比如类java.lang.Object，它存放在rt.jar中，无论哪个类加载器要加载这个类，最终都要委派给启动类加载器去加载，因此Object类在各个类加载器环境中都是同一个类。相反，如果没有使用双亲委派模型，由各个类加载器去自行加载，如果用户自己编写了一个称为java.lang.Object的类，并放在程序的ClassPath中，那系统将会有多个不同的Object类，java类型体系中最基础的行为也就没有办法保证了。
不过，双亲委派模型并不是一个强制性的约束模型，而是一个推荐实现类加载的方式。但也会有例外，导致破坏双亲委派模型。
首先，双亲委派模型是JDK 1.2之后引入的，而ClassLoader类在JDK 1.0就有了，为了向前兼容，不得做出一些妥协。
还有，类加载器的层次结构解决了基础类的统一问题，但是如果基础类要回调用户的代码呢？这也破坏了双亲委托模型。
最后就是语言动态性造成的。
这部分对于双亲委派模型的破坏的介绍不是很多，只要知道这只是一个推荐模型即可。
添加公众号Machairodus，我会不时分享平时学到的东西~
标签：
原文地址：http://blog.csdn.net/u012877472/article/details/51565390
