《深入理解Java虚拟机》—— Java运行时数据区域

[funnycoding]

2.1 概述

对于 C 和 C++ 的开发人员来说，他们需要管理对象的生命周期，从创建到终结。

而对于 Java 开发人员来说，对象的回收由 JVM 负责， Java 开发人员不需要为每一个 new 操作去写配套的 delete/free 代码，同时 JVM 也不容易出现 内存泄漏和内存溢出的问题。

但是相对的，封装的层级越高，真正出问题的时候寻找原因就越麻烦，而排查问题的前提就是去了解 JVM 是怎样使用内存的，以及JVM 中定义的 Java 内存模型。

本章作者从**概念上介绍虚拟机内存**的各个区域，讲解这些区域的作用，服务对象，以及可能产生的问题，也是非常基础且重要的一个章节。

2.2 运行时数据区域

Java 虚拟机会在程序执行时将数据划分为几个不同的数据区域。 这些区域有着**不同的用途，创建和销毁的时间**，有的区域随着虚拟机进程的启动而一直存在，有的区域则随着用户线程的启动和结束而建立和销毁。

根据 **《Java虚拟机规范》的规定，Java虚拟机管理的内存区域包括以下几个运行时**区域：

2.2.1 程序计数器

**性质：线程私有，占用空间小，不会发生OOM，是当前线程执行字节码的行号指示器。**从图中可以看到，这块空间是私有的，因为每个线程都有自己的执行进度。

在 Java 虚拟机的概念模型①中：字节码解释器工作时通过改变这个计数器的值来选取下一条需要执行的字节码指令，它是程序控制流的指示器，分支、循环、跳转、依赖、异常处理、**线程恢复**等基础功能都需要依赖这个计数器来完成。

可以看到，这是相当基础且重要的功能，相当于是每个线程的控制器。

Java 虚拟机中的**多线程是通过线程轮流切换，分配CPU执行时间片的方式实现的，在任何一个确定的时刻，一个处理器（对于多核处理器来说，是其中的一个内核）都只会执行一条线程中的指令。而程序计数器就担任着线程切换后继续执行线程代码的责任，所以每条线程都有一个独立的「程序计数器」，各线程之间的计数器互不影响，独立存储，我们称这样的区域为「线程私有**」内存。

程序计数器存储的内容：

• 如果线程执行的是 Java 方法，则记录的是正在执行**的 虚拟机字节码指令地址**
• 如果正在执行的是本地方法（Native），则**程序计数器的值为空**（Undefined）

该区域是《Java虚拟机规范》中唯一一个没有规定任何OOM发生的区域，即该区域不会产生内存溢出错误。

①：「概念模型」这个词经常被提到，它代表了所有虚拟机的统一外观，但各个具体的Java 虚拟机并不一定要完全按照概念模型的定义来进行设计，可能会通过更高效的「等价方式」去实现概念模型。

2.2.2 Java 虚拟机栈

性质：线程私有，生命周期与线程相同

虚拟机栈描述的是 Java 方法执行的线程内存模型：每个方法被执行的时候，Java虚拟机都会同步的创建一个「栈桢」①（Stack Frame），用于存储 「局部变量表」、「操作数栈」，「动态连接」，「方法出口」 等信息。

每一个方法从被调用到执行完毕这个过程就对应着一个栈桢在虚拟机中从入栈到出栈的过程。

我们经常将 Java 中的内存区域简单粗暴的划分为 「堆」 和 「栈」，所谓的栈指的就是这里的「虚拟机栈」了，或者更多情况下其内容仅仅对应的是 虚拟机栈中的「局部变量表」 部分。

局部变量表：存放了编译期间可知的各种

• Java 虚拟机基本数据类型（boolean，byte，char，short，int，float，long，double）
• 对象引用（reference 类型，它可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或者其他与此对象相关的位置）
• returnAddress 类型（指向一条字节码指令的地址）

局部变量表中的具体存储模式：使用**变量槽（Slot）存储数据**，64位长度的 long 和 double 类型的会占用2个变量槽，其余数据类型占用1个。

局部变量表所需的内存空间在编译期就已经完成分配（因为是可知的），当进入一个方法时，这个方法需要在栈桢中分配多大的局部变量空间是完全确定的，在方法运行期间不会改变局部变量表的大小。 —— 这里的大小指的是变量槽的数量，而每个槽对应的真实内存占用大小则是虚拟机自行实现。

虚拟机栈中可能发生的异常：

• StackOverflowError：当**线程请求的栈深度大于虚拟机允许的栈深度**时，出现该异常。
• 在**JVM 允许 虚拟机栈动态扩展容量的前提下**，则可能发生 OOM ②异常。

①：栈桢是方法运行时期很重要的数据结构，在本书的 第8章 中对其进行详细讲解。

