【Java JVM】运行时数据区

JVM 在执行 Java 程序的过程中会把它管理的内存分为若干个不同的数据区域, 这些区域有着各自的用途。
根据《Java虚拟机规范》中规定, JVM 所管理的内存大致包括以下几个运行时数据区域, 如图所示:
Alt 'JvmRuntimeDataArea'
这个运行时数据区被分为了 5 大块

方法区 (Method Area)
堆 (Heap)
虚拟机栈 (Virtual Machine Stacks)
本地方法栈 (Native Method Stacks)
PC 寄存器 (Program Counter Register)

其中: 绿色部分是各个线程之间独享的部分, 而蓝色部分是所有线程共享的区域。

1 PC 寄存器 (Program Counter Register)

程序计数器是一块较小的内存分区, 你可以把它看做当前线程所执行的字节码的指示器(类似于, 记录了线程执行到了哪个位置, 下一步的位置)。在虚拟机的概念模型里, 字节码解释器工作时, 就是通过改变计数器的值来选择下一条需要执行的字节码指令。
程序技术器为线程私有, 每个线程都有它们各自的程序计数器, 这样在多线程的情况下, 线程之间的来回切换, 也能正确找到上次切换时执行的位置。
如果线程正在执行的是一个 Java 方法, 那么程序计数器记录的是当前线程正在执行的字节码指令的地址; 如果线程正在执行的是一个 native 方法, 则计数器值为空。
此内存区域是唯一一个 Java 虚拟机规范中没有规定任何 OutOfMemoryError (OOM) 情况的区域。

2 虚拟机栈 (Virtual Machine Stacks)

虚拟机栈是线程私有的, 它的生命周期与线程相同。
虚拟机栈可以看做是 Java 方法执行的内存模型: 每个方法执行的同时都会创建一个栈帧用于存储局部变量表, 操作数栈, 动态链接, 方法返回等信息。一个 Java 方法从调用到执行完的过程, 就对应着一个栈帧从虚拟机栈入栈到出栈的过程。
局部变量表中存放了编译期可知的基本数据类型, 对象引用, returnAddress 类型 (指向了一条字节码指令的地址)。局部变量表里面的数据类型的存储空间是以槽 (Slot) 表示的, 64 位的 long 和 double 类型占 2 个槽, 其他的只占 1 个。局部变量表所需的内存空间在编译器就完成分配了, 运行期间不会改变局部变量表的大小, 既槽的个数是确定的 (但是一个槽的所占的空间大小, 则是有 JVM 自行实现的, 可以是 32b, 64b 等)。
在虚拟机栈中可能会出现两种异常：StackOverflowError 和 OutOfMemory。

4.1 如果线程请求的栈深度大于当前 JVM 所允许的深度, 会抛出 StackOverflowError 异常
4.2 虚拟机栈可以动态扩展, 当扩展时无法申请到足够的内存, 会抛出 OutOfMemory 异常

3 本地方法栈 (Native Method Stacks)

本地方法栈与虚拟机栈所发挥的作用是非常相似的, 其区别只是虚拟机栈为 JVM 执行 Java 方法服务, 而本地方法栈则是为虚拟机使用到的本地 (Native) 方法服务。
在 HotSpot 虚拟机中直接把本地方法栈和虚拟机栈合二为一。
同样的本地方法栈也会抛出 StackOverflowError 和 OutOfMemory。

4 堆 (Heap)

JVM 只有一个堆, 同样的所有的线程共享这个堆, 他的生命周期同样和 JVM 一样。
堆主要存放的是类的实例和被分配的数组数据。
堆是 JVM 中内存最大的一块, 也是垃圾回收管理的主要区域, 堆在物理上是可以为不连续的内存空间, 只要逻辑上连续即可。
堆的实现是可以固定大小, 也可以是动态扩展的, 当堆的内存使用完了, 同样会抛出 OutOfMemoryError。

5 方法区 (Method Area)

