1、类的生命周期

2、虚拟机规范严格控制规定了有且只有四种情况必须立即对类进行“初始化”（而加载、验证、准备自然需要在这些之前开始）。

   （1）使用new关键字实例化对象、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）、以及调用一个类的静态方法的时候。更严格的说，是遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，如果类没有进行初始化，则需要先触发其初始化；

   （2）使用java.lang.reflect包的方法对类进行反射调用的时候，如果类没有进行过初始化，则需要先触发其初始化；

   （3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化；

   （4）当虚拟机启动时，用户需要指定一个要执行的主类（包括main方法的那个类），虚拟机会先初始化这个主类。

    注意，接口的情况并不适合第三种情况。即一个接口在初始化时，并不要求其父接口全部都完成初始化了，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

3、加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，然后在Java堆中实例化一个java.lang.Class类的对象，这个对象将作为程序访问方法区中的这些类型数据的外部接口。  P177

4、准备阶段（P181）           

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。注意，这里的类变量是指被static修饰的变量，不包括实例变量 （实例变量分配在堆中）。

类变量有两种：

    (1) public static int value = 123；那么变量value在准备阶段之后的初始值是0，因为此时尚未执行任何java方法，赋值123是在初始化阶段才执行的;

   （2）public static final int value = 123；那么编译时会为value生成ConstantValue属性，准备阶段就会赋值为123。

    即：变量有两次赋初值的过程：一次在准备阶段，赋予系统初始值；一次在初始化阶段，赋予程序员定义的初始值。

5、初始化：

   <clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，收集的顺序由语句在源文件中出现的顺序决定的。静态语句块中只能访问到定义在静态语句块之前的变量，定义在其后的变量可以赋值，但不能访问。

   <clinit>()方法无须显示地调用父类构造器，虚拟机会保证父类的方法在子类的方法前面执行。因此第一个被执行的<clinit>()方法的类是Object。因此，父类中定义的静态语句块会优先于子类的变量赋值操作。

执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法，接口的实现类也不会先执行接口的<clinit>()方法。只有当父接口中定义的变量被使用时，父接口才会被初始化。

虚拟机会保证一个类的<clinit>()方法在多线程中被正确的加锁和同步。如果在一个类的<clinit>()方法中有耗时很少的操作，可能造成多个线程阻塞。

6、对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。“相等”也只有在同一个类加载器的前提之下才有意义。（这里的“相等”包括代表Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果）。

7、类加载的双亲委派模型：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是指把这个请求委派给父类加载器去加载，直到最顶层的Bootstrap ClassLoader。

该模型解决了：各个加载器的基础类的统一问题（越基础的类由越上层的加载器进行加载）。如类java.lang.Object，无论哪一个类加载器要加载这个类，最终都是委派给启动类加载器进行加载，所以在程序的各种类加载器环境中都是同一个类。

为了解决使用Bootstrap ClassLoader的类需要调用用户的代码（如JNDI、JDBC、JCE等SPI）的问题，Java设计团队引入了线程上下文类加载器（Thread Context ClassLoader）。如果创建线程时还未设置，那么会从父线程中继承；如果应用程序的全局范围内都没有设置过，这个类加载器默认就是应用程序类加载器。

注意：类加载的双亲委派模板并不是一个强制性的约束。