②：HotSpot 虚拟机的栈容量是不可以动态扩展的，以前的 Classic 虚拟机可以。 所以在 HotSpot 中不会因为虚拟机栈无法扩展导致 OOM 异常 —— 只要线程申请栈空间成功，就不会出现OOM，但是**如果申请时就失败，则仍然会出现OOM异常，这里的异常原因不是动态扩容导致的。**

2.2.3 本地方法栈

本地方法栈与虚拟机栈所发挥的作用**非常相似**，区别是本地方法栈为虚拟机使用到的本地方法服务，而虚拟机栈则是为虚拟机使用到的 Java 方法服务。

《Java 虚拟机规范》对本地方法栈中的方法使用的语言，使用方式，数据结构没有任何强制规定，具体的虚拟机可以根据需要自由地实现。例如 HotSpot虚拟机直接将本地方法栈和虚拟机栈合二为一。

2.2.4 Java 堆

下图是 Java 堆空间中的分类。

对于 Java 应用程序来说，「堆」 是 虚拟机所管理的内存中**最大的一块，堆也是线程中共享的一块内存区域，在虚拟机启动时创建**。

Java 堆中存放着几乎所有的对象实例。《Java 虚拟机规范》 中这样描述堆：所有的对象实例以及数组都应当在堆上分配。

而这里的几乎是指从实现角度来看，随着 Java 语言的发展，现在已经能看到一些迹象表示日后可能出现值类型的支持，即使只考虑现在，由于**即时编译技术的进步，尤其是逃逸分析技术的日渐强大，栈上分配、标量替换**优化手段已经导致并不是绝对的所有对象都在堆上产生。

Java 堆是垃圾收集器管理的内存区域，因此一些资料中它也被称为 GC 堆。从回收内存的角度来看，由于现代垃圾收集器大部分都是基于「分代收集」理论设计，所以 Java 堆中经常出现**「新生代」、「老年代」、「永久代」、「Eden空间」、「From Survivor 空间」、「To Survivor 空间」等名词、这些区域的划分仅仅是一些垃圾收集器的共同特性或者设计风格而已，而非某个 Java 虚拟机具体实现的固有内存布局，更不是《Java 虚拟机规范》里对 Java 堆的进一步细致划分。**

在**十年前，以 G1 收集器的出现作为分界，作为业界绝对主流的 HotSpot 虚拟机的内部垃圾收集器全部基于「经典分代」设计，需要 新生代、老年代收集器搭配才能工作，在这样的背景下，上面的说法还算是不会产生太大歧义。但是到了今天，垃圾收集器技术与十年前已经不可用同日而语，HotSpot** 里也出现了**不采用 分代设计的新垃圾收集器**，再按之前的说法来定义就有很多不准确的地方了。

从分配内存的角度看：所有线程共享的 Java 堆中可以划分出多个线程私有的「分配缓冲区」（Thread Local Allocation Buffer TLAB）来**提升对象分配时的效率**。

但是不管如何划分，都不会改变 Java堆中存储的内容的性质：无论哪个区域，存储的都只能是「对象实例」，将Java 堆进行细分的目的是为了**更好地回收内存，或者更快的分配内存**。

根据 《Java 虚拟机规范》 规定，Java 堆可以处于物理上不连续的内存空间中，但是逻辑上是连续的，这就像是用磁盘存储文件一样，并不要求每个文件连续存放，但对于大对象（比如数组）多数虚拟机实现出于简单、存储高效的考虑，很可能会要求连续的内存空间来存放数组。

Java堆可以是**固定大小，也可以是可扩展的，通过 -Xmx 和 -Xms 参数设定。如果Java堆中没有足够的内存完成实例分配，并且堆也无法继续扩展，则抛出OOM内存溢出异常**。

2.2.5 方法区

方法区（Method Area) ：线程共享，存储已被虚拟机加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

《Java 虚拟机规范》中把方法区描述为「堆的一个逻辑部分」，但是方法区有一个别名叫做「非堆」（Non-Heap），目的是与 Java堆区分开。

方法区与「永久代」这个概念经常放在一起说，因为在 JDK8 以前，许多Java程序员都习惯在 HotSpot 虚拟机上开发部署程序，于是很多人更愿意把方法区称呼为「永久代」（Permanent Generation），或者将两者混为一谈。

本质上方法区和永久代并不是等价的，仅仅因为当时 HotSpot 虚拟机设计团队选择把收集器的分代设计扩展到方法区，或者说使用永久代来实现方法区而已，这样使 HotSpot 的垃圾收集器能够像管理 「Java堆」一样管理这部分方法区的内存，省去专门为方法区编写内存管理代码的工作。

但是其他虚拟机例如 BEA JRockit、IBM J9 等，是**不存在永久代这个概念**的。 如何实现方法区属于虚拟机实现细节，不受 《Java虚拟机规范》约束，并不要求统一。

