1、类加载时机:java
一、类初始化时机程序员
1)遇到new、getstatic、putstatic或invokestatic这四个字节码指令时,若是类没有进行过初始化,则须要先对其进行初始化。数据库
2)使用Java.lang.reflect包的方法对类进行反射调用的时候,若是类没有进行过初始化,则须要先出发器初始化。数组
3)当初始化一个类的时候,若是发现其父类尚未进行过初始化,则须要先触发其父类的初始化安全
4)当虚拟机启动时,用户须要制定一个执行的主类,虚拟机会先初始化这个主类网络
5)当使用jdk1.7动态语言支持时,若是一个Java.lang.invoke.MethodHandle实例最后的解析结果REF_getstatic,REF_putstatic,REF_invokestatic的方法句柄,而且这个方法句柄所对应的类没有进行初始化,则须要先出发其初始化。数据结构
2.被动引用的几种经典的场景多线程
1)经过子类引用父类的静态字段,不会致使子类初始化oop
2)经过数组定义来引用类,不会触发此类的初始化线程
3)常量在编译阶段会存入调用类的常量池中,本质上并无直接引用到定义量的类,所以不会触发定义常量的类初始化。
3、类加载的过程
一、加载(Loading) 在加载阶段(能够参考java.lang.ClassLoader的loadClass()方法),虚拟机须要完成如下三件事情: (1). 经过一个类的全限定名来获取定义此类的二进制字节流(并无指明要从一个Class文件中获取,能够从其余渠道,譬如:网络、动态生成、数据库等); (2). 将这个字节流所表明的静态存储结构转化为方法区的运行时数据结构; (3). 在内存中(对于HotSpot虚拟就而言就是方法区)生成一个表明这个类的java.lang.Class对象,做为方法区这个类的各类数据的访问入口; 加载阶段和链接阶段(Linking)的部份内容(如一部分字节码文件格式验证动做)是交叉进行的,加载阶段还没有完成,链接阶段可能已经开始,但这些夹在加载阶段之中进行的动做,仍然属于链接阶段的内容,这两个阶段的开始时间仍然保持着固定的前后顺序。 特别地,第一件事情(经过一个类的全限定名来获取定义此类的二进制字节流)是由类加载器完成的,具体涉及JVM预约义的类加载器、双亲委派模型等内容,详情请参见个人转载博文《深刻理解Java类加载器(一):Java类加载原理解析》中的说明,此不赘述。二、验证(Verification) 验证是链接阶段的第一步,这一阶段的目的是为了确保Class文件的字节流中包含的信息符合当前虚拟机的要求,而且不会危害虚拟机自身的安全。 验证阶段大体会完成4个阶段的检验动做:文件格式验证:验证字节流是否符合Class文件格式的规范(例如,是否以魔术0xCAFEBABE开头、主次版本号是否在当前虚拟机的处理范围以内、常量池中的常量是否有不被支持的类型)元数据验证:对字节码描述的信息进行语义分析,以保证其描述的信息符合Java语言规范的要求(例如:这个类是否有父类,除了java.lang.Object以外);字节码验证:经过数据流和控制流分析,肯定程序语义是合法的、符合逻辑的;符号引用验证:确保解析动做能正确执行。 验证阶段是很是重要的,但不是必须的,它对程序运行期没有影响。若是所引用的类通过反复验证,那么能够考虑采用-Xverifynone参数来关闭大部分的类验证措施,以缩短虚拟机类加载的时间。三、准备(Preparation) 准备阶段是正式为类变量(static 成员变量)分配内存并设置类变量初始值(零值)的阶段,这些变量所使用的内存都将在方法区中进行分配。这时候进行内存分配的仅包括类变量,而不包括实例变量,实例变量将会在对象实例化时随着对象一块儿分配在堆中。其次,这里所说的初始值“一般状况”下是数据类型的零值,假设一个类变量的定义为:public static int value = 123; 那么,变量value在准备阶段事后的值为0而不是123。由于这时候还没有开始执行任何java方法,而把value赋值为123的putstatic指令是程序被编译后,存放于类构造器方法<clinit>()之中,因此把value赋值为123的动做将在初始化阶段才会执行。至于“特殊状况”是指:当类字段的字段属性是ConstantValue时,会在准备阶段初始化为指定的值,因此标注为final以后,value的值在准备阶段初始化为123而非0。 public static final int value = 123;四、解析(Resolution) 解析阶段是虚拟机将常量池内的符号引用替换为直接引用的过程。解析动做主要针对类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符7类符号引用进行。五、初始化(Initialization) 类初始化阶段是类加载过程的最后一步。在前面的类加载过程当中,除了在加载阶段用户应用程序能够经过自定义类加载器参与以外,其他动做彻底由虚拟机主导和控制。到了初始化阶段,才真正开始执行类中定义的java程序代码(字节码)。 在准备阶段,变量已经赋过一次系统要求的初始值(零值);而在初始化阶段,则根据程序猿经过程序制定的主观计划去初始化类变量和其余资源,或者更直接地说:初始化阶段是执行类构造器<clinit>()方法的过程。<clinit>()方法是由编译器自动收集类中的全部类变量的赋值动做和静态语句块static{}中的语句合并产生的,编译器收集的顺序是由语句在源文件中出现的顺序所决定的,静态语句块只能访问到定义在静态语句块以前的变量,定义在它以后的变量,在前面的静态语句块能够赋值,可是不能访问。以下:public class Test{static{i=0;System.out.println(i);//Error:Cannot reference a field before it is defined(非法向前应用)}static int i=1;} 那么注释报错的那行代码,改为下面情形,程序就能够编译经过并能够正常运行了。public class Test{static{i=0;//System.out.println(i);}static int i=1;public static void main(String args[]){System.out.println(i);}}/* Output:1*///:~ 类构造器<clinit>()与实例构造器<init>()不一样,它不须要程序员进行显式调用,虚拟机会保证在子类类构造器<clinit>()执行以前,父类的类构造<clinit>()执行完毕。因为父类的构造器<clinit>()先执行,也就意味着父类中定义的静态语句块/静态变量的初始化要优先于子类的静态语句块/静态变量的初始化执行。特别地,类构造器<clinit>()对于类或者接口来讲并非必需的,若是一个类中没有静态语句块,也没有对类变量的赋值操做,那么编译器能够不为这个类生产类构造器<clinit>()。 虚拟机会保证一个类的类构造器<clinit>()在多线程环境中被正确的加锁、同步,若是多个线程同时去初始化一个类,那么只会有一个线程去执行这个类的类构造器<clinit>(),其余线程都须要阻塞等待,直到活动线程执行<clinit>()方法完毕。特别须要注意的是,在这种情形下,其余线程虽然会被阻塞,但若是执行<clinit>()方法的那条线程退出后,其余线程在唤醒以后不会再次进入/执行<clinit>()方法,由于 在同一个类加载器下,一个类型只会被初始化一次。若是在一个类的<clinit>()方法中有耗时很长的操做,就可能形成多个线程阻塞,在实际应用中这种阻塞每每是隐藏的,以下所示:public class DealLoopTest {static{System.out.println("DealLoopTest...");}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() { // 匿名内部类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();}}/* Output:DealLoopTest...Thread[Thread-1,5,main] startThread[Thread-0,5,main] startThread[Thread-1,5,main]init DeadLoopClass*///:~ 如上述代码所示,在初始化DeadLoopClass类时,线程Thread-1获得执行并在执行这个类的类构造器<clinit>() 时,因为该方法包含一个死循环,所以久久不能退出。