类加载之 02 类加载的过程

类加载之 02 类加载的过程

概述

下面按照类加载的顺序来进行说明整个这类加载过程。

1. 加载
2. 连接（验证、准备和解析）
3. 初始化

1. 加载

加载：查找并加载类的二进制数据的过程。

加载的过程描述：

1. 通过类的全限定名定位 .class文件，并获取其二进制字节流。
2. 把字节流所代表的静态存储结构转换为方法区的运行时数据结构。
3. 在 Java堆中生成一个此类的 java.lang.Class对象，作为方法区中这些数据的访问入口。

注意，这里第 1 条中的二进制字节流并不只是单纯地从 Class 文件中获取，比如它还可以从 Jar 包中获取、从网络中获取（最典型的应用便是 Applet）、由其他文件生成（JSP 应用）等。

相对于类加载的其他阶段而言，一个非数组的加载阶段（准确地说，是加载阶段获取类的二进制字节流的动作）是可控性最强的阶段，因为开发人员既可以使用系统提供的类加载器来完成加载，也可以自定义自己的类加载器来完成加载。

加载阶段完成后，虚拟机外部的 二进制字节流就按照虚拟机所需的格式存储在方法区之中，而且在 Java 堆中也创建一个 java.lang.Class 类的对象，这样便可以通过该对象访问方法区中的这些数据。

另外需要主要的是数组类的加载，情况和上面的有所不同，也是要解释为什么数组的加载阶段不如普通的类加载更可控。最重要的一点原因是数组类是由java虚拟机直接创建的。但是数组类的元素类型最终是靠类加载器创建的。一个数组类创建过程遵循一下规则（假定数组C）

1. 如果数组的类型是引用类型，那就递归采用本机定义的加载过程去加载这个类型，并且将数组C和加载此数组类型的加载器绑定到一起。
2. 如果数组的类型不是引用类型，比如int[]，java虚拟机将会把数组C标记为与引导类加载器关联（其实就是启动类加载器BootStrab ClassLoader）。
3. 数组的可见性与他的组件类型（也就是type[] 中type占位符）的可见性一致，如果组件类型不是引用类型，那数组的可见性默认为public。

2. 连接

连接：包括验证、准备、解析三步。

a) 验证

验证：确保被加载的类的正确性。验证是连接阶段的第一步，用于确保 Class字节流中的信息是否符合虚拟机的要求。

具体验证形式：

• 文件格式验证：验证字节流是否符合 Class文件格式的规范；例如：是否以 0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围之内、常量池中的常量是否有不被支持的类型。
• 元数据验证：对字节码描述的信息进行语义分析（注意：对比 javac编译阶段的语义分析），以保证其描述的信息符合 Java 语言规范的要求；例如：这个类是否有父类，除了 java.lang.Object之外。
• 字节码验证：通过数据流和控制流分析，确定程序语义是合法的、符合逻辑的。
• 符号引用验证：确保解析动作能正确执行。这是最后一个阶段的验证，它发生在虚拟机将符号引用转化为直接引用的时候（解析阶段中发生该转化，后面会有讲解），主要是对类自身以外的信息（常量池中的各种符号引用）进行匹配性的校验。

b) 准备

• 准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中分配。对于该阶段有以下几点需要注意：

  • 这时候进行内存分配的仅包括类变量（static），而不包括实例变量，实例变量会在对象实例化时随着对象一块分配在 Java 堆中。
  • 这里所设置的初始值通常情况下是数据类型默认的零值（如 0、0L、null、false 等），而不是被在 Java 代码中被显式地赋予的值。

  假设一个类变量的定义为：

  public static int value = 3；

  那么变量 value 在准备阶段过后的初始值为 0，而不是 3，因为这时候尚未开始执行任何 Java 方法，而把 value 赋值为 3 的 putstatic 指令是在程序编译后，存放于类构造器 （）方法之中的，所以把 value 赋值为 3 的动作将在初始化阶段才会执行。

  如果类字段的字段属性表中存在 ConstantValue 属性，即同时被 final 和 static 修饰，那么在准备阶段变量 value 就会被初始化为 ConstValue 属性所指定的值。

  假设上面的类变量 value 被定义为：

  public static final int value = 3；

  编译时 Javac 将会为 value 生成 ConstantValue 属性，在准备阶段虚拟机就会根据 ConstantValue 的设置将 value 赋值为 3。回忆上一篇博文中对象被动引用的第 2 个例子，便是这种情况。我们可以理解为 static final 常量在编译期就将其结果放入了调用它的类的常量池中。

