深入理解--JVM 类加载机制详解
如下图所示，JVM类加载机制分为五个部分：加载，验证，准备，解析，初始化，下面我们就分别来看一下这五个过程。
加载
加载是类加载过程中的一个阶段，这个阶段会在内存中生成一个代表这个类的java.lang.Class对象，作为方法区这个类的各种数据的入口。注意这里不一定非得要从一个Class文件获取，这里既可以从ZIP包中读取（比如从jar包和war包中读取），也可以在运行时计算生成（动态代理），也可以由其它文件生成（比如将JSP文件转换成对应的Class类）。
验证
这一阶段的主要目的是为了确保Class文件的字节流中包含的信息是否符合当前虚拟机的要求，并且不会危害虚拟机自身的安全。
准备
准备阶段是正式为类变量分配内存并设置类变量的初始值阶段，即在方法区中分配这些变量所使用的内存空间。注意这里所说的初始值概念，比如一个类变量定义为：
|
1
|
public
static
int
v =
8080
;
|
实际上变量v在准备阶段过后的初始值为0而不是8080，将v赋值为8080的putstatic指令是程序被编译后，存放于类构造器
但是注意如果声明为：
|
1
|
public
static
final
int
v =
8080
;
|
在编译阶段会为v生成ConstantValue属性，在准备阶段虚拟机会根据ConstantValue属性将v赋值为8080。
解析
解析阶段是指虚拟机将常量池中的符号引用替换为直接引用的过程。符号引用就是class文件中的：
- CONSTANT_Class_info
- CONSTANT_Field_info
- CONSTANT_Method_info
等类型的常量。
下面我们解释一下符号引用和直接引用的概念：
- 符号引用与虚拟机实现的布局无关，引用的目标并不一定要已经加载到内存中。各种虚拟机实现的内存布局可以各不相同，但是它们能接受的符号引用必须是一致的，因为符号引用的字面量形式明确定义在Java虚拟机规范的Class文件格式中。
- 直接引用可以是指向目标的指针，相对偏移量或是一个能间接定位到目标的句柄。如果有了直接引用，那引用的目标必定已经在内存中存在。
初始化
初始化阶段是类加载最后一个阶段，前面的类加载阶段之后，除了在加载阶段可以自定义类加载器以外，其它操作都由JVM主导。到了初始阶段，才开始真正执行类中定义的Java程序代码。
初始化阶段是执行类构造器
注意以下几种情况不会执行类初始化：
- 通过子类引用父类的静态字段，只会触发父类的初始化，而不会触发子类的初始化。
- 定义对象数组，不会触发该类的初始化。
- 常量在编译期间会存入调用类的常量池中，本质上并没有直接引用定义常量的类，不会触发定义常量所在的类。
- 通过类名获取Class对象，不会触发类的初始化。
- 通过Class.forName加载指定类时，如果指定参数initialize为false时，也不会触发类初始化，其实这个参数是告诉虚拟机，是否要对类进行初始化。
- 通过ClassLoader默认的loadClass方法，也不会触发初始化动作。
类加载器
虚拟机设计团队把加载动作放到JVM外部实现，以便让应用程序决定如何获取所需的类，JVM提供了3种类加载器：
- 启动类加载器(Bootstrap ClassLoader)：负责加载 JAVA_HOME\lib 目录中的，或通过-Xbootclasspath参数指定路径中的，且被虚拟机认可（按文件名识别，如rt.jar）的类。
- 扩展类加载器(Extension ClassLoader)：负责加载 JAVA_HOME\lib\ext 目录中的，或通过java.ext.dirs系统变量指定路径中的类库。
- 应用程序类加载器(Application ClassLoader)：负责加载用户路径（classpath）上的类库。
JVM通过双亲委派模型进行类的加载，当然我们也可以通过继承java.lang.ClassLoader实现自定义的类加载器。
当一个类加载器收到类加载任务，会先交给其父类加载器去完成，因此最终加载任务都会传递到顶层的启动类加载器，只有当父类加载器无法完成加载任务时，才会尝试执行加载任务。
采用双亲委派的一个好处是比如加载位于rt.jar包中的类java.lang.Object，不管是哪个加载器加载这个类，最终都是委托给顶层的启动类加载器进行加载，这样就保证了使用不同的类加载器最终得到的都是同样一个Object对象。
在有些情境中可能会出现要我们自己来实现一个类加载器的需求，由于这里涉及的内容比较广泛，我想以后单独写一篇文章来讲述，不过这里我们还是稍微来看一下。我们直接看一下jdk中的ClassLoader的源码实现：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
protected
synchronized
Class loadClass(String name,
boolean
resolve)
throws
ClassNotFoundException {
// First, check if the class has already been loaded
Class c = findLoadedClass(name);
if
(c ==
null
) {
try
{
if
(parent !=
null
) {
c = parent.loadClass(name,
false
);
}
else
{
c = findBootstrapClass0(name);
}
}
catch
(ClassNotFoundException e) {
// If still not found, then invoke findClass in order
// to find the class.
c = findClass(name);
}
}
if
(resolve) {
resolveClass(c);
}
return
c;
}
|
- 首先通过Class c = findLoadedClass(name);判断一个类是否已经被加载过。
- 如果没有被加载过执行if (c == null)中的程序，遵循双亲委派的模型，首先会通过递归从父加载器开始找，直到父类加载器是Bootstrap ClassLoader为止。
- 最后根据resolve的值，判断这个class是否需要解析。
而上面的findClass()的实现如下，直接抛出一个异常，并且方法是protected，很明显这是留给我们开发者自己去实现的，这里我们以后我们单独写一篇文章来讲一下如何重写findClass方法来实现我们自己的类加载器。
|
1
2
3
|
protected
Class findClass(String name)
throws
ClassNotFoundException {
throw
new
ClassNotFoundException(name);
}
|
References
还有另外一个角度对JVM的类加载机制的理解，这里放到一起进行学习。
JVM结构
Java编写的代码会按照下图的流程来执行：
图 1: Java代码执行流程
类装载器装载负责装载编译后的字节码，并加载到运行时数据区（Runtime Data Area），然后执行引擎执行会执行这些字节码。
类加载器（Class Loader）
Java提供了动态的装载特性；它会在运行时的第一次引用到一个class的时候对它进行装载和链接，而不是在编译期进行。JVM的类装载器负责动态装载。Java类装载器有如下几个特点：
- 层级结构：Java里的类装载器被组织成了有父子关系的层级结构。Bootstrap类装载器是所有装载器的父亲。
- 代理模式：基于层级结构，类的装载可以在装载器之间进行代理。当装载器装载一个类时，首先会检查它是否在父装载器中进行装载了。如果上层的装载器已经装载了这个类，这个类会被直接使用。反之，类装载器会请求装载这个类。
- 可见性限制：一个子装载器可以查找父装载器中的类，但是一个父装载器不能查找子装载器里的类。
- 不允许卸载：类装载器可以装载一个类但是不可以卸载它，不过可以删除当前的类装载器，然后创建一个新的类装载器。
每个类装载器都有一个自己的命名空间用来保存已装载的类。当一个类装载器装载一个类时，它会通过保存在命名空间里的类全局限定名(Fully Qualified Class Name)进行搜索来检测这个类是否已经被加载了。如果两个类的全局限定名是一样的，但是如果命名空间不一样的话，那么它们还是不同的类。不同的命名空间表示class被不同的类装载器装载。
下图展示了类装载器的代理模型。
图 2: 类加载器代理模型
当一个类装载器（class loader）被请求装载类时，它首先按照顺序在上层装载器、父装载器以及自身的装载器的缓存里检查这个类是否已经存在。简单来说，就是在缓存里查看这个类是否已经被自己装载过了，如果没有的话，继续查找父类的缓存，直到在bootstrap类装载器里也没有找到的话，它就会自己在文件系统里去查找并且加载这个类。
- 启动类加载器（Bootstrap class loader）：这个类装载器是在JVM启动的时候创建的。它负责装载Java API，包含Object对象。和其他的类装载器不同的地方在于这个装载器是通过native code来实现的，而不是用Java代码。
- 扩展类加载器（Extension class loader）：它装载除了基本的Java API以外的扩展类。它也负责装载其他的安全扩展功能。
- 系统类加载器（System class loader）：如果说bootstrap class loader和extension class loader负责加载的是JVM的组件，那么system class loader负责加载的是应用程序类。它负责加载用户在$CLASSPATH里指定的类。
- 用户自定义类加载器（User-defined class loader）:这是应用程序开发者用直接用代码实现的类装载器。
类似于web应用服务(WAS)之类的框架会用这种结构来对Web应用和企业级应用进行分离。换句话来说，类装载器的代理模型可以用来保证不同应用之间的相互独立。WAS类装载器使用这种层级结构，不同的WAS供应商的装载器结构有稍许区别。
如果类装载器查找到一个没有装载的类，它会按照下图的流程来装载和链接这个类：
图 3: 类加载的各个阶段
每个阶段的描述如下：
- Loading：类的信息从文件中获取并且载入到JVM的内存里。
- Verifying：检查读入的结构是否符合Java语言规范以及JVM规范的描述。这是类装载中最复杂的过程，并且花费的时间也是最长的。并且JVM TCK工具的大部分场景的用例也用来测试在装载错误的类的时候是否会出现错误。
- Preparing：分配一个结构用来存储类信息，这个结构中包含了类中定义的成员变量，方法和接口的信息。
- Resolving：把这个类的常量池中的所有的符号引用改变成直接引用。
- Initializing：把类中的变量初始化成合适的值。执行静态初始化程序，把静态变量初始化成指定的值。
JVM规范定义了上面的几个任务，不过它允许具体执行的时候能够有些灵活的变动。
运行时数据区(Runtime Data Areas)
图 4: 运行时数据区
运行时数据区是在JVM运行的时候操作系统所分配的内存区。运行时内存区可以划分为6个区域。在这6个区域中，一个PC Register,JVM stack 以及Native Method Statck都是按照线程创建的，Heap,Method Area以及Runtime Constant Pool都是被所有线程公用的。
- PC寄存器(PC register):每个线程启动的时候，都会创建一个PC（Program Counter，程序计数器）寄存器。PC寄存器里保存有当前正在执行的JVM指令的地址。
- JVM 堆栈(JVM stack)：每个线程启动的时候，都会创建一个JVM堆栈。它是用来保存栈帧的。JVM只会在JVM堆栈上对栈帧进行push和pop的操作。如果出现了异常，堆栈跟踪信息的每一行都代表一个栈帧立的信息，这些信息是通过类似于printStackTrace()这样的方法来展示的。
图 5: JVM堆栈
--- 栈帧(stack frame)：每当一个方法在JVM上执行的时候，都会创建一个栈帧，并且会添加到当前线程的JVM堆栈上。当这个方法执行结束的时候，这个栈帧就会被移除。每个栈帧里都包含有当前正在执行的方法所属类的本地变量数组，操作数栈，以及运行时常量池的引用。本地变量数组的和操作数栈的大小都是在编译时确定的。因此，一个方法的栈帧的大小也是固定不变的。
--- 局部变量数组(Local variable array)：这个数组的索引从0开始。索引为0的变量表示这个方法所属的类的实例。从1开始，首先存放的是传给该方法的参数，在参数后面保存的是方法的局部变量。
--- 操作数栈(Operand stack)：方法实际运行的工作空间。每个方法都在操作数栈和局部变量数组之间交换数据，并且压入或者弹出其他方法返回的结果。操作数栈所需的最大空间是在编译期确定的。因此，操作数栈的大小也可以在编译期间确定。
- 本地方法栈(Native method stack)：供用非Java语言实现的本地方法的堆栈。换句话说，它是用来调用通过JNI(Java Native Interface Java本地接口）调用的C/C++代码。根据具体的语言，一个C堆栈或者C++堆栈会被创建。
- 方法区(Method area)：方法区是所有线程共享的，它是在JVM启动的时候创建的。它保存所有被JVM加载的类和接口的运行时常量池，成员变量以及方法的信息，静态变量以及方法的字节码。JVM的提供者可以通过不同的方式来实现方法区。在Oracle 的HotSpot JVM里，方法区被称为永久区或者永久代（PermGen）。是否对方法区进行垃圾回收对JVM的实现是可选的。
- 运行时常量池(Runtime constant pool)：这个区域和class文件里的constant_pool是相对应的。这个区域是包含在方法区里的，不过，对于JVM的操作而言，它是一个核心的角色。因此在JVM规范里特别提到了它的重要性。除了包含每个类和接口的常量，它也包含了所有方法和变量的引用。简而言之，当一个方法或者变量被引用时，JVM通过运行时常量区来查找方法或者变量在内存里的实际地址。
- 堆(Heap)：用来保存实例或者对象的空间，而且它是垃圾回收的主要目标。当讨论类似于JVM性能之类的问题时，它经常会被提及。JVM提供者可以决定怎么来配置堆空间，以及不对它进行垃圾回收。
现在我们再回过头来看看之前反汇编的字节码。
- public void add(java.lang.String);
- Code:
- 0: aload_0
- 1: getfield #15; //Field admin:Lcom/nhn/user/UserAdmin;
- 4: aload_1
- 5: invokevirtual #23; //Method com/nhn/user/UserAdmin.addUser:(Ljava/lang/String;)Lcom/nhn/user/User;
- 8: pop
- 9: return
把上面的反汇编代码和我们平时所见的x86架构的汇编代码相比较，我们会发现这两者的结构有点相似，都使用了操作码；不过，有一点不同的地方是Java字节码并不会在操作数里写入寄存器的名称、内存地址或者偏移量。之前已经说过，JVM用的是栈，它不会使用寄存器。和使用寄存器的x86架构不同，它自己负责内存的管理。它用索引例如15和23来代替实际的内存地址。15和23都是当前类（这里是UserService类）的常量池里的索引。简而言之，JVM为每个类创建了一个常量池，并且这个常量池里保存了实际目标的引用。
每行反汇编代码的解释如下：
- aload_0: 把局部变量数组中索引为#0的变量添加到操作数栈上。索引#0所表示的变量是this，即是当前实例的引用。
- getfield #15: 把当前类的常量池里的索引为#15的变量添加到操作数栈。这里添加的是UserAdmin的admin成员变量。因为admin变量是个类的实例，因此添加的是一个引用。
- aload_1: 把局部变量数组里的索引为#1的变量添加到操作数栈。来自局部变量数组里的索引为1的变量是方法的一个参数。因此，在调用add()方法的时候，会把userName指向的String的引用添加到操作数栈上。
- invokevirtual #23: 调用当前类的常量池里的索引为#23的方法。这个时候，通过getfile和aload_1添加到操作数栈上的引用都被作为方法的参数。当方法运行完成并且返回时，它的返回值会被添加到操作数栈上。
- pop: 把通过invokevirtual调用的方法的返回值从操作数栈里弹出来。你可以看到，在前面的例子里，用老的类库编译的那段代码是没有返回值的。简而言之，正因为之前的代码没有返回值，所以没必要吧把返回值从操作数栈上给弹出来。
- return：结束当前方法调用。
下图可以帮助你更好地理解上面的内容。
6: 装载到运行时数据区的Java字节码示例
顺便提一下，在这个方法里，局部变量数组没有被修改。所以上图只显示了操作数栈的变化。不过，大部分的情况下，局部变量数组也是会改变的。局部变量数组和操作数栈之间的数据传输是使用通过大量的load指令(aload,iload)和store指令（astore,istore)来实现的。
在这个图里，我们简单验证了运行时常量池和JVM栈的描述。当JVM运行的时候，每个类的实例都会在堆上进行分配，User，UserAdmin，UserService以及String等类的信息都会保存在方法区。
执行引擎（Execution Engine）
通过类装载器装载的，被分配到JVM的运行时数据区的字节码会被执行引擎执行。执行引擎以指令为单位读取Java字节码。它就像一个CPU一样，一条一条地执行机器指令。每个字节码指令都由一个1字节的操作码和附加的操作数组成。执行引擎取得一个操作码，然后根据操作数来执行任务，完成后就继续执行下一条操作码。
不过Java字节码是用一种人类可以读懂的语言编写的，而不是用机器可以直接执行的语言。因此，执行引擎必须把字节码转换成可以直接被JVM执行的语言。字节码可以通过以下两种方式转换成合适的语言。
- 解释器：一条一条地读取，解释并且执行字节码指令。因为它一条一条地解释和执行指令，所以它可以很快地解释字节码，但是执行起来会比较慢。这是解释执行的语言的一个缺点。字节码这种“语言”基本来说是解释执行的。
- 即时(Just-In-Time)编译器：即时编译器被引入用来弥补解释器的缺点。执行引擎首先按照解释执行的方式来执行，然后在合适的时候，即时编译器把整段字节码编译成本地代码。然后，执行引擎就没有必要再去解释执行方法了，它可以直接通过本地代码去执行它。执行本地代码比一条一条进行解释执行的速度快很多。编译后的代码可以执行的很快，因为本地代码是保存在缓存里的。
不过，用JIT编译器来编译代码所花的时间要比用解释器去一条条解释执行花的时间要多。因此，如果代码只被执行一次的话，那么最好还是解释执行而不是编译后再执行。因此，内置了JIT编译器的JVM都会检查方法的执行频率，如果一个方法的执行频率超过一个特定的值的话，那么这个方法就会被编译成本地代码。
图 7:Java编译器和JIT编译器
JVM规范没有定义执行引擎该如何去执行。因此，JVM的提供者通过使用不同的技术以及不同类型的JIT编译器来提高执行引擎的效率。
大部分的JIT编译器都是按照下图的方式来执行的：
图 8: JIT编译器
JIT编译器把字节码转换成一个中间层表达式，一种中间层的表示方式，来进行优化，然后再把这种表示转换成本地代码。
Oracle Hotspot VM使用一种叫做热点编译器的JIT编译器。它之所以被称作”热点“是因为热点编译器通过分析找到最需要编译的“热点”代码，然后把热点代码编译成本地代码。如果已经被编译成本地代码的字节码不再被频繁调用了，换句话说，这个方法不再是热点了，那么Hotspot VM会把编译过的本地代码从cache里移除，并且重新按照解释的方式来执行它。Hotspot VM分为Server VM和Client VM两种，这两种VM使用不同的JIT编译器。
Figure 9: Hotspot Client VM and Server VM
Client VM 和Server VM使用完全相同的运行时，不过如上图所示，它们所使用的JIT编译器是不同的。Server VM用的是更高级的动态优化编译器，这个编译器使用了更加复杂并且更多种类的性能优化技术。
IBM 在IBM JDK 6里不仅引入了JIT编译器，它同时还引入了AOT(Ahead-Of-Time)编译器。它使得多个JVM可以通过共享缓存来共享编译过的本地代码。简而言之，通过AOT编译器编译过的代码可以直接被其他JVM使用。除此之外，IBM JVM通过使用AOT编译器来提前把代码编译器成JXE（Java EXecutable)文件格式来提供一种更加快速的执行方式。
大部分Java程序的性能都是通过提升执行引擎的性能来达到的。正如JIT编译器一样，很多优化的技术都被引入进来使得JVM的性能一直能够得到提升。最原始的JVM和最新的JVM最大的差别之处就是在于执行引擎。
Hotspot编译器在1.3版本的时候就被引入到Oracle Hotspot VM里了，JIT编译技术在Anroid 2.2版本的时候被引入到Dalvik VM里。
注意：
引入一种中间语言，例如字节码，虚拟机执行字节码，并且通过JIT编译器来提升JVM的性能的这种技术以及广泛应用在使用中间语言的编程语言上。例如微软的.Net，CLR（Common Language Runtime 公共语言运行时），也是一种VM，它执行一种被称作CIL（Common Intermediate Language）的字节码。CLR提供了AOT编译器和JIT编译器。因此，用C#或者VB.NET编写的源代码被编译后，编译器会生成CIL并且CIL会执行在有JIT编译器的CLR上。CLR和JVM相似，它也有垃圾回收机制，并且也是基于堆栈运行。
Java虚拟机规范，Java SE 第7版
2011年7月28日，Oracle发布了Java SE的第7个版本，并且把JVM规也更新到了相应的版本。在1999年发布《The Java Virtual Machine Specification,Second Edition》后，Oracle花了12年来发布这个更新的版本。这个更新的版本包含了这12年来累积的众多变化以及修改，并且更加细致地对规范进行了描述。此外，它还反映了《The Java Language Specificaion,Java SE 7 Edition》里的内容。主要的变化总结如下：
- 来自Java SE 5.0里的泛型，支持可变参数的方法
- 从Java SE 6以来，字节码校验的处理技术所发生的改变
- 添加invokedynamic指令以及class文件对于该指令的支持
- 删除了关于Java语言概念的内容，并且指引读者去参考Java语言规范
- 删除关于Java线程和锁的描述，并且把它们移到Java语言规范里
最大的改变是添加了invokedynamic指令。也就是说JVM的内部指令集做了修改，使得JVM开始支持动态类型的语言，这种语言的类型不是固定的，例如脚本语言以及来自Java SE 7里的Java语言。之前没有被用到的操作码186被分配给新指令invokedynamic，而且class文件格式里也添加了新的内容来支持invokedynamic指令。
Java SE 7的编译器生成的class文件的版本号是51.0。Java SE 6的是50.0。class文件的格式变动比较大，因此，51.0版本的class文件不能够在Java SE 6的虚拟机上执行。
尽管有了这么多的变动，但是Java方法的65535字节的限制还是没有被去掉。除非class文件的格式彻底改变，否者这个限制将来也是不可能去掉的。
值得说明的是，Oracle Java SE 7 VM支持G1这种新的垃圾回收机制，不过，它被限制在Oracle JVM上，因此，JVM本身对于垃圾回收的实现不做任何限制。也因此，在JVM规范里没有对它进行描述。