Java虚拟机类加载机制

虚拟机的类加载机制：虚拟机把描述类的数据从Class文件中加载到内存，并且对数据进行校验、转换解析和初始化，最终形成可以被虚拟机直接使用的Java类型。

前言
　　学习Java语言，了解Java虚拟机的类加载机制是必不可少的。在Java语言中，类的加载、连接和初始化都是在程序运行过程中完成的，虽然会在类加载是增加性能的开销，但是大大提高了Java语言的灵活性。Java可以动态扩展的特性就是依赖这种特性实现的。

一、类加载机制
　　一个类具有其生命周期，从被加载进虚拟机，到被卸出内存分为以下七个阶段：加载(Loading)、验证(Verification)、准备(Preparation)、解析(Resolution)、初始化(Initialization)、使用(Using)、卸载(Unloading)。

　　上图中加载、验证、准备、初始化、卸载五个阶段的顺序是确定的，而解析阶段可能发生在初始化阶段之后。虽然上述的五个阶段是发生的顺序是确定的，但其实这些阶段都是交叉进行(在一个阶段的执行过程中，对另一个阶段调用)。

类加载的过程
　　加载，是类加载的第一个阶段，在这一阶段，虚拟机将完成下述三件事情：
　　1)、通过类的全限定名来获取此类的二进制字节流。
　　2)、将二进制字节流所代表的静态存储结构转化为方法区运行时需要的数据结构。
　　3)、在内存中生成一个代表这个类的java.lang.Class对象，这个对象将作为方法区中的各种数据的访问入口。
　　但是Java虚拟机规范对于上述三点并没有过于严苛的要求，留给了虚拟机设计团队广阔的舞台区构建新的虚拟机。
　　在类加载过程中，数组类型的加载方式与其他类型的加载方式又有所不同。一个非非数组类型的加载过程，既可以使用系统所提供的引导类加载器完成加载，也可以有程序人员自己定义类加载器完成类的加载。对于数组类而言，不通过类加载器创建，是由Java虚拟机直接创建，但是在创建过程中，数组中每一个元素对象都需要类加载器去创建。
　　在加载阶段完成后，虚拟机外部的二进制字节流就按照虚拟机所需的格式存储在方法区之中，方法区中的数据存储格式则是由虚拟机实现自行定义的。由于加载阶段与连接阶段的部分内容（如一部分字节码文件格式的验证动作）是交叉进行的，加载阶段尚未完成，连接阶段就可能开始，但这部分在加载阶段进行的动作仍然属于连接阶段的内容。这两个阶段开始的先后顺序是不会发生改变的。

　　验证阶段是连接过程(Linking)阶段的第一步，它为了确保Class文件中的字节流中包含的信息时符合虚拟机要求的，并且不会危害虚拟机自身的安全。因为，生成Class文件，并不一定通过Java源码编译而来，可以使用任何途径来生成，甚至可以通过十六进制的编译器来直接编写Class文件。所以验证Class文件中的字节码信息时对虚拟机自身保护的一项重要工作。
　　在2010年发布的《Java虚拟机规范（Java SE 7版）》中，有许多具体的约束与验证，因为本文的篇幅限制，不再一一列举。但是验证过程整体下述四个阶段：文件格式验证、元数据验证、字节码验证、符号引用验证。
　　在文件格式验证中主要是检查字节流是否符合Class文件的规范，是否可以被当前的虚拟机所处理。只有通过了文件格式的验证，字节流才会进入内存的方法去中进行储存，其余的三个阶段均在内存中的方法去中进行。
　　在元数据验证中主要是对字节码进行语义分析，保证符合Java语言规范。检测是否机场了不允许被继承的类（被final修饰的类），检测是否为实现了接口或父类中要求实现的所有方法……
　　字节码验证是整个验证过程中最复杂的一个阶段，主要目的是通过数据流和控制流分析，确定程序语义是合法性的、符合逻辑的。这个阶段将对类的方法体进行校验分析，保证被校验类的方法在运行时不会伤害虚拟机。例如：保证跳转指令不会跳转至方法体之外的字节码指令上；保证方法体中的类型转换是有效的……
　　符号验证验证是将虚拟机中的符号引用转化为直接引用的时候，其目的是为了保证解析动作能正常执行，如果无法通过符号引用验证，那么会抛出一个java.lang.NoSuchMethodError异常的子类。符号引用验证可以看做是类自身以外的信息匹配性验证。
　　从上面的分析可以了解到验证阶段是一个非常重要的阶段，但其并不是一定要有的阶段。如果所运行的全部代码（包括自己编写即第三方包中的代码）都已经被反复使用和验证过，那么可以关闭大部分的验证阶段，减少虚拟机类的加载时间。

　　接下来便进入准备阶段，准备阶段是正是为类变量分配内存并设置类变量的初始值的阶段，在这一阶段中在内存中分配的仅仅为类变量（被static修饰的变量，不包括实例变量），其内存空间在方法区中分配。这里所说的零值，通常情况下为该数据类型的零值。假设一个类变量的定义为：
　　public static int value = 123;
　　在准备阶段后，value的初始值为0而不是123，在执行初始化阶段后，value的值才会被赋值为123。基本数据的零值如下图所示：

