跳至主要內容

JVM (二) 类加载的时机及其过程

安图新大约 9 分钟

JVM (二) 类加载的时机及其过程

类从被加载到虚拟机内存中开始,到卸载出内存为止,它的的整个生命周期包括:

加载(Loading),验证(Verification),准备(Preparation),解析(Resolution),初始化(Initialization),使用(Using)和卸载(Unloading)七个阶段。

其中验证,准备,解析三个阶段统称为链接(Linking),七个阶段发生的顺序如图所示:

 
 

加载,验证,解析,初始化,卸载这个 5 个阶段的顺序是确定的,类的加载过程必须按照这种顺序按部就班的开始,而解析阶段不一定:它在某些情况下可以在初始化阶段之后再开始,这是为了支持 Java 语言的运行时绑定(动态绑定或晚期绑定)。注意上面的顺序只是按部就班的"开始",不是“进行”或“完成”,强调这点是因为这些阶段通常都是互相交叉地混合式进行的,通常会在一个阶段执行的过程中调用,激活另外一个阶段。

初始化的过程:

什么情况下开始类加载的第一个阶段:加载? Java 虚拟机规范中并没有强制约束,可以由虚拟机实现者来把握。但是对于初始化阶段,虚拟机规范中有严格规定。有且只有 5 种情况必须立即对类进行"初始化"(而加载,验证,准备自然需要在此之前开始)

1)遇到 new,getstatic,putstatic 或 invokestatic 这 4 条字节码指令时,如果类没有进行过初始化,则需要先触发其初始化。

生成这 4 条指令的最常见的 Java 代码场景是:使用 new 关键字实例化对象的时候,读取或设置一个类的静态字段(被 final 修饰,已在编译期把结果放入常量池的静态字段除外)的时候,以及调用一个类的静态方法的时候。

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

3)当初始化一个类的时候,如果发现其父类还未初始化,则需要先触发父类初始化。

4)当虚拟机启动时,用户需要指定一个要执行的主类(包含 main 函数),虚拟机会先初始化这个主类。

5)当使用 JDK 1.7 的动态语言支持时,如果一个 java.lang.invoke.MethodHandle 实例最后的解析结果 REF_getStatic,REF_putStatic,REF_invokeStatic 的方法句柄,并且这个方法句柄所对应的类没有进行过初始化,则需要先触发其初始化。

以上 5 中场景的行为成为对一个类的主动引用。除此之外,所有类的方法都不会触发初始化成为被动引用。

我们说明集中常见的看似会初始化其实并没有初始化的情况:

1:子类引用父类的静态字段,不会触发子类的初始化会触发父类的初始化,而且是触发的是静态代码块的执行,非静态代码块不会执行。

2:子类引用子类的静态字段,会先触发父类的静态代码块执行,再执行自身的静态代码块,非静态代码块不会执行。

3:父类中的静态字段被子类重写,然后通过子类调用这个字段也不会触发子类的初始化。

4:静态属性的初始化顺序和在类中的定义顺序是一致的。比如下面的这个例子:

输出的结果是 :1,1。、

实例化的时候 val1 和 val2 都是 0 开始的。
 

静态变量可以在定义前进行赋值,但是不能在定义前使用。记住非静态代码块是在实例化的时候才会执行。

接口和类初始化不同

接口中不能使用静态代码块,但是仍然有变量初始化的赋值操作,因此接口与类一样都会生成<clinit>方法,只有当父接口中定义的变量使用时,接口才会初始化。

另外,接口的实现类在初始化的时候也一样不会执行接口的<clinit>方法。

实例化过程:

实例化过程中类不仅会初始化还会执行其他的非静态代码块,那么父子类之间的调用顺序又是怎样的呢?

   

public class SupperClass {
    public static int parent=2;
    {
        System.out.println("父类非静态代码块  前");
    }
    static {
        System.out.println("父类静态代码块");
    }
    {
        System.out.println("父类非静态代码块 后");
    }
    public SupperClass () {
        System.out.println("你好父类");
    }

}

父类

   

public class ChildClass extends SupperClass{
          public static  int  child=5;
          {
              System.out.println("子类非静态代码块  前");
          }
          static {
              System.out.println("子类静态代码块");
          }
          {
              System.out.println("子类非静态代码块 后");
          }
          public ChildClass() {
              System.out.println("测试子类");

          }
}

子类

测试代码:

new ChildClass();
 
 

可以看出执行顺序:父类静态代码块>子类静态代码块>父类非静态代码块>父类的构造函数>子类的非静态代码块>子类的构造函数

类加载的过程:

加载:

加载是类加载过程的一个阶段,在加载过程中,虚拟机需要完成以下三件事:

1)通过一个类的全限定名来获取定义此类的二进制字节流。

2)将这个字节流所代表的静态存储结构转化为方法区的运行时数据结构。

3)在内存中生成一个代表这个类的 java.lang.Class 对象,作为方法区这个类的各种数据的访问入口。

虚拟机规范中对这个三个步骤并没有具体要求,可以由虚拟机自由实现,这也是类加载过程中可以让程序员自由发挥最大的一个阶段。

比如:(1)从 zip 包获取,常见的从 jar,EAR 包,WAR 包中获取。(2)从网络中获取,例如 Applet。(3)运行时生成,比如动态代理。(4)其他文件生成,典型场景是 JSP。

验证:

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

这个阶段是个很严谨的阶段,大致包含四个检验动作:文件格式验证,元数据验证,字节码验证,符号引用验证。

准备:

准备阶段是正式为类变量(被 static 修饰的变量,不是对象实例的变量)分配内存并设置变量初始值的阶段,这些变量所使用的内存都将在方法区中进行分配。实例变量将在对象实例化时随着对象一起分配在 Java 堆上。

解析:

解析是虚拟机将常量池内的符号引用替换为直接引用的过程。

**符号引用:**以一组符号来描述所引用的的目标,符号可以是任何形式的字面量,只要使用事能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关,引用的目标不一定已经加载到内存中了。各种虚拟机实现的内存布局可以各不相同,但是他们能接受的符号引用必须是一致的,因为符号引用的字面量形式明确定义在 Java 虚拟机规范的 Class 文件格式中。

**直接引用:**直接引用可以是在直接指向目标的指针,相对偏移量或者是一个能间接定位到目标的句柄。直接引用和虚拟机实现的内存布局相关的,同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用,那引用的目标必定已经在内存中了。

初始化:

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

在准备阶段,变量已经赋值过一次初始值,而在初始化阶段,则根据程序员通过程序制定的主观计划去初始化类变量和其他资源。初始化阶段就是执行类构造器<clinit>()方法的过程。

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

关于父子之间的静态代码块执行顺序参见上面的论述。

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

接口中不能使用静态代码块,但是仍然有变量初始化的赋值操作,因此接口与类一样都会生成<clinit>()方法。但是接口和类不同的是,执行接口的<clinit>()方法不需要先执行父类接口的<clinit>()方法。只有当父接口中定义的变量使用时,父接口才会初始化。另外接口的实现类在初始化时也一样不会执行接口的<clinit>()方法。

注意:

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

上次编辑于:
贡献者: Andy