深刻了解Java虚拟机（3-1）虚拟机类加载机制

 

虚拟机类加载机制

1、类加载的阶段和时机

　　1.阶段

　　　　　　整个生命周期包括：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）7个阶段。

　　　　　　其中验证、准备、解析3个部分统称为链接（Linking），

　　2.类加载时机

　　　　　　1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，若是类没有进行过初始化，则须要先触发其初始化。

　　　　　　　　经常使用：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

　　　　　　2）使用java.lang.reflect包的方法对类进行反射调用的时候，若是类没有进行过初始化，则须要先触发其初始化。

　　　　　　3）当初始化一个类的时候，若是发现其父类尚未进行过初始化，则须要先触发其父类的初始化（接口除外）。

　　　　　　4）当虚拟机启动时，用户须要指定一个要执行的主类（包含main（）方法的那个类），虚拟机会先初始化这个主类。

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

　　　　例子

　　　　　　1.对于静态字段，只有直接定义这个字段的类才会被初始化，所以经过其子类来引用父类中定义的静态字段，只会触发父类的初始化而不会触发子类的初始化

package org.fenixsoft.classloading；
/**
*被动使用类字段演示一：
*经过子类引用父类的静态字段，不会致使子类初始化
**/
public class SuperClass{
    static{
        System.out.println（"SuperClass init！"）；
    }
    public static int value=123；
}

public class SubClass extends SuperClass{
    static{
        System.out.println（"SubClass init！"）；
    }
}
/*
**
*非主动使用类字段演示
**/
public class NotInitialization{
    public static void main（String[]args）{
        System.out.println（SubClass.value）；
    }
}

 

　　　　　　2.类的数组类型

package org.fenixsoft.classloading；
/**
*被动使用类字段演示二：
*经过数组定义来引用类，不会触发此类的初始化
*虚拟机会初始化一个[SuperClass的数组类，由虚拟机自动产生，经过执行newarray字节码
**/
public class NotInitialization{
    public static void main（String[]args）{
        SuperClass[]sca=new SuperClass[10]；
    }
}    

 

　　　　　　3.常量字段(static final)

package org.fenixsoft.classloading；
/**
*被动使用类字段演示三：
*常量在编译阶段会存入调用类的常量池中，本质上并无直接引用到定义常量的类，所以不会触发定义常量的类的初始化。
**/
public class ConstClass{
    static{
        System.out.println（"ConstClass init！"）；
    }
    public static final String HELLOWORLD="hello world"；
}
/*
**
*非主动使用类字段演示
**/
public class NotInitialization{
    public static void main（String[]args）{
        System.out.println（ConstClass.HELLOWORLD）；
    }
}

 

2、类加载过程

　　1.加载

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

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

　　　　　　3）在内存中生成一个表明这个类的java.lang.Class对象，做为方法区这个类的各类数据的访问入口。

　　　　数组的加载：

　　　　　　数组的元素类型是基本类型：引导类加载器

　　　　　　数组的元素类型是引用类型：递归父类加载

　　2.验证：-Xverify:none取消

　　　　　　1）文件格式验证：验证class文件格式，并能被当前虚拟机处理

　　　　　　2）元数据验证：字节码描叙信息进行语义分析，如：类是否有父类，是否与父类字段冲突

　　　　　　3）字节码验证：肯定程序的语义合乎逻辑

　　　　　　4）符号引用验证：符号引用所引用的字符串的验证，如：全限定名可否找到对应的类，类、字段、方法的访问性

　　3.准备

　　　　为类变量分配内存并设置类变量初始值的阶段，这些变量所使用的内存都将在方法区中进行分配

　　　　注意：类变量（static）、初始值为类型的初值，而并非“=”号赋予的值；如：int初值为0等；可是static fianl常量除外（字段表中ConstantValue属性指定的值）

　　　　

 

　　4.解析

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

　　　　　　1）符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，符号能够是任何形式的字面量，只要使用时能无歧义地定位到目标便可。

　　　　　　　　符号引用与虚拟机实现的内存布局无关，引用的目标并不必定已经加载到内存中。

　　　　　　　　各类虚拟机实现的内存布局能够各不相同，可是它们能接受的符号引用必须都是一致的，由于符号引用的字面量形式明肯定义在Java虚拟机规范的Class文件格式中。

