深入了解Java虚拟机（3-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）；
    }
}

二、类加载过程

　　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{}块）中的语句合并产生的

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

三、类加载器

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

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

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

　　1.类加载器

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

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

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

　　2.双亲委派模型

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

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

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

　　　　　　

　　3.打破双亲委派模型

　　　　JNDI服务

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

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

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

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

　　　　OSGi

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