但是现在回头看，当时使用永久代实现方法区的决定并不是一个好注意，这种设计导致 Java 应用更容易遇到内存溢出问题。（永久代有 -XX:MaxPermSize 的上限，即使不设置也有一个默认大小，而 J9 和 JRockit 只要没有触碰到进程可用内存的上限，例如32位系统的上限 4GB内存限制，则就不会出现问题。）

而且存在极少数方法（String::inter()) 会因为永久代的原因导致不同虚拟机下有不同的表现。

当 Oracle 收购 BEA 获得 JRockit 所有权后，准备将其中的优秀功能 例如 Java Mission Control 管理工具移植到 HotSpot 虚拟机时，但是因为 JRockit 和 HotSpot 对于方法区的实现差异而面临着很多困难，考虑到 HotSpot 未来的发展，从 JDK6开始，HotSpot 开发团队就有放弃永久代，逐步改为使用本地内存来实现方法区的计划。

到了 JDK7 时的 HotSpot，已经将原本放在永久代中的 「字符串常量池」、「静态变量」。等移出永久代，到了 JDK8，完全废弃了永久代的概念，此时HotSpot 与 JRockit 、J9一样，在**本地内存中实现的元空间（Meta-sapace）代替了之前的永久代，将 JDK7 中永久代的剩余内容（主要是类型信息**）移动到元空间中。

《Java 虚拟机规范》对于方法区的约束非常宽松，该区域可以使用不连续的内存，可以选择固定大小和可扩展大小，甚至可以选择不实现垃圾收集。这部分区域的内存回收目标主要是针对「常量池」的回收和对Java 类型的卸载，一般来说针对这个区域的回收效果并不令人满意，尤其是类型卸载的条件非常苛刻，但是对于这部分的回收又是必要的，之前出现过若干严重bug就是这部分区域的回收出现问题导致**内存泄漏**。

根据《Java虚拟机规范》规定，方法区如果无法满足新的内存分配需求，抛出 OOM 异常。

为什么要将永久代（PermGen）替换为元空间（MetaSpace）呢？

其中一个原因是因为 永久代受 JVM本身设置影响，有固定的内存大小上限，而元空间使用的是机器的直接内存，只受本机可用内存限制，不会出现 OOM 异常。

可以使用 -XX:MaxMetaSpaceSize 设置最大元空间大小，默认值 unlimited。

2.2.6 运行时常量池

运行时常量池（Runtime Constant Pool）是方法区的一部分。 Class 文件中除了有 类的版本、字段、方法、接口等**描述信息外，还有一项信息是「常量池表」（Constant Pool Table），用于存放编译期生成的各种字面量与符号引用，这部分内容将在类加载后放到方法区的运行时常量池**中。

Java虚拟机对于 Class 文件的每一部分都有严格规定 —— 例如每个字节用于存储哪种数据都必须符合规范上的要求才会被虚拟机认可、加载和执行，但对于运行时常量池，《Java 虚拟机规范》没有做任何细节要求，这使得不同提供商实现的虚拟机可以按照自己的需求来实现这个内存区域。

一般来说，除了保存 Class 文件中描述的**符号引用外，还会把符号引用翻译出来的直接引用也存储在运行时常量池中**。①

**运行时常量池**相对于 **Class 文件常量池**的另外一个重要特征是：具备动态性。 Java 语言并不要求常量一定只有在编译期才能产生，也就是说，并非只有预置在 Class 文件常量池中的内容才能进入方法区运行时常量池，在程序运行期间也可以将新的常量添加到池中。比如 String 类的 intern() 方法就是将字符串添加到运行时常量池中。

运行时常量池是方法区的一部分，所以当常量池无法再申请到内存时会抛出 OOM 异常。

2.2.7 直接内存

直接内存不是虚拟机运行时数据区域的一部分，也不是《Java 虚拟机规范》中定义的内存区域。但是这部分内存也被频繁地使用，而且可能导致 OOM 异常出现，所以作者在这里一起进行讲解。

JDK 1.4 中加入了 NIO（New Input/Output)类，引入了一种「基于通道」（Channel）与「缓冲区」（Buffer）的I/O 方式，它可以使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样在一些场景中能显著提高性能，因为避免了 Java 堆和 Native 堆之间来回复制数据的开销。

本机直接内存是不会受到 Java堆大小的限制，但是既然是内存，则肯定还是受到本机总内存（包括物理内存，SWAP 分区或者分页文件）大小以及处理器寻址空间的限制，一般配置虚拟机参数时，会根据实际内存设置 -Xmx等参数信息，但经常忽略了直接内存，如果各个内存区域的综合大于物理内存限制（包括实际物理内存和操作系统级的内存限制）从而导致动态扩展时内存不够，就会发生**OOM异常**。