Java基础-类加载顺序

类加载过程

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：加载（Loading）、验证（Verification）、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)和卸载(Unloading)7个阶段。其中准备、验证、解析3个部分统称为连接（Linking）。如图所示。

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照这种顺序按部就班地开始，而解析阶段则不一定：它在某些情况下可以在初始化阶段之后再开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。以下陈述的内容都已HotSpot为基准。

加载

在加载阶段（可以参考java.lang.ClassLoader的loadClass()方法），虚拟机需要完成以下3件事情：

1. 通过一个类的全限定名来获取定义此类的二进制字节流（并没有指明要从一个Class文件中获取，可以从其他渠道，譬如：网络、动态生成、数据库等）；
2. 将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构；
3. 在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的访问入口；

加载阶段和连接阶段（Linking）的部分内容（如一部分字节码文件格式验证动作）是交叉进行的，加载阶段尚未完成，连接阶段可能已经开始，但这些夹在加载阶段之中进行的动作，仍然属于连接阶段的内容，这两个阶段的开始时间仍然保持着固定的先后顺序。

验证

验证是连接阶段的第一步，这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
验证阶段大致会完成4个阶段的检验动作：

1. 文件格式验证：验证字节流是否符合Class文件格式的规范；例如：是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
2. 元数据验证：对字节码描述的信息进行语义分析（注意：对比javac编译阶段的语义分析），以保证其描述的信息符合Java语言规范的要求；例如：这个类是否有父类，除了java.lang.Object之外。
3. 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
4. 符号引用验证：确保解析动作能正确执行。

验证阶段是非常重要的，但不是必须的，它对程序运行期没有影响，如果所引用的类经过反复验证，那么可以考虑采用-Xverifynone参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在堆中。其次，这里所说的初始值“通常情况”下是数据类型的零值，假设一个类变量的定义为：

1	public static int value= 123 ;

那变量value在准备阶段过后的初始值为0而不是123.因为这时候尚未开始执行任何java方法，而把value赋值为123的putstatic指令是程序被编译后，存放于类构造器()方法之中，所以把value赋值为123的动作将在初始化阶段才会执行。
至于“特殊情况”是指：public static final int value=123，即当类字段的字段属性是ConstantValue时，会在准备阶段初始化为指定的值，所以标注为final之后，value的值在准备阶段初始化为123而非0.

解析

解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。

初始化

类初始化阶段是类加载过程的最后一步，到了初始化阶段，才真正开始执行类中定义的java程序代码。在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序猿通过程序制定的主管计划去初始化类变量和其他资源，或者说：初始化阶段是执行类构造器<clinit>()方法的过程.
<clinit>()方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块static{}中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问。如下：

1 2 3 4 5 6 7 8 9

public class Test {      static      {          i= 0 ;          System.out.println(i); //这句编译器会报错：Cannot reference a field before it is defined（非法向前应用）      }      static int i= 1 ; }

<clinit>()方法与实例构造器<init>()方法不同，它不需要显示地调用父类构造器，虚拟机会保证在子类<init>()方法执行之前，父类的<clinit>()方法方法已经执行完毕。
由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。
<clinit>()方法对于类或者接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生产<clinit>()方法。
接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法。但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。

初始化顺序

先假设一个类，各组成都有，那么他的初始化顺序是

1. 初始化类变量（即static修饰的成员变量），并未赋值。不管写的位置在哪里，只要是类变量，系统总会先找到它进行变量初始化。
2. 执行静态代码块和类变量定义式，两者根据写的位置来决定先后，先写先执行。其实从某种角度上看，可以把类变量定义赋值视为两部分：一部分是定义变量，一部分赋值。而这个赋值部分可以看做是一个静态代码块。两个静态代码块的执行顺序自然是看写的位置的先后了。
3. 初始化实例变量（即未被static修饰的成员变量），并未赋值。同样的，不管写的位置在哪里，在创建对象时执行到这步时，系统总会找到它进行变量初始化。
4. 执行构造代码块和实例变量定义赋值式，两者同样根据写的位置先后来决定执行顺序先后，同样可以按2中所写来理解。但是，这里要注意的就是构造代码块是可以调用静态变量的，实例变量定义赋值式可以看做是只对实例变量进行赋值的构造代码块。
5. 执行构造函数。构造函数同样可以调用静态变量和实例变量。 
   初始化结束。 
   
   关于这个初始化顺序，其实一句话可以概括： 
   先初始化类变量然后赋值，再初始化实例变量然后赋值。 
   由于静态代码块可以调用静态变量，构造代码块和构造函数可以调用实例变量和静态变量，这块很容易来个看似复杂的代码，将一个变量变来变去的，弄明白这个初始化顺序就会解决很快了。 
   接下来，看几个例子来验证下： 
   第一个：

public class JustForTest {
    public static void main(String[] args) {
        Car c=new Car();
        sop("i="+c.i);
    }
     static void sop(Object obj){
        System.out.println(obj);
    }
}

class Car{
    static int i=1;   //定义赋值
    static {          //静态代码块
        i=4;
    }   
}
运行结果为:i=4.
只改写Car的内部，让静态代码块和静态变量的定义赋值互换位置，其他保持不变：
class Car{
    static {          //静态代码块
        i=4;
    }
    static int i=1;   //定义赋值    
}
运行结果为：i=1.
最后来个综合点的，把Car再改写一下：
class Car{
  static int i=1;     //静态变量定义赋值
  Car(){             //构造函数
  i=2;
  }
  static {          //静态代码块
        i=4;
    }
    {           //构造代码块
       i=3;
    }
}
运行结果是：i=2.
按初始化顺序，构造函数是最后初始化的。

如果存在继承的关系时：

属性、方法、构造方法和自由块都是类中的成员，在创建类的对象时，类中各成员的执行顺序：
1.父类静态成员和静态初始化快，按在代码中出现的顺序依次执行。
2.子类静态成员和静态初始化块，按在代码中出现的顺序依次执行。
3. 父类的实例成员和实例初始化块，按在代码中出现的顺序依次执行。
4.执行父类的构造方法。
5.子类实例成员和实例初始化块，按在代码中出现的顺序依次执行。
6.执行子类的构造方法