深入理解Java虚拟机读书笔记十二

第 7 章虚拟机类加载机制

7. 1.概述

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

Java中可以动态扩展的语言特性就是依赖运行期动态加载和动态连接这个特点实现的。

7.2.类加载的时机

类从被加载到虚拟机内存中开始，到卸载出内存为止，它的整个生命周期包括：

加载 (Loading) 、验证 ( Verification)、准备( Preparation) 、解析 (Resolution) 、初始化 (Initial)、使用 ( Using ) 和卸载(Unloading )七个阶段。其中验证、准备和解析三个部分统称为链接(Linking)。

只有四钟情况必须立即对类进行“初始化”(而加载、验证、准备在此之前开始），解析为了实现运行时绑定，可以在初始化之后：

1.遇到new、getstatic、putstatic或invokestatic这4个字节码指令时，如果类没有进行初始化，则需要先触发其初始化。

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

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

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

"有且只有" 这四个场景中的行为称为对一个类进行主动引用。除此之外所有引用，类的方式都不会触发初始化称为被动引用。

接口与类真正有所区别：四种"有且仅有"需要开始初始化场景中第三种：当一个类在初始化时，要求其父类全部都已经初始化过了，但是一个接口在初始化时，并不要求其全部都完成了初始化，只有在真正使用到父接口的时候（如引用接口中定义的常量）才会初始化。

7.3.类加载的过程

7.3.1.加载

“加载”（Loading) 阶段是"类加载" (Class Loading )过程的一个阶段。

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

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

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

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

二进制字节流获取方式：

1.从ZIP中读取这很常见，最终成为日后 JAR. EAR.WAR 格式的基础。

2.从网络中获取，这种场景最典型的应用就是Applet。

3.运行时计算生成这忡场景使用得最多的就是动态代理位术，在java.lang.reflect.Proxy中就是用了ProxyGenerator.generateProxyClass来为特定接口生成“*$Proxy的代理类的二进制字节流。

4.由其他文件生成，典型场景：JSP应用。

5.从数据库中读取，这种场景相对少见些，有些中间件服务器（如SAP Netweaver)可以选择把程序安装到数据库中来完成程序代码在集群间的分发。

7.3.2.验证

验怔是虚拟机自身保护的一项重要工作。

四个阶段的检验：

1.文件格式验证：验证字节流是否符合Class文件格式的规范，并且能被当前版本的虚拟机处理。

2.元数据验证：对字节码描述的信息进行语义分析以保证其描述的信息符合Java语言的规范要求。

3.字节码验证：进行数据流和控制流分析。对类的方法体进行校验分析。任务：保证被校验类的方法在运行时不会做出危害虚拟机安全的行为。

4.符号引用验证：校验发生在虚拟机将符号引用转化为直接引用的时候，这个转化动作将在连接的第三个阶段——解析阶段中发生。可以看做是对类自身以外（常量池中的各种符号引用）的信息进行匹配性的校验。验证的目的是确保解析动作能正常执行，如果无法通过符号引用验证，将会抛出一个异常。

如果所运行的代码（包括自己写的、第三方包中的代码）都已反复使用和验证过，在实施阶段可以考虑使用-Xverify:none参数来关闭大部分的类验证措施，以缩短虚拟机类加载的时间。

7.3.3.准备

准备阶段是正式为类变量分配内存并设置类变量初始值的阶段，这些内存都将在方法区中进行分配。

1.首先是内存分配仅包括类变量（被static修饰的变量），而不包括实例变量，实例变量将会在对象实例化时随着对象一起分配在Java堆中。

2.其次，初始值通常情况下是数据类型的零值。

例如： public static int value = 123;

Value准备阶段后，初始值为0，不是123.因为尚未执行任何Java方法，而把value赋值为123的putstatic指令时程序编译后，存放于类构造器<clinit>()方法中，赋值123的动作在初始化阶段才会执行。

如果是常量，在准备阶段就会设置。

比如：public static final int value = 123,准备就设置为123.

7.3.4.解析

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

1.符号引用 ( Symbolic References ) ：符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能无歧义地定位到目标即可。符号引用与虚拟机实现的内存布局无关，引用的目标并不一定已经加载到内部中。

2.直接引用 ( Direct References)：直接引用可以是直接指向目标的指针、相对偏移量或是一个能间接定位到目标的句柄。直接引用是与虚拟机实现的内存布局相关的，同一个符号引用在不同虚拟机实例上翻译出来的直接引用一般不会相同。如果有了直接引用，那引用的目标必定已经在内存中存在。