JVM 只有一个方法区, 所有的线程共享着这个唯一的方法区, 他的生命周期和 JVM 一样。
方法区用于存储已被 JVM 加载的类型信息, 常量, 静态变量, 即时编译器编译后的代码等数据。
方法区逻辑上是属于堆的一部分, 它却有一个别名叫作 “非堆” (Non-Heap), 用于区分堆 (Heap)。
方法区中, 垃圾回收比较少见, 但并不是不进行 GC, 这个区域的回收目标主要是针对常量池的回收和对类的卸载, 当方法区内存不足时, 会导致 OutOfMemoryError (OOM)。
《Java虚拟机规范》对方法区的约束是非常宽松的, 所以导致对不同的 JVM 对这个区域的实现有差异。比如: HotSpot 用永久代来实现方法区, 但是其他的 JVM 没有这种方式, 不存在永久代的概念的。

说到 HotSpot, 就不能不说不同 JDK 版本下, 方法区的实现和几个常量池的概念。

5.1 HotSpot 方法区的实现

在 JDK8 之前, HotSpot 方法区是通过永久代的方式实现的, 但是到了 JDK8, 方法区的实现改为元空间 (MetaSpace) 的方式, 同时从以前的堆空间移到了本地内存 (Native memory) 中。

Metaspace 的组成

Klass Metaspace: 就是用来存 klass 的, klass 是我们熟知的 class 文件在 JVM 里的运行时数据结构, 这个区域不一定有的, 只有开启压缩指针, 同时 -Xmx (设定程序运行期间最大可占用的内存大小) 小于等于 32G (大于这个临界值, 会导致压缩指针关闭), 才会有这个区域
NoKlass Metaspace: 专门来存 klass 相关的其他的内容, 比如 method, constantPool 等, 虽然叫做 NoKlass Metaspace, 但是也其实可以存 klass 的内容。当然了, 如果没有 Metaspace 的时候, klass 内容也会存储在这里。

上面说的临界值 32G 的确定, 可以看这里聊一聊JAVA指针压缩的实现原理 (图文并茂, 让你秒懂)

5.2 常量池(Constant Pool)

在 JVM 中关于常量池的关键字有 class 常量池, 字符串常量池, 运行时常量池。

5.2.1 class 常量池

这里的 class 常量池, 主要指的是 class 文件里面的常量池。
当我们的 .java 文件编译为 .class 文件后, .class 文件里面有一个常量池的项,
用于存放编译器生成的各种字面量 (Literal) 和符号引用 (Symbolic References)。

字面量: 各种常量, 如文本字符串, final 的常量值。
符号引用: 一组符号描述所引用的目标。

class 常量池的内容, 如图
Alt 'ConstantPoolInClassFile'
在 .class 文件中的样子大体如下

Constant pool:
   #1 = Methodref          #4.#13         // java/lang/Object."<init>":()V
   #2 = Methodref          #3.#14         // SymbolicReference.fn2:()V
   #3 = Class              #15            // SymbolicReference
   #4 = Class              #16            // java/lang/Object

5.2.2 字符串常量池 (String Constant Pool)

在 JVM 中有一个字符串常量池, 在我们平常创建字符串时, 会先到这个字符串池中查看是否已有相关的字符串了, 有的话直接使用这个字符串, 没有再创建然后加入到这个字符串常量池中。

在 HotSpot 里实现的字符串常量池功能的是一个 StringTable 类, 它是一个 Hash 表, 默认值大小长度是 1009 (JDK7 及后面的版本可以通过参数进行修改)。

这个 StringTable 在每个 HotSpot 的实例只有一份, 被所有的类共享。

当类加载到了 JVM 后, 类中涉及到的字符串常量, 在堆中生成字符串对象实例, 会将这些字符串对象实例的引用值存到字符串常量池中, 既存到 StringTable 中。
也就是我们的字符串常量具体的值是放在堆中的, 但是会有个引用指向它, 同时这个引用存放在 StringTable 中。

Java 有一道经典的题目