虚拟机类加载机制

虚拟机类加载机制

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括了：加载（Loading）、验证（Verification）、准备（Preparation）、解析（Resolution）、初始化（Initialization）、使用（Using）和卸载（Unloading）七个阶段。其中验证、准备和解析三个部分统称为连接（Linking）

在Java语言里面，类型的加载和连接过程都是在程序运行期间完成的

Java中天生可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。例如，如果编写一个使用接口的应用程序，可以等到运行时再指定其实际的实现。这种组装应用程序的方式广泛应用于Java程序之中

2 类加载的时机

虚拟机规范则是严格规定了有且只有四种情况必须立即对类进行“初始化”

1）遇到new、getstatic、putstatic或invokestatic这4条字节码指令时，场景是：使用new关键字实例化对象的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态字段除外）的时候，以及调用一个类的静态方法的时候。

2）使用java.lang.reflect包的方法对类进行发射调用的时候

3）当初始化一个类的时候，如果发现其父类还没有进行过初始化，则需要先触发其父类的初始化。

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

3 类加载的过程

在加载阶段，虚拟机需要完成以下三件事情：

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

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

3）在Java堆中生成一个代表这个类的java.lang.Class对象，作为方法区这些数据的访问入口

关于第一点，从哪加载

□ 从ZIP包中读取，这很常见，最终成为日后JAR、EAR、WAR格式的基础。□ 从网络中获取，这种场景最典型的应用就是Applet。□ 运行时计算生成，这种场景使用得最多的就是动态代理技术，在java.lang. reflect.Proxy中，就是用了ProxyGenerator.generateProxyClass来为特定接口生成*$Proxy的代理类的二进制字节流。□ 由其他文件生成，典型场景：JSP应用。□ 从数据库中读取，这种场景相对少见些，有些中间件服务器（如SAP Netweaver）可以选择把程序安装到数据库中来完成程序代码在集群间的分发。□ ……

关于第二点：虚拟机规范未规定方法区的具体数据结构

2 验证(java.lang. VerifyError异常)

Class文件并不一定要求用Java源码编译而来，可以使用任何途径，包括用十六进制编辑器直接编写来产生Class文件。在字节码的语言层面上，上述Java代码无法做到的事情都是可以实现的

文件格式验证、元数据验证、字节码验证和符号引用验证。

关于第三点得高复杂度，在JDK 1.6之后的Javac编译器中进行了一项优化，给方法体的Code属性的属性表中增加了一项名为“StackMapTable”的属性，这项属性描述了方法体中所有的基本块（Basic Block，按照控制流拆分的代码块）开始时本地变量表和操作栈应有的状态，这可以将字节码验证的类型推导转变为类型检查从而节省一些时间

在JDK1.6的HotSpot虚拟机中提供了-XX:-UseSplitVerifier选项来关闭掉这项优化，或者使用参数-XX:+FailOverToOldVerifier要求在类型校验失败的时候退回到旧的类型推导方式进行校验。而在JDK 1.7之后，对于主版本号大于50的Class文件，使用类型检查来完成数据流分析校验则是唯一的选择

关于第四点，java.lang. IncompatibleClassChangeError异常的子类，如java.lang.IllegalAccessError、java.lang.NoSuchFieldError、java.lang.NoSuchMethodError等

实施阶段就可以考虑使用-Xverify:none参数来关闭大部分的类验证

3 准备

为类变量分配内存并设置类变量初始值的阶段

首先是这时候进行内存分配的仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。其次是这里所说的初始值“通常情况”下是数据类型的零值

如果类字段的字段属性表中存在ConstantValue属性，那在准备阶段变量value就会被初始化为ConstantValue属性所指定的值

4 解析

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

符号引用：以CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info等类型的常量。

符号引用（Symbolic References）：符号引用以一组符号来描述所引用的目标，与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内存中

直接引用（Direct References）：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，目标必然存在内存中。

解析时间只要求了在执行anewarray、checkcast、getfield、getstatic、instanceof、invokeinterface、invokespecial、invokestatic、invokevirtual、multianewarray、new、putfield和putstatic这13个用于操作符号引用的字节码指令之前，没有具体时间；

解析动作主要针对类或接口、字段、类方法、接口方法四类符号引用进行，分别对应于常量池的CONSTANT_Class_info、CONSTANT_Fieldref_info、CONSTANT_Methodref_info及CONSTANT_InterfaceMethodref_info四种常量类型。

。。。。。

5 初始化

