JVM（五）：虚拟机类加载机制

一、类加载时机

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

加载(Loading)

验证(Verification)

准备(Preparation)

解析(Resolution)

初始化(Initialization)

使用(Using)

卸载(Unloading)

这7个阶段的发生顺序如图:

加载、验证、准备、初始化和卸载这5个阶段的顺序是确定的，类的加载过程必须按照

这种顺序按部就班的进行，而解析阶段则不一定:它在某些情况下可以在初始化阶段之后在

开始，这是为了支持Java语言的运行时绑定（也称为动态绑定或晚期绑定）。这里按部就班

的开始，而不是“进行”或“完成”，强调的就是因为这些阶段通常都是互相交叉的混合式

进行，通常会在一个阶段执行的过程中调用、激活另外一个阶段。

（一）加载

这里类的加载是指在类加载过程中的第一个任务“加载”，在这个阶段JVM主要完成三

件事：

1、通过类的全限定名（包名与类名）来获取定义此类的二进制字节流（class文件），来

获取的方式，可以通过jar包、war包、网络中获取、JSP文件生成等方式。

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

数据结构，并未合并数据。（方法区就是用来存放已被加载的类信息，常量、静态变量，

编译后的代码的运行时内存区域）

3、在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的

访问入口。这个Class对象并没有规定是在Java对内存中，它比较特殊，虽为对象，但存

放在方法中。

（二）验证

验证是虚拟机对自身保护的一项重要工作，大致分为4个阶段：

1、文件格式验证

2、元数据验证

3、字节码验证

4、符号引用验证

验证被加载后的类是否有正确的结构，类数据是否会符合虚拟机的要求，确保不会危害

虚拟机安全。

（三）准备

为类的静态变量（static filed）在方法区分配内存，并赋默认初值（0值或null值）。

如：

static int a = 100;

静态变量a就会在准备阶段被赋默认值0。

对于一般的成员变量是在类实例化时候，随对象一起分配在堆内存中。

另外，静态常量（static final filed）会在准备阶段赋程序设定的初值，如static final int a

= 666;  静态常量a就会在准备阶段被直接赋值为666，对于静态变量，这个操作是在初始化

阶段进行的

（四）解析

将类的二进制数据中的符号引用换为直接引用

（五）初始化

java虚拟机对加载阶段开始执行并没有强制约束，可以由虚拟机具体实现来自由把握，

但对于 初始化阶段，虚拟机严格规范了有且只有5种情况：

1、遇到new、getstatic、putstatic、invokestatic这4条字节码指令时，如果类没有进行过

初始化，则需要先触发其初始化。生成4条指令最常见的场景是:使用new关键字实例化对象

的时候、读取或设置一个类的静态字段（被final修饰、已在编译期把结果放入常量池的静态

字段除外）的时候，以及调用一个类的静态方法的时候。

2、使用java.lang.reflect包的方法对类进行发射调用的时候，如果类没有进行过初始化，则需

要先触发其初始化。

3、初始化一个类时，如果发现其父类还没有进行初始化，则需要触发欺负类的初始化。

4、当虚拟机启动时，用户需要指定一个要执行的主类（包含main方法的那个类），虚拟机会

先初始化这个类。

5、当使用JDK1.7的动态语言支持时，如果一个java.lang.invoke.MethodHandle实例最后的解

析结果REP_getStatic、REP_putStatic、REP_invokeStatic的方法句柄，并且这个方法句柄所

对应的类没有进行过初始化，则需要先出发其初始值。

二、类加载器

“通过一个类的全限定名来获取描述此类的二进制字节流”这个动作放到java虚拟机外不部去

实现，以便让应用程序自己决定如何去获取做需要的类，实现这个动作的代码模块称为“类加

载器”。

（一）类与类加载器

类加载器的主要作用只是实现类的加载动作，但它在java程序中起到的作用去远远不限于

类加载阶段，每一个类，都需要由加载它的类加载器和这个类本身一同确立其在Java虚拟机中

的唯一性，每一个加载器，都拥有一个独立的类名称空间，比较两个类是否“相等”，只有在

这两个类是由同一个类加载器加载的前提下才有意义。

（二）双亲委派模型

从Java虚拟机的角度来说，只存在两种不同的类加载器，一种是启动类加（Bootstrap

ClassLoader），这个加载器使用C++语言实现，是虚拟机自身的一部分，另一种是所有其他

的类加载器，这些类加载器使用Java实现，独立于虚拟机外部，并未全都继承自抽象类java.

lang.ClassLoader

对于开发人员来说，类加载器可以细致划分为3种：

1、启动类加载器(Bootstrap ClassLoader)：负责将存放在\lib目录中的，或被

-Xbootclasspath参数指定的路径中的，并且是虚拟机识别的类库加载到虚拟机中 如,rt.jar。

名字不符合即使放在目录中也不被加载。如果需要把加载请求委派给引导类加载器，直接使

用null代替即可。

2、扩展类加载器(Extension ClassLoader)：由sum.misc.Launcher$ExtClassLoader实现，

负责加载<Java_Home>\lib\ext目录中的，或者被java.ext.dir系统变量所指定的路径中的所

有类库。开发者可以直接使用扩展类加载器。

3、应用程序类加载器(Application ClassLoader):由sun.misc.Launcher$App-ClassLoader

实现。是ClassLoader中的getSystemClassLoader()方法的返回值，所以也称为系统类加载

器。负责加载用户路径(ClassPath)上所指定的类库，如果应用程序中没有自定义过自己的类

加载器，这个就是默认的加载器，开发人员可以直接使用这个类加载器。

应用程序是由这3种类加载器互相配合进行加载的，如果有必要，也可以加入自定义的类

加载器，图中展示了类加载器之间的层次关系，称为类加载器的双亲委派模型( Parents

Delegation Model)，双亲委派模型要求除了顶层是启动类加载器外，其余加载器都应当有自

己的父类加载器。这里类加载器之间的父子关系不是由继承来实现的，而是以组合形式来完成

的。

双亲委派模型的工作过程：如果类加载器收到类加载的请求，会先将请求委派给父类加

载器完成，每一个层次的类加载器都是如此，因此所有加载请求最终都应该传送到顶层的启动

类加载器中，只有当父加载器反馈无法完成这个加载请求，子加载器才会尝试自己去加载。

好处：如类java.lang.Object，存放在rt.jar中，无论哪个类加载器要加载这个类，都会

委派到启动类加载器中，所以Object类在程序的各种类加载器环境中都是同一个类。相反，

如果没有使用双亲委派模型，用户自定义了一个java.lang.Object类，被加载后虚拟机中就存

在多个Object类，造成混乱。