虚拟机实现可能会对第一次解析的结果进行缓存（在运行时常量池中记录直接引用，并把常量标识为已解析状态）从而避免解析动作重复进行。

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

1.类或接口的解析

2.字段解析

3.类方法的解析

4.接口方法解析

7.3.5.初始化

初始化阶段，开始执行类中定义的Java程序代码（字节码）。

初始化阶段，是执行类构造器<clinit>()方法的过程。

1.<clinit>方法是由编译器自动收集类中的所有类变量的赋值动作和静态语句块（static{}块）中的语句合并产生的，编译器收集的顺序是由语句在源文件中出现的顺序决定。静态语句块中只能访问到定义在静态语句块之前的变量，定义在它之后的变量，在前面的静态语句块中可以赋值，但是不能访问。

2.<clinit>()方法与类的构造函数（或者说实例构造器<init>()方法）不同，它不需要显示地调用父类构造器，虚拟机会保证在子类的<clinit>方法执行之前，父类的<clinit>()方法已经执行完毕。因此在虚拟机中第一个执行的<clinit>()方法的类肯定是java.lang.Object。

3.由于父类的<clinit>()方法先执行，也就意味着父类中定义的静态语句块要优先于子类的变量赋值操作。

4.<clinit>()方法对于类或接口来说并不是必须的，如果一个类中没有静态语句块，也没有对变量的赋值操作，那么编译器可以不为这个类生成<clinit>()方法。

5.接口中的不能使用静态语句块，但仍然有变量初始化的赋值操作，因此接口与类一样都会生成<clinit>()方法，但接口与类不同的是，执行接口的<clinit>()方法不需要先执行父接口的<clinit>()方法。只有当父接口中定义的变量被使用时，父接口才会被初始化。另外，接口的实现类在初始化时也一定不会执行接口的<clinit>()方法。

6.虚拟机会保证一个类的<clinit>()方法在多线程环境中被正确地加锁和同步，如果多个线程同时去初始化一个类，那么只会有一个线程去执行这个类的<clinit>()方法，其他线程需要阻塞等待，直到活动线程执行<clinit>方法完毕。如果在一个类的<clinit>()方法中有耗时很长的操作，那可能造成多个线程阻塞，在实际应用中，这种阻塞往往是很隐蔽的。

7.4.类加载器

7.4.1类和类加载器

类加载器：通过一个类的全限定名来获取描述此类的二进制字节流的代码模块。

类加载器只用于实现类的加载动作。

两个类相等：对于任意一个类，需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中的唯一性。两个类由同一个类加载器加载才有意义，否则，即使两个类来源于同一个Class文件，只要加载它们的类加载器不同，那这两个类就必定不相等。

7.4.2.双亲委派模型

从Java虚拟机角度讲

Java虚拟机有两种类加载器：

1.启动类加载器（Bootstrap ClassLoader)，这个类加载器使用C++语言实现，是虚拟机自身的一部分；

2.所有其他的类加载器，这些加载器都由Java语言实现，独立于虚拟机外部，并且全部继承自抽象类java.lang.ClassLoader。

从Java开发人员角度

大部分Java程序会用到三种系统提供的类加载器：

1.启动类加载器（Bootstrap ClassLoader)：负责将存放在<:JAVA_HQME>\lib目录中的，或者被_Xbootc1asspath参数所指定的路径中的，并且是虚拟机识别的（仅按照文件名识别，如rt.jar)类库加载到虚拟机内存中。启动类加载器无法被Java程序直接引用。

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

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

应用程序是由这三种类加载器互相配合进行加载的。

类加载器双亲委派模型：

类加载器之间的这种层次关系，就称为类加载器的双亲委派模型( Parents Delegation Model) 。

不会以继承(Inheritance)关系实现类加载器之间的父子关系，使用组合（Composition)关系来复用父加载器的代码。

双亲委派模型的工作过程是：如果一个类加载器收到了类加载器的请求，它首先不会自己去加载这个类，而是把这个请求委派给父类加载器去完成，每一个层次的类加载器就都是如此，因此所有的加载请求最终都应该传送到顶层的启动类加载器中，只有当父加载器反馈自己无法完成这个加载请求（它的健搜索范圈中没有找到所需的类）时，子加载器才会尝试自己去加载。

7.4.3.破坏双亲委派模型

双亲委派模型也有特殊情况不被遵循。

第一次破坏：JDK版本的类加载器兼容问题

第二次破坏：模型自身的缺陷。JNDI服务原因，逆向使用类加载器。

第三次破坏：用户对程序动态性追求导致的。代码热替换，模块热部署。OSGI可以实现代码热替换。