　　　　　　2）直接引用（Direct References）：直接引用能够是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。

　　　　　　　　直接引用是和虚拟机实现的内存布局相关的，同一个符号引用在不一样虚拟机实例上翻译出来的直接引用通常不会相同。

　　　　　　　　若是有了直接引用，那引用的目标一定已经在内存中存在。

　　　　　　解析的类型：类或接口、字段、类方法、接口方法、方法类型、方法句柄和调用点限定符

　　　　　　1.类或接口的解析

　　　　　　　　假设当前代码所处的类为D，若是要把一个从未解析过的符号引用N解析为一个类或接口C的直接引用，那虚拟机完成整个解析的过程须要如下3个步骤：

　　　　　　　　1）非数组类型，那虚拟机将会把表明N的全限定名传递给D的类加载器去加载这个类C。

　　　　　　　　2）数组类型，而且数组的元素类型为对象，也就是N的描述符会是相似“[Ljava/lang/Integer”的形式，那将会按照第1点的规则加载数组元素类型。若是N的描述符如前面所假设的形式，须要加载的元素类型就是“java.lang.Integer”，接着由虚拟机生成一个表明此数组维度和元素的数组对象。

　　　　　　　　3）若是上面的步骤没有出现任何异常，那么C在虚拟机中实际上已经成为一个有效的类或接口了，但在解析完成以前还要进行符号引用验证，确认D是否具有对C的访问权限。若是发现不具有访问权限，将抛出java.lang.IllegalAccessError异常。

　　　　　　2.字段的解析

　　　　　　　　本类----接口----父类递归----不存在抛出异常

　　　　　　3.类方法解析

　　　　　　　　解析出的符号引用不是类，抛出异常----本类----父类----接口（抽象方法抛异常）----不存在抛异常

　　　　　　4.接口方法解析

　　　　　　　　解析出非符号引用不是接口，抛异常----本接口----父接口----不存在抛出异常

　　4.初始化

　　　　　　初始化是执行类构造器<clinit>方法

　　　　　　＜clinit＞（）方法是由编译器自动收集类中的全部类变量的赋值动做和静态语句块（static{}块）中的语句合并产生的

　　　　　　编译器收集的顺序是由语句在源文件中出现的顺序所决定的，静态语句块中只能访问到定义在静态语句块以前的变量，定义在它以后的变量，在前面的静态语句块能够赋值，可是不能访问

 

3、类加载器

　　比较两个类是否“相等”：同一个类加载器，加载同一个类；才是相等

　　不然同一个Class文件，被同一个虚拟机加载，只要加载它们的类加载器不一样，那这两个类就一定不相等。

　　这里所指的“相等”，包括表明类的Class对象的equals（）方法、isAssignableFrom（）方法、isInstance（）方法的返回结果，也包括使用instanceof关键字作对象所属关系断定等状况。

　　1.类加载器

　　　　启动类加载器：加载JAVA_HOME\lib下或-Xbootclasspath指定路径下的指定类库

　　　　扩展类加载器：加载ext类库，任何类库都行

　　　　应用程序类加载器：用户用的最多的加载器

　　2.双亲委派模型

　　　　双亲委派模型：保证了类的相等或者说是惟一

　　　　　　若是一个类加载器收到了类加载的请求，它首先不会本身去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每个层次的类加载器都是如此，

　　　　　　所以全部的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈本身没法完成这个加载请求（它的搜索范围中没有找到所需的类）时，子加载器才会尝试自己去加载。

　　　　　　

 

　　3.打破双亲委派模型

　　　　JNDI服务

　　　　　　JNDI提供命名服务和目录服务，是经过启动类加载器加载，是对资源的管理

　　　　　　可是既然是管理资源，就要加载应用程序中三方厂商提供的JNDI接口，才能对三方资源进行目录和命名服务提供

　　　　　　而启动类加载器是没法加载到这些应用程序中的资源

　　　　　　解决：经过一个ThreadContextClassLoader线程上下文加载器加载

 　　　　OSGi

　　　　　　热部署，动态的增长和卸载模块，原有的类加载机制就不合适了