c) 解析

解析：把类中对常量池内的符号引用转换为直接引用。

解析动作主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符等 7 类符号引用进行。

在 Class 类文件结构一文中已经比较过了符号引用和直接引用的区别和关联，这里不再赘述。前面说解析阶段可能开始于初始化之前，也可能在初始化之后开始，虚拟机会根据需要来判断，到底是在类被加载器加载时就对常量池中的符号引用进行解析（初始化之前），还是等到一个符号引用将要被使用前才去解析它（初始化之后）。

对同一个符号引用进行多次解析请求时很常见的事情，虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标示为已解析状态），从而避免解析动作重复进行。

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池中的 CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info、CONSTANT_InterfaceMethodref_info 四种常量类型。

1、类或接口的解析：判断所要转化成的直接引用是对数组类型，还是普通的对象类型的引用，从而进行不同的解析。

2、字段解析：对字段进行解析时，会先在本类中查找是否包含有简单名称和字段描述符都与目标相匹配的字段，如果有，则查找结束；如果没有，则会按照继承关系从上往下递归搜索该类所实现的各个接口和它们的父接口，还没有，则按照继承关系从上往下递归搜索其父类，直至查找结束，查找流程如下图所示：

从下面一段代码的执行结果中很容易看出来字段解析的搜索顺序：

class Super{  
   public static int m = 11;  
   static{  
       System.out.println("执行了super类静态语句块");  
   }  
}  

class Father extends Super{  
   public static int m = 33;  
   static{  
       System.out.println("执行了父类静态语句块");  
   }  
}  

class Child extends Father{  
   static{  
       System.out.println("执行了子类静态语句块");  
   }  
}  

public class StaticTest{  
   public static void main(String[] args){  
       System.out.println(Child.m);  
   }  
}  

执行结果如下：

执行了super类静态语句块
执行了父类静态语句块
33

如果注释掉 Father 类中对 m 定义的那一行，则输出结果如下：

执行了super类静态语句块
11

另外，很明显这就是上篇博文中的第 1 个例子的情况，这里我们便可以分析如下：static 变量发生在静态解析阶段，也即是初始化之前，此时已经将字段的符号引用转化为了内存引用，也便将它与对应的类关联在了一起，由于在子类中没有查找到与 m 相匹配的字段，那么 m 便不会与子类关联在一起，因此并不会触发子类的初始化。

最后需要注意：理论上是按照上述顺序进行搜索解析，但在实际应用中，虚拟机的编译器实现可能要比上述规范要求的更严格一些。如果有一个同名字段同时出现在该类的接口和父类中，或同时在自己或父类的接口中出现，编译器可能会拒绝编译。如果对上面的代码做些修改，将 Super 改为接口，并将 Child 类继承 Father 类且实现 Super 接口，那么在编译时会报出如下错误：

StaticTest.java:24: 对 m 的引用不明确，Father 中的 变量 m 和 Super 中的 变量 m
都匹配
               System.out.println(Child.m);
                                       ^
1 错误

3、类方法解析：对类方法的解析与对字段解析的搜索步骤差不多，只是多了判断该方法所处的是类还是接口的步骤，而且对类方法的匹配搜索，是先搜索父类，再搜索接口。

4、接口方法解析：与类方法解析步骤类似，只是接口不会有父类，因此，只递归向上搜索父接口就行了。

3. 初始化