数据类型 零值 数据类型 零值 int 0 boolean false long 0L float 0.0f short (short)0 double 0.0d char ‘\u0000’ reference null byte (byte)0

　　虽然有初始零值的存在，但也会有一些特殊情况，如果类字段的字段属性表存在ConstantValue属性，那么在初始化时就会被初始化为ConstantValue所指定的初值。假设上面类变量value的定义变为
　　public static final int value = 123;
　　编译时Javac将会将value的生成ConstantValue属性，在准备阶段虚拟机就会根据ConstantValue的设置将value赋值为123。

　　解析阶段是虚拟机将常量池中的符号引用转变为直接引用的过程。
　　符号引用与虚拟机的内存布局无关，引用的目标并不一定已经加载到内存中，可以任何形式的字面量存在，但是引用的字面量明确的定义在Java虚拟机规范的Class文件格式中。直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。与虚拟机实现的内部布局相关。如果有了直接引用，那引用的目标必定已经在内存中存在。
　　解析动作主要针对类或接口、字段、类方法、接口方法、方法句柄和调用点限定符7类符号引用进行，分别对应于常量池的7中常量，这里不在赘述。

　　初始化阶段是类加载过程的最后一步。在初始化阶段，真正的执行类中定义的Java程序代码（或者说是字节码）。初始化阶段是执行类构造器<clinit>()方法的过程。
　　<clinit>()方法是由编译器自动收集类的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定的，静态语句块中只能访问定义在静态语句块之间的变量，定义在它之后的变量在前面的静态语句块中可以赋值，但是不可以访问。
　　<clinit>()方法类的构造函数不同，它不需要显示的调用父类构造器。虚拟机会保证在子类的<clinit>()方法执行之前，父类的<clinit>()方法已经执行完毕。在虚拟机中第一个被执行的<clinit>()方法一定是java.lang.Object。
　　<clinit>()方法对于类或接口来说并不是必需的，如果一个类中没有静态语句块，也没有对变量的复制操作，那么编译器可以不为这个类生成<clinit>()方法。
　　接口中不能使用静态语句块，但仍有对变量初始化的赋值操作，也会生成<clinit>()方法。但与类不同，执行接口的<clinit>()方法。不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量使用时，父接口才会初始化。接口的实现类在初始化时一样不会执行接口的<clinit>()方法。
　　虚拟机会保证一个类的<clinit>()方法在多线程环境中能被正确地加载、同步，保证只有一个线程会执行<clinit>()方法。

二、类加载器
　　对于任意一个类，都需要由加载它的类加载器和这个类本身共同确定其在Java虚拟机中的唯一性，每一个类加载器都拥有一个独立的类名称空间。即：比较两个类是否“相等”，只有在这两个类是由同一个类加载器加载的前提下才有意义，否则，即使这两个类来源于同一个Class文件，被同一个虚拟机加载，只要加载他们的类加载器不同，那么这两个类必定不相等。这里的所说的“相等”，包括代表类的Class对象的equals()方法、isAssignableFrom()方法、isInstance()方法的返回结果，也包括使用instanceof关键字做对象所属关系判定等情况。例如：

/** * 类加载器与instanceof关键字演示。 * @author LXH * */public class ClassLoaderTest {    public static void main(String[] args)             throws InstantiationException,                     IllegalAccessException,                     ClassNotFoundException {        ClassLoader myLoader = new ClassLoader() {            @Override            public Class<?> loadClass(String name) throws ClassNotFoundException {                String fileName = name.substring(name.lastIndexOf(".") + 1) + ".class";                try {                    InputStream is = getClass().getResourceAsStream(fileName);                    if(is == null) {                        return super.loadClass(name);                    }                    byte[] b = new byte[is.available()];                    is.read(b);                    return defineClass(name, b, 0, b.length);                } catch (IOException e) {                    throw new ClassNotFoundException(name);                }            }        };        Object object = myLoader.loadClass("xupt.lxh.core.ClassLoaderTest").newInstance();        System.out.println(object.getClass());        System.out.println(object instanceof xupt.lxh.core.ClassLoaderTest);    }

　　使用类加载器实例化了这个类的对象，确实是类lxh.core.ClassLoaderTest的实例，但在做所属类型检查的时候反 回了false，这是因为虚拟机中存在了两个ClassLoaderTest类，一个是由系统应用程序类加载器加载的，另外一个是由我们定义的 类加载器加载的。

双亲委派模型
　　从Java虚拟机的角度来讲，只存在两种不同的类加载器：一种为启动类加载器（Bootstrap ClassLoader），这个类加载器是由C++语言实现的，是虚拟机的一部分；另一种就是所有其他的类加载器，这些类加载器都由Java语言实现的，独立于虚拟机外部，并且全部继承于java.lang.ClassLoader。

　　　　　　　　　　　　　　　　
　　上图所展示的类加载器之间的层次关系。称为类加载器的双亲委派模型。
　　双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（她的搜索范围内没有找到所需的类）时，子加载器才会尝试自己去加载。Tomcat5服务器则是在双亲委派模型的基础上来实现。

　　本文简单介绍了类的加载过程的“加载”、“验证”、“准备”、“解析”和“初始化”阶段，还简单提到了类加载器。希望对读者有所帮助。