集册 Java 专题合集 Java 虚拟机

Java 虚拟机

欢马劈雪     最近更新时间：2020-08-04 05:37:59

181

Java 虚拟机工作原理详解

一、类加载器 首先来看一下 java 程序的执行过程。

从这个框图很容易大体上了解 java 程序工作原理。首先，你写好 java 代码，保存到硬盘当中。然后你在命令行中输入

javac YourClassName.java

此时，你的 java 代码就被编译成字节码（.class).如果你是在 Eclipse IDE 或者其他开发工具中，你保存代码的时候，开发工具已经帮你完成了上述的编译工作，因此你可以在对应的目录下看到 class 文件。此时的 class 文件依然是保存在硬盘中，因此，当你在命令行中运行

java YourClassName

就完成了上面红色方框中的工作。JRE 的来加载器从硬盘中读取 class 文件，载入到系统分配给 JVM 的内存区域--运行数据区（Runtime Data Areas). 然后执行引擎解释或者编译类文件，转化成特定 CPU 的机器码，CPU 执行机器码，至此完成整个过程。

接下来就重点研究一下类加载器究竟为何物？又是如何工作的？ 首先看一下来加载器的一些特点，有点抽象，不过总有帮助的。

》》层级结构 类加载器被组织成一种层级结构关系，也就是父子关系。其中，Bootstrap 是所有类加载器的父亲。如下图所示：

--Bootstrap class loader： 当运行 java 虚拟机时，这个类加载器被创建，它加载一些基本的 java API，包括 Object 这个类。需要注意的是，这个类加载器不是用 java 语言写的，而是用 C/C++ 写的。 --Extension class loader: 这个加载器加载出了基本 API 之外的一些拓展类，包括一些与安全性能相关的类。（目前了解得不是很深，只能笼统说，待日后再详细说明） --System Class Loader: 它加载应用程序中的类，也就是在你的 classpath 中配置的类。 --User-Defined Class Loader: 这是开发人员通过拓展 ClassLoader 类定义的自定义加载器，加载程序员定义的一些类。

》》委派模式（Delegation Mode） 仔细看上面的层次结构，当 JVM 加载一个类的时候，下层的加载器会将将任务委托给上一层类加载器，上一层加载检查它的命名空间中是否已经加载这个类，如果已经加载，直接使用这个类。如果没有加载，继续往上委托直到顶部。检查完了之后，按照相反的顺序进行加载，如果 Bootstrap 加载器找不到这个类，则往下委托，直到找到类文件。对于某个特定的类加载器来说，一个 Java 类只能被载入一次，也就是说在 Java 虚拟机中，类的完整标识是（classLoader，package，className）。一个雷可以被不同的类加载器加载。

举个具体的例子来说明，现在加入我有一个自己定义的类 MyClass 需要加载，如果不指定的话，一般交 App（System）加载。接到任务后，System 检查自己的库里是否已经有这个类，发现没有之后委托给 Extension，Extension 进行同样的检查，发现还是没有继续往上委托，最顶层的 Boots 发现自己库里也没有，于是根据它的路径（Java 核心类库，如 java.lang）尝试去加载，没找到这个 MaClass 类，于是只好（人家看好你，交给你完成，你无能为力，只好交给别人啦）往下委托给 Extension，Extension 到自己的路径（JAVA_HOME/jre/lib/ext)是找，还是没找到，继续往下，此时 System 加载器到 classpath 路径寻找，找到了，于是加载到 Java 虚拟机。 现在假设我们将这个类放到 JAVA_HOME/jre/lib/ext 这个路径中去（相当于交给 Extension 加载器加载），按照同样的规则，最后由 Extension 加载器加载 MyClass 类，看到了吧，统一各类被两次加载到 JVM，但是每次都是由不同的 ClassLoader 完成。

》》可见性限制 下层的加载器能够看到上层加载器中的类，反之则不行，也就是是说委托只能从下到上。

》》不允许卸载类 类加载器可以加载一个类，但是它不能卸载一个类。但是类加载器可以被删除或者被创建。

当类加载完毕之后，JVM 继续按照下图完成其他工作：

