类使用的7个阶段
类从被加载到虚拟机内存中开始，到卸载出内存，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initiallization）、使用（Using）和卸载（Unloading）这7个阶段。其中验证、准备、解析3个部分统称为连接（Linking），这七个阶段的发生顺序如下图：
图中，加载、验证、准备、初始化、卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段不一定：它在某些情况下可以初始化阶段之后在开始，这是为了支持Java语言的运行时绑定（也称为动态绑定）。接下来讲解加载、验证、准备、解析、初始化五个步骤，这五个步骤组成了一个完整的类加载过程。使用没什么好说的，卸载属于GC的工作，在之前GC的文章中已经有所提及了。
加载Loading
加载是类加载的第一个阶段。有两种时机会触发类加载：
1、预加载。虚拟机启动时加载，加载的是JAVA_HOME/lib/下的rt.jar下的.class文件，java.lang.*、java.util.*、java.io.*等等，因此随着虚拟机一起加载。要证明这一点很简单，写一个空的main函数，设置虚拟机参数为"-XX:+TraceClassLoading"来获取类加载信息，运行一下：
[Opened /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.Object from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.io.Serializable from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.Comparable from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.CharSequence from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.String from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.reflect.GenericDeclaration from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.reflect.Type from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.reflect.AnnotatedElement from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.Class from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.Cloneable from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar] [Loaded java.lang.ClassLoader from /home/tp/MyEclipse Professional 2014/binary/com.sun.java.jdk7.linux.x86_64_1.7.0.u45/jre/lib/rt.jar]
2、运行时加载。虚拟机在用到一个.class文件的时候，会先去内存中查看一下这个.class文件有没有被加载，如果没有就会按照类的全限定名来加载这个类。
加载阶段做了有三件事情：
1.获取.class文件的二进制流。
2.把类信息，静态变量，字节码，常量这些.class文件中的内容放入到方法区中。
3.在内存中生成一个代表这个.class文件的java.lang.Class对象，作为方法区这个类的各种数据的入口。一般情况下对象是放在堆内存中，但是Class对象比较特殊，所以在Hotspot虚拟机中是放在了方法区中（其他虚拟机不一定是这样）。
虚拟机规范对这三点的要求并不具体，因此虚拟机实现与具体应用的灵活度都是相当大的。例如第一条，根本没有指明二进制字节流要从哪里来、怎么来，因此单单就这一条，就能变出许多花样来：
· 从zip包中获取，这就是以后jar、ear、war格式的基础
· 从网络中获取，典型应用就是Applet
· 运行时计算生成，典型应用就是动态代理技术
· 由其他文件生成，典型应用就是JSP，即由JSP生成对应的.class文件
· 从数据库中读取，这种场景比较少见
总而言之，在类加载整个过程中，这部分是对于开发者来说可控性最强的一个阶段。
验证
是为了确保.class中的字节流包含的信息符合虚拟机要求，并且不会危害虚拟机自身安全。前面说过，.class文件未必要从Java源码编译而来，可以使用任何途径产生，甚至包括用十六进制编辑器直接编写来产生.class文件。在字节码语言层面上，Java代码至少从语义上是可以表达出来的。虚拟机如果不检查输入的字节流，对其完全信任的话，很可能会因为载入了有害的字节流而导致系统崩溃，所以验证是虚拟机对自身保护的一项重要工作。
验证阶段将做一下几个工作，具体就不细讲了，这是虚拟机实现层面的问题：
1、文件格式验证
这个地方要说一点和开发者相关的。.class文件的第5~第8个字节表示的是该.class文件的主次版本号，验证的时候会对这4个字节做一个验证，高版本的JDK能向下兼容以前版本的.class文件，但不能运行以后的class文件，即使文件格式未发生任何变化，虚拟机也必须拒绝执行超过其版本号的.class文件。举个具体的例子，如果一段.java代码是在JDK1.6下编译的，那么JDK1.6、JDK1.7的环境能运行这个.java代码生成的.class文件，但是JDK1.5、JDK1.4乃更低的JDK版本是无法运行这个.java代码生成的.class文件的。如果运行，会抛出java.lang.UnsupportedClassVersionError，这个小细节，务必注意。
2、元数据验证
3、字节码验证
4、符号引用验证
准备正式为类变量（类常量）分配内存并设置其初始值的阶段，也就是0或者false这些。这些变量使用的内存都在方法区中分配
1.这时候进行内存分配的是类变量，而不是实例变量，实例变量会在对象实例化的时候分配到java堆中。
2.这个阶段指的是那些static修饰的变量（或常量），比如public static int value = “123”（变量），在准备阶段的时候值是0，给value赋值是在初始化阶段才进行。而比如"public static final int value = 123（常量）;"就不一样了，在准备阶段，虚拟机就会给value赋值为123。
各个数据类型的零值如下图：
解析解释阶段是 虚拟机将常量池内的符号引用替换为直接引用的过程。
1.符号引用 这个是编译原理方面的概念，符号引用以一组符号来描述所引用的目标，符号引用可以是任何形式的字面量，符合引用包括三类常量。 类和接口的全限定名，字段的名称和描述符，方法的名称和描述符
package com.xrq.test6;
public class TestMain
{
private static int i;
private double d;
public static void print()
{
}
private boolean trueOrFalse()
{
return false;
}
}
用javap把这段代码的.class反编译一下：
Constant pool: #1 = Class #2 // com/xrq/test6/TestMain #2 = Utf8 com/xrq/test6/TestMain #3 = Class #4 // java/lang/Object #4 = Utf8 java/lang/Object #5 = Utf8 i #6 = Utf8 I #7 = Utf8 d #8 = Utf8 D #9 = Utf8 <init> #10 = Utf8 ()V #11 = Utf8 Code #12 = Methodref #3.#13 // java/lang/Object."<init>":()V #13 = NameAndType #9:#10 // "<init>":()V #14 = Utf8 LineNumberTable #15 = Utf8 LocalVariableTable #16 = Utf8 this #17 = Utf8 Lcom/xrq/test6/TestMain; #18 = Utf8 print #19 = Utf8 trueOrFalse #20 = Utf8 ()Z #21 = Utf8 SourceFile #22 = Utf8 TestMain.java
看到Constant Pool也就是常量池中有22项内容，其中带"Utf8"的就是符号引用。比如#2，它的值是"com/xrq/test6/TestMain"，表示的是这个类的全限定名；又比如#5为i，#6为I，它们是一对的，表示变量时Integer（int）类型的，名字叫做i；#6为D、#7为d也是一样，表示一个Double（double）类型的变量，名字为d；#18、#19表示的都是方法的名字。
那其实总而言之，符号引用和我们上面讲的是一样的，是对于类、变量、方法的描述。符号引用和虚拟机的内存布局是没有关系的，引用的目标未必已经加载到内存中了。
2、直接引用
直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不同的虚拟机示例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经存在在内存中了。
初始化
初始化是类加载的最后一步，初始化阶段是真正执行类中个的java代码的过程。初始化过程是执行类构造器的过程。其实就是给static变量赋予用户指定的值以及执行静态代码块。
虚拟机会保证类的初始化在多线程环境中被同步，即如果多线程去初始化一个类，只有一个线程会执行这个类的<clinit>()方法，其他线程要等待，直到活动线程执行<clinit>()方法结束。如果一个类的<clinit>方法有耗时很长的操作，可能会出现阻塞。不过当那条线程退出<clinit>()方法后，其他
线程不会再次进入。因为一个类加载器下，一个类只初始化一次。
Java虚拟机规范严格规定了有且只有5种场景必须立即对类进行初始化，这4种场景也称为对一个类进行主动引用
1、使用new关键字实例化对象、读取或者设置一个类的静态字段（被final修饰的静态字段除外）、调用一个类的静态方法的时候
2、使用java.lang.reflect包中的方法对类进行反射调用的时候
3、初始化一个类，发现其父类还没有初始化过的时候
4、虚拟机启动的时候，虚拟机会先初始化用户指定的包含main()方法的那个类
除了上面4种场景外，所有引用类的方式都不会触发类的初始化，称为被动引用。
类与类加载器类加载器实现类的加载动作。对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在java虚拟机的唯一性。每个类加载器都有一个独立的类名称空间。比较两个类是否相等，必须由同一个类加载器加载才有意义。即使两个类来源于同一个.class文件，被同一个
虚拟机加载，只要是类加载器不同那么这两个类就不一样。上面说的"相等"，包括代表类的.class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。
这是三个层次的类加载器，它们不是继承关系。
1.启动类加载器Bootstrap ClassLoader ：这个是嵌在jvm内核中的加载器（c++写的），负责加载java_home/lib下的类库，系统类加载器是无法被java程序直接应用。
2.扩展类加载器Extension ClassLoader：负责加载JAVA_HOME/lib/ext目录中的，或者被java.ext.dirs系统变量指定所指定的路径中所有类库，开发者可以直接使用扩展类加载器。
3.应用程序类加载器Application ClassLoader：也是系统类加载器。
public static void main(String[] args) {
System.out.println(ClassLoader.getSystemClassLoader());
}
结果是sun.misc.Launcher$AppClassLoader@5a74b10b 证明Application ClassLoader 是系统类加载器。
public static void main(String[] args) {
System.out.println(ClassLoader.getSystemClassLoader().getParent());
}
结果是sun.misc.Launcher$ExtClassLoader@530f243b，可以看到Application ClassLoader的父加载器确实是Extension ClassLoader，这是符合类加载器模型的。
public static void main(String[] args) {
System.out.println(ClassLoader.getSystemClassLoader().getParent().getParent());
}
结果是null。按模型来说，这里的结果应该是Bootstrap ClassLoader，但是结果是null。因为其他的加载器是java写的，在堆中有这些classloader的实例，所以可以打印出来。Bootstrap ClassLoader是c++写的，是jvm的一部分，不属于java，所以在堆中并没有它的对象。
如果classloader的值是null，那么表示对应的classloader是Bootstrap ClassLoader。
反编译一下rt.jar，找到sun.misc.Launcher看一下Application ClassLoader的实现：
static class AppClassLoader extends URLClassLoader
{
public static ClassLoader getAppClassLoader(final ClassLoader paramClassLoader)
throws IOException
{
String str = System.getProperty("java.class.path");//加载的路径
final File[] arrayOfFile = str == null ? new File[0] : Launcher.getClassPath(str);
return (ClassLoader)AccessController.doPrivileged(new PrivilegedAction()
{
public Launcher.AppClassLoader run()
{
URL[] arrayOfURL = this.val$s == null ? new URL[0] : Launcher.pathToURLs(arrayOfFile);
return new Launcher.AppClassLoader(arrayOfURL, paramClassLoader);
}
});
}
也就是说只加载java.class.path里面的class文件
public static void main(String[] args) {
System.out.println(System.getProperty("java.class.path"));
}
结果是 /home/tp/Workspaces/MyEclipse Professional 2014/algorithm/bin
说明Application ClassLoader只能加载bin下的.class文件。
双亲委派模型1.如果一个类加载器收到了类加载的请求，它不会尝试去加载这个类，而是委托给父类加载器去完成。
2.当父类加载器反馈说自己无法完成这个加载请求时，子加载器才会尝试自己去加载。
所以类加载的请求都会被传到启动类加载器中。双亲委派模型对java程序的稳定运作很重要。比如java.lang.Object，存放在rt.jar中，无论任何类加载器去加载这个类最终都是由Bootstrap ClassLoader去加载，那么可以保证Object类在程序的各种类加载器环境中都是
一个类。如果没有双亲委派模型，就会产生多个Object类。那么java应用程序会变得混乱。