Jvm（56），虚拟机类加载机制----类加载的过程----初始化

类初始化阶段是类加载过程的最后一步，前面的类加载过程中，除了在加载阶段用户应用程序可以通过自定义类加载器参与之外，其余动作完全由虚拟机主导和控制。到了初始化阶段，才真正开始执行类中定义的Java程序代码（或者说是字节码）。

在准备阶段，变量已经赋过一次系统要求的初始值，而在初始化阶段，则根据程序员通过程序制定的主观计划去初始化类变量和其他资源，或者可以从另外一个角度来表达：初始化阶段是

执行类构造器＜clinit＞（）方法的过程。我们在下文会讲解＜clinit＞（）方法是怎么生成的，在这里，我们先看一下＜clinit＞（）方法执行过程中一些可能会影响程序运行行为的特点和细节，这部分相对更贴近于普通的程序开发人员。

上面的意思就是说在初始化的时候，也就是在编译的时候变量已经有初始值了，而不是运行的时候，这个时候我们也能更加亲切的看到常量都是在编译的时候已经有值了，所以它是不可以变更的。

＜clinit＞（）方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{} 块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块可以赋值，但是不能访问，如代码清单7-5中的例子所示。

public class Test {

static {

i = 0;// 给变量赋值可以正常编译通过

System.out.print(i);// 这句编译器会提示"非法向前引用"

}

static int i = 1;

 

}

＜clinit＞（）方法与类的构造函数（或者说实例构造器＜init＞（）方法）不同，它不需要显式地调用父类构造器，虚拟机会保证在子类的＜clinit＞（）方法执行之前，父类的＜clinit＞（）

方法已经执行完毕。因此在虚拟机中第一个被执行的＜clinit＞（）方法的类肯定是java.lang.Object。

注意这里这里说的初始化的范围比构造方法的初始化的范围要宽泛好多，这里说的初始化主要有静态代码块，静态的变量，它发生在构造方法之前，原因就是我们前面所说的，当虚拟机在准备阶段的时候就把静态的数据放到方法区中（常量池）了。

由于父类的＜clinit＞（）方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。看下面的代码。

package demo.jvm.test6;

 

public class Parent {

public static int A = 1;//第一步

static {

A = 2;//第二步，把2赋值给A了

}

 

static class Sub extends Parent {

public static int B = A;//现在B值就是2了

}

 

public static void main(String[] args) {

System.out.println(Sub.B);

}

}

结果是2

＜clinit＞（）方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成＜clinit＞（）方法。

接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成＜

clinit＞（）方法。但接口与类不同的是，执行接口的＜clinit＞（）方法不需要先执行父接口的＜clinit＞（）方法。只有当父接口中定义的变量使用时，父接口才会初始化。另外，接口的实现类在初始化时也一样不会执行接口的＜clinit＞（）方法。

多线程的初始化；

虚拟机会保证一个类的＜clinit＞（）方法在多线程环境中被正确地加锁、同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的＜clinit＞（）方法，其他线程都需要阻塞等待，直到活动线程执行＜clinit＞（）方法完毕。如果在一个类的＜clinit＞（）方法中

有耗时很长的操作，就可能造成多个进程阻塞[2]，在实际应用中这种阻塞往往是很隐蔽的。

例如:

package demo.jvm.test6;   import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors;   class DeadLoopClass { static class Hello { static { System.out.println(Thread.currentThread() + "我现在在类的初始化的过程"); try { Thread.sleep(5000); } catch (InterruptedException e) { // TODO Auto­generated catch block e.printStackTrace(); } } }   public static void main(String[] args) { ExecutorService threatpool = Executors.newFixedThreadPool(20); int i = 0;

pool­1­thread­6­­­结束 pool­1­thread­9­­­结束 pool­1­thread­5­­­结束 pool­1­thread­4­­­结束 pool­1­thread­7­­­结束 pool­1­thread­1­­­结束 pool­1­thread­12­­­结束 pool­1­thread­2­­­结束 pool­1­thread­10­­­结束 pool­1­thread­14­­­结束 pool­1­thread­11­­­结束 pool­1­thread­13­­­结束 pool­1­thread­15­­­结束 pool­1­thread­16­­­结束 pool­1­thread­17­­­结束 pool­1­thread­19­­­结束 pool­1­thread­18­­­结束 pool­1­thread­20­­­结束 pool­1­thread­8­­­结束

从上面的例子我们可以看到在初始化的过程中是会加锁的，是线程安全的。相当于加了一个 sychronized的锁。

但是一旦在初始化的过程中出现阻塞，那么整个过程都会出现阻塞的情况，我们来看下面的案例。

package demo.jvm.test6;   import java.lang.reflect.Executable; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors;   import demo.jvm.test6.DeadLoopClass.Hello;   class DeadLoopClass2 { static class Hello { static { if (true) {

pool­1­thread­14­­­开始 pool­1­thread­12­­­开始 Thread[pool­1­thread­5,5,main]我现在在类的初始化的过程 pool­1­thread­13­­­开始 pool­1­thread­15­­­开始 pool­1­thread­16­­­开始 pool­1­thread­20­­­开始 pool­1­thread­17­­­开始 pool­1­thread­19­­­开始 pool­1­thread­18­­­开始 //在这里我们可以看到线程就一直阻塞在这了。因为代码被锁死在初始化的代码块中了。

ll