前言
我们写的源程序.java文件经过编译后成为了.class字节码文件，.class文件中描述了类的各种信息，最终都需要加载到虚拟机(JVM)之后才能运行和使用。而虚拟机如何加载这些.class文件？.class文件的信息进入到虚拟机后会发生什么变化？这些都是本文要讲的内容。
类使用的7个阶段
类从被加载到虚拟机JVM内存中开始，到卸载出内存，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initiallization）、使用（Using）和卸载（Unloading）这7个阶段。其中验证、准备、解析3个部分统称为链接（Linking），这七个阶段的发生顺序如下图：
图中，加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段不一定：它在某些情况下可以初始化阶段之后在开始，这是为了支持Java语言的运行时绑定（也称为动态绑定）。
加载Loading
加载是类加载的第一个阶段，在加载阶段，虚拟机需要完成以下3件事情：
- 通过一个类的全限定名来获取定义此类的二进制字节流；
- 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
- 在内存(HotSpot虚拟机中是在方法区，不在堆中)中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；
有两种时机会触发类加载：
1、预加载。虚拟机启动时加载，加载的是JAVA_HOME/lib/下的rt.jar下的.class文件，这个jar包里面的内容是程序运行时常用到的，像java.lang.*、java.util.*、java.io.*等等，因此随着虚拟机一起加载。要证明这一点很简单，写一个空的main函数，设置虚拟机参数为"-XX:+TraceClassLoading"来获取类加载信息，运行一下：
[Opened C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.Object from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.io.Serializable from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.Comparable from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.CharSequence from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.String from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.reflect.AnnotatedElement from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.reflect.GenericDeclaration from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.reflect.Type from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.Class from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.Cloneable from C:Program FilesJavajdk1.8.0_111jrelib t.jar] [Loaded java.lang.ClassLoader from C:Program FilesJavajdk1.8.0_111jrelib t.jar]
2、运行时加载。虚拟机在用到一个.class文件的时候，会先去内存中查看一下这个.class文件有没有被加载，如果没有就会按照类的全限定名来加载这个类。
虚拟机规范对这三点的要求并不具体，因此虚拟机实现与具体应用的灵活度都是相当大的。例如第一条，根本没有指明二进制字节流要从哪里来、怎么来，因此单单就这一条，就能变出许多花样来：
-从zip包中获取，这就是以后jar、ear、war格式的基础
-从网络中获取，典型应用就是Applet
-运行时计算生成，典型应用就是动态代理技术
-由其他文件生成，典型应用就是JSP，即由JSP生成对应的.class文件
-从数据库中读取，这种场景比较少见
总而言之，在类加载整个过程中，这部分是对于开发者来说可控性最强的一个阶段。
加载阶段完成以后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中。方法区中的数据存储格式由虚拟机实现自行定义，
然后在内存中实例化一个java.lang.Class类的对象(并没有明确规定是在Java堆中，对于HotSpot虚拟机而言，Class对象比较特殊，它虽然是对象，但是存放在方法区里面)，
这个对象将作为程序访问方法区中的这些类型数据的外部接口！
验证
连接阶段的第一步，这一阶段的目的是为了确保.class文件的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
Java语言本身是相对安全的语言（相对C/C++来说），但是前面说过，.class文件未必要从Java源码编译而来，可以使用任何途径产生，甚至包括用十六进制编辑器直接编写来产生.class文件。在字节码语言层面上，Java代码至少从语义上是可以表达出来的。虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。
验证阶段大致会完成4个阶段的检验动作：
- 文件格式验证：验证字节流是否符合Class文件格式的规范,并且能被当前版本的虚拟机处理。例如：是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。该验证阶段的主要目的是保证输入的字节流能够正确的解析并存储于方法区内，格式上符合描述一个Java类型信息的要求。这个阶段的验证是基于二进制字节流进行的。只有通过了这个阶段的验证之后，字节流才会进入内存的方法区进行存储，所以后面三个验证阶段全部是基于方法区的存储结构进行的，不会直接操作字节流。
- 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。第二阶段的主要目的是对类的元数据信息进行语义校验，保证不存在不符合java语言规范的元数据信息。
- 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。在第二阶段对元数据信息中的数据类型做完校验后，这个阶段将对类的方法体进行校验分析，保证被校验类的方法在执行的时候不会做出危害虚拟机安全的事件。
- 符号引用验证：符号引用验证发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三阶段-解析阶段发生，符号引用验证可以看做是对类自身以外(常量池中的各种符号引用)的信息进行匹配性校验。
如符号引用中通过字符串描述的全限定名是否能够找到对应的类等。确保解析动作能正确执行。
验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。
准备
准备阶段是正式为静态变量分配内存并设置其初始值的阶段，这些变量所使用的内存都将在方法区中分配。关于这点，有两个地方注意一下：
1、这时候进行内存分配的仅仅是静态变量（被static修饰的变量），而不是实例变量，实例变量将会在对象实例化的时候随着对象一起分配在Java堆中
2、这里所说的初始值"通常情况"下是数据类型的零值，假设一个类变量的定义为：
public static int value=123;
那变量value在准备阶段过后的初始值为0而不是123.因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器<clinit>()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
至于"特殊情况"是指：public static final int value=123，即当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0.
解析
解析阶段是虚拟机将符号引用替换为直接引用的过程。符号引用在Class文件格式中以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量出现.来了解一下符号引用和直接引用有什么区别：
1、符号引用。
符号引用是以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标就可以了。符号引用和虚拟机实现的内存布局无关，应用的目标并不一定已经加载到内存中。
这个其实是属于编译原理方面的概念，符号引用包括了下面三类常量：
· 类和接口的全限定名
· 字段的名称和描述符
· 方法的名称和描述符
这么说可能不太好理解，结合实际看一下，写一段很简单的代码：
package com.winner; public class Test { private static int i; private double d; public static void print() { } private boolean trueOrFalse() { return false; } }
用javap把这段代码的.class反编译一下：
>javap -p -v Test Constant pool: #1 = Methodref #3.#17 // java/lang/Object."<init>":()V #2 = Class #18 // com/winner/Test #3 = Class #19 // java/lang/Object #4 = Utf8 i #5 = Utf8 I #6 = Utf8 d #7 = Utf8 D #8 = Utf8 <init> #9 = Utf8 ()V #10 = Utf8 Code #11 = Utf8 LineNumberTable #12 = Utf8 print #13 = Utf8 trueOrFalse #14 = Utf8 ()Z #15 = Utf8 SourceFile #16 = Utf8 Test.java #17 = NameAndType #8:#9 // "<init>":()V #18 = Utf8 com/winner/Test #19 = Utf8 java/lang/Object
看到Constant Pool也就是常量池中有19项内容，其中带"Utf8"的就是符号引用。比如#2，它的值是"com/winner/Test"，表示的是这个类的全限定名；又比如#4为i，#5为I，它们是一对的，表示变量时Integer（int）类型的，名字叫做i；#6为D、#7为d也是一样，表示一个Double（double）类型的变量，名字为d；#12、#13表示的都是方法的名字。
那其实总而言之，符号引用和我们上面讲的是一样的，是对于类、变量、方法的描述。符号引用和虚拟机的内存布局是没有关系的，引用的目标未必已经加载到内存中了。
2、直接引用
直接引用可以是直接指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机实例上翻译出来的直接引用一般不会相同，如果有了直接引用，那么引用的目标必定已经在内存中存在。
初始化
初始化阶段是类加载过程的最后一步。初始化过程是一个执行类构造器<clinit>()方法的过程，就是给static变量赋予用户指定的值以及执行静态代码块。
注意一下，虚拟机会保证类的初始化在多线程环境中被正确地加锁、同步， 即如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程都要阻塞等待，直至活动线程执行<clinit>()方法完毕。因此如果在一个类的<clinit>()方法中有耗时很长的操作，就可能造成多个进程阻塞。不过其他线程虽然会阻塞，但是执行<clinit>()方法的那条线程退出<clinit>()方法后，其他线程不会再次进 入<clinit>()方法了，因为同一个类加载器下，一个类只会初始化一次。实际应用中这种阻塞往往是比较隐蔽的，要小心。
(1)<clinit>()方法是由编译器自动收集类中的所有类变量的赋值语句和静态语句块(static{}块)中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的。静态语句块只能访问到定义在静态语句块之前的变量，定义在之后的变量，在前面的静态语句块可以赋值，但是不能访问。
(2)类构造器<clinit>()方法与类的构造函数（或者说实例构造器中的<init>()方法）不同，它不需要显示的调用父类构造器，虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个被执行的<clinit>()方法的类肯定是java.lang.Object。
(3)由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
(4)<clinit>()方法对于类或者接口来说并不是必须的，如果一个类没有静态语句块，也没有类变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。
(5)接口中不能使用静态语句块，但仍然可以有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。
(6)虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只有一个线程去执行这个类的<clinit>()方法，其他线程都需要阻塞等待。其他线程虽然被阻塞，但是唤醒之后不会再次进入<clinit>()方法，同一个类加载器下，一个类型只会加载一次！
Java虚拟机规范严格规定了有且只有5种场景必须立即对类进行初始化(而加载、验证、准备自然需要在此之前开始)，这5种场景也称为对一个类进行主动引用：
1、遇到new(类)、getstatic、putstatic(属性)或invokestatic(方法)这4条字节码指令时，如果类没有进行过初始化，则需要先触发其初始化。生成这4条指令的最常见的Java代码场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态属性（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。
2、使用java.lang.reflect包中的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化。
3、当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先初始化其父类。
4、当虚拟机启动时，用户需要指定一个要执行的主类（包含main()方法的那个类），虚拟机会先初始化这个主类。
5.当使用JDK1.7以上的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解析结果为REF_getStatic、REF_putStatic、REF_invokeStatic的方法句柄，并且这个方法句柄所对应类没有进行初始化，则触发初始化操作。
对于这5种会触发类进行初始化的场景，虚拟机规范中使用了一个很强烈的限定语：有且只有。这五种场景中的行为称为对一个类进行主动引用！除此之外所有引用类的方式都不会触发初始化。称为被动引用！
接下来看下被动引用的几个例子：
1、子类引用父类静态字段，不会导致子类初始化。至于子类是否被加载、验证了，前者可以通过"-XX:+TraceClassLoading"来查看
public class SuperClass{
public static int value = 123;
static{
System.out.println("SuperClass init");
}
}
public class SubClass extends SuperClass{
static{
System.out.println("SubClass init");
}
}
public class TestMain{
public static void main(String[] args){
System.out.println(SubClass.value);
}
}
运行结果为
SuperClass init
123
对于静态字段，只有直接定义这个字段的类才会被初始化，因此通过子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化！
2、通过数组定义引用类，不会触发此类的初始化
public class SuperClass{
public static int value = 123;
static{
System.out.println("SuperClass init");
}
}
public class TestMain{
public static void main(String[] args){
SuperClass[] scs = new SuperClass[10];
}
}
运行结果为
3、引用静态常量时，常量在编译阶段会存入类的常量池中，本质上并没有直接引用到定义常量的类
public class ConstClass{
public static final String HELLOWORLD = "Hello World";
static{
System.out.println("ConstCLass init");
}
}
public class TestMain{
public static void main(String[] args){
System.out.println(ConstClass.HELLOWORLD);
}
}
运行结果为
Hello World
在编译阶段通过常量传播优化，常量HELLOWORLD的值"Hello World"实际上已经存储到了NotInitialization类的常量池中，以后NotInitialization对常量ConstClass.HELLOWORLD的引用实际上都被转化为NotInitialization类对自身常量池的引用了。也就是说，实际上的NotInitialization的Class文件中并没有ConstClass类的符号引用入口，这两个类在编译成Class之后就不存在任何联系了。
接口也有初始化过程，但是当一个类在初始化的时候要求其父类全部都已经完成初始化了！当时一个接口在初始化的时候并不要求其父接口全部完成初始化，只有真正使用到父接口的时候才会去初始化！