初始化是类加载过程的最后一步，到了此阶段，才真正开始执行类中定义的 Java 程序代码。在准备阶段，类变量已经被赋过一次系统要求的初始值，而在初始化阶段，则是根据程序员通过程序指定的主观计划去初始化类变量和其他资源，或者可以从另一个角度来表达：初始化阶段是执行类构造器< cinit >()方法的过程。

这里简单说明下()方法的执行规则:

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

2、< cinit >()方法与实例构造器方法（类的构造函数）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的< cinit>()方法执行之前，父类的< cinit>()方法已经执行完毕。因此，在虚拟机中第一个被执行的< cinit>()方法的类肯定是java.lang.Object。

3、< cinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对类变量的赋值操作，那么编译器可以不为这个类生成< cinit>()方法。

4、接口中不能使用静态语句块，但仍然有类变量（final static）初始化的赋值操作，因此接口与类一样会生成< cinit>()方法。但是接口与类不同的是：执行接口的< cinit>()方法不需要先执行父接口的< cinit>()方法，只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的< cinit>()方法。

5、虚拟机会保证一个类的< cinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的< cinit>()方法，其他线程都需要阻塞等待，直到活动线程执行< cinit>()方法完毕。如果在一个类的()方法中有耗时很长的操作，那就可能造成多个线程阻塞，在实际应用中这种阻塞往往是很隐蔽的。

下面给出一个简单的例子，以便更清晰地说明如上规则：

class Father{  
   public static int a = 1;  
   static{  
       a = 2;  
   }  
}  

class Child extends Father{  
   public static int b = a;  
}  

public class ClinitTest{  
   public static void main(String[] args){  
       System.out.println(Child.b);  
   }  
}  

执行上面的代码，会打印出 2，也就是说 b 的值被赋为了 2。

我们来看得到该结果的步骤。首先在准备阶段为类变量分配内存并设置类变量初始值，这样 A 和 B 均被赋值为默认值 0，而后再在调用()方法时给他们赋予程序中指定的值。当我们调用 Child.b 时，触发 Child 的()方法，根据规则 2，在此之前，要先执行完其父类Father的()方法，又根据规则1，在执行< cinit>()方法时，需要按 static 语句或 static 变量赋值操作等在代码中出现的顺序来执行相关的 static 语句，因此当触发执行 Father的< cinit>()方法时，会先将 a 赋值为 1，再执行 static 语句块中语句，将 a 赋值为 2，而后再执行 Child 类的< cinit>()方法，这样便会将 b 的赋值为 2。

如果我们颠倒一下 Father 类中“public static int a = 1;”语句和“static语句块”的顺序，程序执行后，则会打印出1。很明显是根据规则 1，执行 Father 的()方法时，根据顺序先执行了 static 语句块中的内容，后执行了“public static int a = 1;”语句。

另外，在颠倒二者的顺序之后，如果在 static 语句块中对 a 进行访问（比如将 a 赋给某个变量），在编译时将会报错，因为根据规则 1，它只能对 a 进行赋值，而不能访问。

下面的代码演示类的静态字段初始化是线程安全的demo

package action;

public class  Test{
 static class DeadLoopClass {
   static {
     if (true){
       System.out.println(Thread.currentThread() + "init DeadLoopClass");
       while (true){

       }
     }
   }

 }

 public static void main(String[] args) {
   Runnable script = new Runnable() {
     @Override
     public void run() {
       System.out.println(Thread.currentThread() + " start");
       DeadLoopClass dlc= new DeadLoopClass();
       System.out.println(Thread.currentThread() + " run over");
     }
   };
   Thread thread1 = new Thread(script);
   Thread thread2 = new Thread(script);
   thread1.start();
   thread2.start();
 }
}

运行结果

Thread[Thread-0,5,main] start
Thread[Thread-0,5,main]init DeadLoopClass
Thread[Thread-1,5,main] start

分析：上面只打印一次init DeadLoopClass说明这段static代码段只运行了一次，并且阻塞了整个程序的运行。因此要防止在静态代码段中有花费大量时间的代码。