□ clinit() 方法是由编译器自动收集类中所有类变量的赋值动作和静态语句块（static {}块）中的语句合并产生的，编译器收集的顺序一定是先变量赋值，再静态语句块，因此在静态语句块中可以访问到类变量的初始值了。

□ clinit()方法与类的构造函数（或者说实例构造器()方法）不同，它不需要显式地调用父类构造器

□父类的clinit()方法先执行

□ clinit()方法对于类或接口来说并不是必须的

□ 接口中不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成clinit()方法。但接口与类不同的是，执行接口的clinit()方法不需要先执行父接口的clinit()方法。只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一样不会执行接口的clinit()方法。□ 虚拟机会保证一个类的clinit()方法在多线程环境中被正确地加锁和同步，代码清单7-6

4 类加载器

把类加载阶段中的“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到Java虚拟机外部去实现，以便让应用程序自己决定如何去获取所需要的类

在类层次划分、OSGi、热部署、代码加密等领域大放异彩，成为了Java技术体系中一块重要的基石

4.1 类与类加载器

对于任意一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性

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

代码清单7-7中演示了不同的类加载器对instanceof关键字的运算结果。

4.2 双亲委派模型

站在Java虚拟机的角度讲，只存在两种不同的类加载器：一种是启动类加载器（Bootstrap ClassLoader），这个类加载器使用C++语言实现[插图]，是虚拟机自身的一部分；另外一种就是所有其他的类加载器，这些类加载器都由Java语言实现，独立于虚拟机外部，并且全都继承自抽象类java.lang.ClassLoader

□ 启动类加载器（Bootstrap ClassLoader）：前面已经介绍过，这个类加载器负责将存放在<JAVA_HOME>\lib目录中的，或者被-Xbootclasspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar，名字不符合的类库即使放在lib目录中也不会被加载）类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。

□ 扩展类加载器（Extension ClassLoader）：这个加载器由sun.misc.Launcher$ExtClassLoader实现，它负责加载<JAVA_HOME>\lib\ext目录中的，或者被java.ext.dirs系统变量所指定的路径中的所有类库，开发者可以直接使用扩展类加载器。

□ 应用程序类加载器（Application ClassLoader）：这个类加载器由sun.misc. Launcher$AppClassLoader来实现。由于这个类加载器是ClassLoader中的getSystemClassLoader()方法的返回值，所以一般也称它为系统类加载器。它负责加载用户类路径（ClassPath）上所指定的类库，开发者可以直接使用这个类加载器，如果应用程序中没有自定义过自己的类加载器，一般情况下这个就是程序中默认的类加载器。

双亲委派中的类加载器，之间的父子关系一般不会以继承（Inheritance）的关系来实现，而是都使用组合（Composition）关系来复用父加载器的代码。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载的请求，它首先不会自己去尝试加载这个类，而是把这个请求委派给父类加载器去完成

使用双亲委派模型来组织类加载器之间的关系，有一个显而易见的好处就是Java类随着它的类加载器一起具备了一种带有优先级的层次关系。例如类java.lang.Object，它存放在rt.jar之中，无论哪一个类加载器要加载这个类，最终都是委派给启动类加载器进行加载，因此Object类在程序的各种类加载器环境中都是同一个类

实现双亲委派的代码都集中在java.lang.ClassLoader的loadClass()方法之中：

逻辑清晰易懂：先检查是否已经被加载过，若没有加载则调用父加载器的loadClass()方法，若父加载器为空则默认使用启动类加载器作为父加载器。如果父类加载失败，则在抛出ClassNotFoundException异常后，再调用自己的findClass()方法进行加载

4.3 破坏双亲委派模型

双亲委派模型并不是一个强制性的约束模型

历史中三次被破坏：

在OSGi环境下，类加载器不再是双亲委派模型中的树状结构，而是进一步发展为网状结构，当收到类加载请求时，OSGi将按照下面的顺序进行类搜索：（1）将以java.*开头的类，委派给父类加载器加载。（2）否则，将委派列表名单内的类，委派给父类加载器加载。（3）否则，将Import列表中的类，委派给Export这个类的Bundle的类加载器加载。（4）否则，查找当前Bundle的ClassPath，使用自己的类加载器加载。（5）否则，查找类是否在自己的Fragment Bundle中，如果在，则委派给Fragment Bundle的类加载器加载。（6）否则，查找Dynamic Import列表的Bundle，委派给对应Bundle的类加载器加载。（7）否则，类查找失败。上面的查找顺序中只有开头两点仍然符合双亲委派规则，其余的类查找都是在平级的类加载器中进行的。