之前的《JVM类加载机制-ClassLoader》和《初探JVM-ClassLoader源码》，只是讨论了Class的加载部分，现在来纵观一下整个Class的生命周期。
Class的生命周期就是指一个class文件（字节码）从加载到卸载的全过程。
当一个类被装载、连接、初始化后，它的生命周期就开始了，当代表该类的Class对象不再被引用、即已经不可触及的时候，Class对象的生命周期结束。那么该类的方法区内的数据也会被卸载，从而结束该类的生命周期。
一个类的生命周期取决于它Class对象的生命周期，经历加载、连接、初始化、使用、和卸载五个阶段。
类的加载（Load Class）包含了以下三个步骤：
查找Class的二进制文件（.class），把类的信息加载到JVM的方法区中，对其进行部分检验（类文件的魔数，文件长度，是否有父类等）；在堆区中实例化一个java.lang.Class对象，作为方法区中这个类的信息的入口。
加载方式有多种：A. 在classPath下找相应class文件；B. 从jar文件中读取；C. 从网络中获取；D. 实时生成，如设计模式中的动态代理模式；E. 从非class文件中获取，这些文件在jvm中运行之前也会被转换为可识别的字节码文件。
一般来说加载和连接是同步的，但有时候也会交叉进行，但是两者的开始和结束是顺序的。
将对应的字节码文件读入到JVM中（其中解析步骤是可以选择的）
a) 验证
检查载入的class文件数据的合法性：字节码的格式，变量与方法是否重复、数据类型是否有效、继承与实现是否合法，接入属性是否正确（public ,private的问题），检查 final class 有没有被继承，检查静态变量的正确性等等。
b) 准备
给类的静态变量分配存储空间：赋default值（基本类型为0，引用为null），静态常量（如final static int a = 100），但不会对其进行初始化，不会执行任何 Java 代码（static块）。
c) 解析：
将符号引用转成直接引用，完成内存结构的布局。
例如我们要调用Collections.toString()，java.util.Collections.toString()就是符号引用，而直接引用就是这个方法在方法区中的内存地址。解析就是把类、接口、方法、成员变量的符号引用转换成内存地址，以供调用。
在连接阶段完成后，再根据使用的情况（直接引用or被动引用）来决定是否类进行初始化。
对静态变量赋assign值，执行静态代码块。 【类的初始化顺序可以参考我的《类的初始化&实例化顺序》】
在Java中类的引用分为直接引用和被动引用，只有直接引用，会触发类的初始化：
a) new实例化对象；b) 使用类的（非常量）静态变量 / 方法；c) 通过反射执行前三种情况；d) 子类被初始化；e) 作为程序入口，调用main（也是调用静态方法的一种）。
其他使用类的方式都叫被动引用，如：
a) 定义类数组；b) 引用类的静态常量；c) 引用父类的静态域，只会触发父类的初始化，而不会触发子类的初始化。
从上面能看出，初始化的原则是，只初始化要用到的。在主动引用中，实例化(new/main)、使用静态域都是被用到了；而子类依赖了父类，所以也会触发初始化。在被动引用中，a中的类型只是用于编译器的校验，而b中的静态常量是在链接中的准备阶段已经完成了，所以两者都用不上去初始化；另外c中只用到了父类的静态域，所以就没必要触发子类。
public class LoaderLazy {
publicstatic String HELLO = "Hello";
static{
System.out.println("Init parent");
}
class SubLoaderLazy extends LoaderLazy{
static{
System.out.println("Init sub");
}
}
System.out.println(SubLoaderLazy.HELLO);
console：
Init parent
能看出上面只初始化了父类。那如果我们把HELLO属性放在子类SubLoaderLazy中，子类也会被初始化。
console：
Init parent
Init sub
类的初始化完成后，我们就可以创建对象实例了。
相比初始化只执行类的静态域（静态变量/代码块），类的实例化是执行类的实例域（非静态变量/代码块）和构造函数，并且在堆区创建一个类的实例对象。
（在实例化时，如果没有指定构造函数，JVM会自动构造一个无参构造函数。）
类的实例化，一般在使用new创建对象，或者Class.newInstance()时执行。
【类的实例化顺序可以参考我的《类的初始化&实例化顺序》】
Class作为JVM中的一个特殊对象，也会被GC回收卸载。
Class的卸载就是清空方法区中Class的信息和堆区中的java.lang.Class对象。这时Class的声明周期就结束了。
SUN的原话：“class or interface may be unloaded if andonly if its class loader is unreachable. Classesloaded by the BootstrapClassLoadermay not be unloaded”。
Class被回收要满足以下三个条件:
a) No Instance：该类所有的实例都已经被GC;
b) No ClassLoader：加载该类的ClassLoader实例已经被GC;
c) No Reference：该类的java.lang.Class对象没有被引用。(XXX.class, 静态变量/方法)
另外，有些Class是不会被回收的：
1、根据JVM和JLS的规范，由Bootstrap类加载器加载的Class在整个运行期间是不会被卸载的。
2、被Extension类加载器 和System类加载器加载的Class在运行期间不太可能被卸载，因为这些实例基本上在整个运行期间总能直接或者间接的访问的到，其达到unreachable的可能性极小。
3、开发者自定义的类加载器加载的Class只有在很简单的上下文环境中才能被卸载，稍微复杂点的应用场景中，很难有符合上面3个条件的Class。
综合以上三点，一个已经加载的Class被卸载的几率很小；而且卸载时间也是不可控的。而且Class占用的内存空间不大，一般不用考虑。
参考博客 http://blog.csdn.net/biaobiaoqi/article/details/6909141
原文：http://blog.csdn.net/tiwerbao/article/details/41177419