框图中各个步骤简单介绍如下： Loading：文章前面介绍的类加载，将文件系统中的 Class 文件载入到 JVM 内存（运行数据区域） Verifying：检查载入的类文件是否符合 Java 规范和虚拟机规范。 Preparing：为这个类分配所需要的内存，确定这个类的属性、方法等所需的数据结构。（Prepare a data structure that assigns the memory required by classes and indicates the fields, methods, and interfaces defined in the class.） Resolving：将该类常量池中的符号引用都改变为直接引用。（不是很理解） Initialing：初始化类的局部变量，为静态域赋值，同时执行静态初始化块。

那么，Class Loader 在加载类的时候，究竟做了些什么工作呢？ 要了解这其中的细节，必须得先详细介绍一下运行数据区域。

二、运行数据区域 Runtime Data Areas：当运行一个 JVM 示例时，系统将分配给它一块内存区域（这块内存区域的大小可以设置的），这一内存区域由 JVM 自己来管理。从这一块内存中分出一块用来存储一些运行数据，例如创建的对象，传递给方法的参数，局部变量，返回值等等。分出来的这一块就称为运行数据区域。运行数据区域可以划分为6大块：Java 栈、程序计数寄存器（PC 寄存器）、本地方法栈（Native Method Stack）、Java 堆、方法区域、运行常量池（Runtime Constant Pool）。运行常量池本应该属于方法区，但是由于其重要性，JVM 规范将其独立出来说明。其中，前面3各区域（PC 寄存器、Java 栈、本地方法栈）是每个线程独自拥有的，后三者则是整个 JVM 实例中的所有线程共有的。这六大块如下图所示：

》PC 计数器： 每一个线程都拥有一个 PC 计数器，当线程启动（start）时，PC 计数器被创建，这个计数器存放当前正在被执行的字节码指令（JVM 指令）的地址。 》Java 栈： 同样的，Java 栈也是每个线程单独拥有，线程启动时创建。这个栈中存放着一系列的栈帧（Stack Frame），JVM 只能进行压入（Push）和弹出（Pop）栈帧这两种操作。每当调用一个方法时，JVM 就往栈里压入一个栈帧，方法结束返回时弹出栈帧。如果方法执行时出现异常，可以调用 printStackTrace 等方法来查看栈的情况。栈的示意图如下：

OK。现在我们再来详细看看每一个栈帧中都放着什么东西。从示意图很容易看出，每个栈帧包含三个部分：本地变量数组，操作数栈，方法所属类的常量池引用。 》局部（本地）变量数组： 局部（本地）变量数组中，从0开始按顺序存放方法所属对象的引用、传递给方法的参数、局部变量。举个例子：

public void doSomething(int a, double b, Object o) {
...
}

这个方法的栈帧中的局部变量存储的内容分别是：

0: this
1: a
2,3:b
4:0

看仔细了，其中 double 类型的 b 需要两个连续的索引。取值的时候，取出的是2这个索引中的值。如果是静态方法，则数组第0个不存放 this 引用，而是直接存储传递的参数。 》操作数栈： 操作数栈中存放方法执行时的一些中间变量，JVM 在执行方法时压入或者弹出这些变量。其实，操作数栈是方法真正工作的地方，执行方法时，局部变量数组与操作数栈根据方法定义进行数据交换。例如，执行以下代码时，操作数栈的情况如下：

int a = 90;
int b = 10;
int c = a + b;

注意在这个图中，操作数栈的地步是在上边，所以先压入的100位于上方。可以看出，操作数栈其实是一个数据临时存储区，存放一些中间变量，方法结束了，操作数栈也就没有啦。 》栈帧中数据引用： 除了局部变量数组和操作数栈之外，栈帧还需要一个常量池的引用。当 JVM 执行到需要常量池的数据时，就是通过这个引用来访问常量池的。栈帧中的数据还要负责处理方法的返回和异常。如果通过 return 返回，则将该方法的栈帧从 Java 栈中弹出。如果方法有返回值，则将返回值压入到调用该方法的方法的操作数栈中。另外，数据区中还保存中该方法可能的异常表的引用。下面的例子用来说明：

class Example3C{
    public static void addAndPrint(){
        double result = addTwoTypes(1,88.88);
        System.out.println(result);
    }
    public static double addTwoTypes(int i, double d){
    return i+d;
    }

}

执行上述代码时，Java 栈如下图所示：

展开阅读全文