Java 入门指南：JVM（Java虚拟机）—— Java 内存运行时的数据区域

前言

对于 Java 程序员来说，在虚拟机自动内存管理机制下，不再需要像 C/C++程序开发程序员这样为每一个 new 操作去写对应的 delete/free 操作，不容易出现内存泄漏和内存溢出问题。

由于程序员把内存控制权利交给 Java 虚拟机，一旦出现内存泄漏和溢出方面的问题，若不了解虚拟机是怎样使用内存的，排查错误将会是一个非常艰巨的任务。

运行时的数据区域

Java 虚拟机在执行 Java 程序的过程中会把它管理的内存划分成若干个不同的数据区域。

JDK 1.7：

图片来源：JavaGuide.cn

JDK 1.8：

Java 虚拟机规范对于运行时数据区域的规定是相当宽松的。以堆为例：堆可以是连续空间，也可以不连续。堆的大小可以固定，也可以在运行时按需扩展 。虚拟机实现者可以使用任何垃圾回收算法管理堆，甚至完全不进行垃圾收集也是可以的。

运行时常量池、方法区、字符串常量池这些都是不随虚拟机实现而改变的逻辑概念，是公共且抽象的

Metaspace、Heap 是与具体某种虚拟机实现相关的物理概念，是私有且具体的

线程私有的区域

线程私有的区域：程序计数器、虚拟机栈、本地方法栈

程序计数器

程序计数器是一块较小的内存空间，可以看作是当前线程所执行的字节码的行号指示器。

字节码解释器工作时通过改变这个计数器的值，来选取下一条需要执行的字节码指令，分支、循环、跳转、异常处理、线程恢复等功能都需要依赖这个计数器来完成，从而实现代码的流程控制。

另外，为了线程切换后能恢复到正确的执行位置，每条线程都需要有一个独立的程序计数器，当线程被切换回来的时候能够知道该线程上次运行到哪儿了。各线程之间计数器互不影响，独立存储，我们称这类内存区域为“线程私有”的内存。

⚠️ 程序计数器是唯一一个不会出现 OutOfMemoryError 的内存区域，它的生命周期随着线程的创建而创建，随着线程的结束而死亡。

Java虚拟机栈

Java 虚拟机栈的生命周期和线程相同，随着线程的创建而创建，随着线程的死亡而死亡。

作为 JVM 运行时数据区域的一个核心，除了一些 Native 方法调用是通过本地方法栈实现的，其他所有的 Java 方法调用都是通过栈来实现的（也需要和其他运行时数据区域比如程序计数器配合）。

方法调用的数据需要通过栈进行传递，每一次方法调用都会有一个对应的栈帧被压入栈中，每一个方法调用结束后，都会有一个栈帧被弹出。

栈由一个个栈帧组成，而每个栈帧中都拥有：局部变量表、操作数栈、动态链接、方法返回地址。

栈帧是方法运行时期十分重要的基础数据结构。和数据结构上的栈类似，两者都是先进后出的数据结构，只支持出栈和入栈两种操作。

局部变量表

局部变量表 主要存放了：

• 编译期可知的各种数据类型（boolean、byte、char、short、int、float、long、double）

• 对象引用（reference 类型，它不同于对象本身，可能是一个指向对象起始地址的引用指针，也可能是指向一个代表对象的句柄或其他与此对象相关的位置）。
  

操作数栈

操作数栈 主要作为方法调用的中转站使用，用于存放方法执行过程中产生的
中间计算结果。另外，计算过程中产生的临时变量也会放在操作数栈中。

动态链接

动态链接 主要服务一个方法需要调用其他方法的场景。Class 文件的常量池里保存有大量的符号引用比如方法引用的符号引用。当一个方法要调用其他方法，需要 将常量池中指向方法的符号引用转化为其在内存地址中的直接引用 。

其作用就是为了将符号引用转换为调用方法的直接引用，这个过程也被称为
动态连接 。

程序运行中栈可能会出现的问题

• 若栈的内存大小不允许动态扩展，如果函数调用陷入无限循环的话，就会导致栈中被压入太多栈帧而占用太多空间，导致栈空间过深。
  当线程请求栈的深度超过当前 Java 虚拟机栈的最大深度的时候，就抛出 StackOverFlowError 错误。

• 如果栈的内存大小可以动态扩展， 如果虚拟机在动态扩展栈时无法申请到足够的内存空间，则抛出 OutOfMemoryError 异常

Java 方法有两种返回方式，一种是 return 语句正常返回，一种是抛出异常。不管哪种返回方式，都会导致栈帧被弹出。栈帧随着方法调用而创建，随着方法结束而销毁。无论方法正常完成还是异常完成都算作方法结束。

以前的 Classic 虚拟机支持栈的动态扩展，
但 HotSpot虚拟机的栈容量不可以动态扩展 ，所有不会因为栈无法扩展而抛出 OOM 异常，然而在栈空间申请失败时仍会抛出 OOM 异常

本地方法栈

本地方法栈与虚拟机栈的作用相似

虚拟机栈为虚拟机执行 Java 方法 （也就是字节码）服务，而本地方法栈则为虚拟机使用到的 Native 方法服务。 在 HotSpot 虚拟机中和 Java 虚拟机栈合二为一。

本地方法被执行的时候，在本地方法栈也会创建一个栈帧，用于存放该本地方法的局部变量表、操作数栈、动态链接、出口信息。

本地方法栈保存了本地方法的执行状态，包括本地方法的参数、局部变量和返回结果等信息。通过本地方法栈，JVM能够在本地方法执行期间进行相关操作，如异常处理和垃圾回收等。

方法执行完毕后相应的栈帧也会出栈并释放内存空间，也会出现 StackOverFlowError 和 OutOfMemoryError 两种错误。

本地方法栈和Java虚拟机栈并不是完全独立的，它们可以共享一部分内存。但本地方法栈在内存分配和管理上与Java虚拟机栈是独立的。

线程共享的区域

线程共享的区域：堆、方法区、直接内存（非运行时数据区的一部分）

Java堆

Java 虚拟机所管理的内存中最大的一块，Java 堆是所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，几乎所有的对象实例以及数组都在这里分配内存。

Java 世界中“几乎”所有的对象都在堆中分配，但是，随着 JIT 编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

从 JDK 1.7 开始已经默认开启 逃逸分析（Escape Analysis），如果 某些方法中的对象引用没有被返回或者未被外面使用（也就是未逃逸出去），那么对象可以直接在栈上分配内存。

GC堆

Java 堆是垃圾收集器管理的主要区域，因此也被称作 GC 堆（Garbage Collected Heap）。从垃圾回收的角度，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆还可以细分为：新生代和老年代；再细致一点有：Eden、Survivor、Old 等空间。进一步划分的目的是更好地回收内存，或者更快地分配内存。

在 JDK 7 版本及 JDK 7 版本之前，堆内存被通常分为下面三部分：

1. 新生代内存(Young Generation)
2. 老生代(Old Generation)
3. 永久代(Permanent Generation)

下图所示的 Eden 区、两个 Survivor 区 S0 和 S1 都属于新生代，中间一层属于老年代，最下面一层属于永久代。

JDK 1.7 与 JDK 1.8 版本 Hotspot VM 堆结构的对比

图片来源：JavaGuide

JDK 8 版本之后 PermGen(永久代) 已被 Metaspace(元空间) 取代，元空间使用的是本地内存。

大部分情况，对象都会首先在 Eden 区域分配，在一次新生代垃圾回收后，如果对象还存活，则会进入 S0 或者 S1，并且对象的年龄还会加 1(Eden 区->Survivor 区后对象的初始年龄变为 1)。当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。

老年代的年龄阈值问题

因为记录年龄的区域在对象头中，这个区域的大小通常是 4 位。这 4 位可以表示的最大二进制数字是 1111，即十进制的 15。因此，对象的年龄被限制为 0 到 15。

老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 来设置。若设置的值在 0-15 范围之外，会爆出以下错误：

MaxTenuringThreshold of 20 is invalid; must be between 0 and 15

Hotspot 遍历所有对象时，按照年龄从小到大对其所占用的大小进行累积，当累积的某个年龄大小超过了 survivor 区的一半时，取这个年龄和 MaxTenuringThreshold 中更小的一个值，作为新的晋升年龄阈值

程序运行中堆的常见错误

堆这里最容易出现的就是 OutOfMemoryError 错误，并且出现这种错误之后的表现形式还会有几种，比如：

1. java.lang.OutOfMemoryError: GC Overhead Limit Exceeded：当 JVM 花太多时间执行垃圾回收并且只能回收很少的堆空间时，就会发生此错误。

2. java.lang.OutOfMemoryError: Java heap space :假如在创建新的对象时, 堆内存中的空间不足以存放新创建的对象, 就会引发此错误。(和配置的最大堆内存有关，且受制于物理内存大小。最大堆内存可通过-Xmx参数配置，若没有特别配置，将会使用默认值）

方法区

方法区属于是 JVM 运行时数据区域的一块逻辑区域，是各个线程共享的内存区域。在不同的虚拟机实现上，方法区的实现是不同的

当虚拟机要使用一个类时，它需要读取并解析 Class 文件获取相关信息，再将信息存入到方法区。方法区会存储已被虚拟机加载的 类信息、字段信息、方法信息、常量、静态变量、即时编译器编译后的代码缓存等数据。

• 类的元数据：包括类名、方法名、字段等信息。
• 静态变量：类级别的变量。
• 常量池：包括类或者接口的字面量（Literal）和符号引用（Symbolic References）。
• 即时编译后的代码：JIT编译器编译后的本地代码缓存。

方法区、永久代、元空间的关系

方法区和永久代以及元空间的关系很像 Java 中接口和类的关系，类实现了接口，这里的类就可以看作是永久代和元空间，接口可以看作是方法区

永久代以及元空间是 HotSpot 虚拟机对虚拟机规范中方法区的两种实现方式。并且，永久代是 JDK 1.8 之前的方法区实现，JDK 1.8 及以后方法区的实现变成了元空间。

在 JDK7 的 HotSpot ，原本放在永久代中的字符串常量值和静态变量等被移出，而到了 JDK8 ，便完全废弃了永久代的概念，改用与 JRockit 、 J9 一样在本地内存实现的元空间（MetaSpace）来替代，并把 JDK7 中永久代还剩余的内容
（主要为类型信息）全部移动到元空间中。

1. 整个永久代有一个 JVM 本身设置的固定大小上限，无法进行调整，而元空间使用的是本地内存，受本机可用内存的限制，虽然元空间仍旧可能溢出，但是比原来出现的几率会更小。当元空间溢出时会得到如下错误：

   java.lang.OutOfMemoryError: MetaSpace

可以使用 -XX：MaxMetaspaceSize 标志设置最大元空间大小，默认值为 unlimited，这意味着它只受系统内存的限制。-XX：MetaspaceSize 调整标志定义元空间的初始大小如果未指定此标志，则 Metaspace 将根据运行时的应用程序需求动态地重新调整大小。

2. 元空间里面存放的是类的元数据，这样加载多少类的元数据就不由 MaxPermSize 控制了, 而由系统的实际可用空间来控制，这样能加载的类就更多了。

3. 在 JDK8，合并 HotSpot 和 JRockit 的代码时, JRockit 从来没有一个叫永久代的东西, 合并之后就没有必要额外的设置这么一个永久代的地方了。

4. 永久代会为 GC 带来不必要的复杂度，并且回收效率偏低。

方法区常用参数

JDK 1.8 之前永久代还没被彻底移除的时候通常通过下面这些参数来调节方法区大小。

-XX:PermSize=N     //方法区 (永久代) 初始大小
-XX:MaxPermSize=N  //方法区 (永久代) 最大大小,超过这个值将会抛出 OutOfMemoryError 异常:java.lang.OutOfMemoryError: PermGen

相对而言，垃圾收集行为在这个区域是比较少出现的，但并非数据进入方法区后就“永久存在”了。

JDK 1.8 的时候，方法区（HotSpot 的永久代）被彻底移除了（JDK1.7 就已经开始了），取而代之是元空间，元空间使用的是本地内存。下面是一些常用参数：

-XX:MetaspaceSize=N     //设置 Metaspace 的初始（和最小大小）
-XX:MaxMetaspaceSize=N //设置 Metaspace 的最大大小

与永久代很大的不同就是，如果不指定大小的话，随着更多类的创建，虚拟机会耗尽所有可用的系统内存。

运行时常量池

Class 文件中除了有类的版本、字段、方法、接口 等描述信息外，还有用于存放编译期生成的各种字面量（Literal） 和符号引用（Symbolic Reference） 的 常量池表(Constant Pool Table) 。

• 字面量是源代码中的固定值的表示法，即通过字面我们就能知道其值的含义。字面量包括整数、浮点数和字符串字面量。

• 常见的符号引用包括类符号引用、字段符号引用、方法符号引用、
  接口方法符号

• 常量池表会在类加载后存放到方法区的运行时常量池中。

  运行时常量池的功能类似于传统编程语言的符号表，尽管它包含了比典型符号表更广泛的数据。

  既然运行时常量池是方法区的一部分，自然受到方法区内存的限制，当常量池无法再申请到内存时会抛出 OutOfMemoryError 错误。

符号引用 Symbolic References

符号引用以一组符号来描述所引用的目标，符号可以是任何形式的字面量，只要使用时能够无歧义的定位到目标即可。Symbolic References 与虚拟机实现的内存布局无关，引用的目标不一定是已将加载到虚拟机内存当中的内容。

各种虚拟机实现的内存布局可以各不相同，但它们能接受的符号引用必须一致，Symbolic References 的字面量形式明确定义在《Java 虚拟机规范》的Class文件格式中。

在Class文件中，符号引用以 CONSTANT_Methodref_info、
CONSTANT_Class_info、CONSTANT_Fieldred_info 等类型的常量出现。

直接引用 Direct References

直接引用是可以直接指向目标的指针、相对偏移量或一个能间接定位到目标的句柄。直接引用是 和虚拟机实现的内存布局直接相关 的，同一个符号引用在不同虚拟机实例翻译出的直接引用一般不相同。

若有了直接引用，那引用的目标必定已经在虚拟机的内存中存在。

解析

解析阶段是 Java 虚拟机将常量池内的符号引用替换成直接引用的过程。

字符串常量池

字符串常量池 是 JVM 为了提升性能和减少内存消耗针对字符串（String 类）专门开辟的一块区域，主要目的是为了避免字符串的重复创建。

// 在堆中创建字符串对象”ab“ 
// 将字符串对象”ab“的引用保存在字符串常量池中
String aa = "ab";
// 直接返回字符串常量池中字符串对象”ab“的引用
String bb = "ab"; 
System.out.println(aa==bb);  // true

HotSpot 虚拟机中字符串常量池的实现是 src/hotspot/share/classfile/stringTable.cpp

StringTable 可以简单理解为一个固定大小的 HashTable ，容量为 StringTableSize（可以通过 -XX:StringTableSize 参数来设置），保存的是字符串（key）和 字符串对象的引用（value）的映射关系，字符串对象的引用指向堆中的字符串对象。

JDK1.7 之前，字符串常量池存放在永久代。
JDK1.7 字符串常量池和静态变量从永久代移动到了 Java 堆中。

JDK 1.6 版本的方法区模型示例：

JDK 1.7 版本的方法区模型示例：

图片来源：JavaGuide

JDK 1.7 为什么要将字符串常量池移动到堆中

主要是因为永久代（方法区实现）的 GC 回收效率太低，只有在整堆收集 (Full GC)的时候才会被执行 GC 。Java 程序中通常会有大量的被创建的字符串等待回收，将字符串常量池放到堆中，能够更高效及时地回收字符串内存。

相关问题：JVM 常量池中存储的是对象还是引用呢？ - RednaxelaFX - 知乎

直接内存

直接内存是一种特殊的内存缓冲区，并不在 Java 堆或方法区中分配的，而是通过 JNI 的方式在本地内存上分配的。

直接内存并不是虚拟机运行时数据区的一部分，也不是虚拟机规范中定义的内存区域，但是这部分内存也被频繁地使用。而且也可能导致 OutOfMemoryError 错误出现。

JDK1.4 中新加入的 NIO（Non-Blocking I/O，也被称为 New I/O）（Java NIO 技术详解），引入了一种基于 通道（Channel） 与 缓存区（Buffer） 的 I/O 方式，它可以直接使用 Native 函数库直接分配堆外内存，然后通过一个存储在 Java 堆中的 DirectByteBuffer 对象作为这块内存的引用进行操作。这样避免了在 Java 堆和 Native 堆之间来回复制数据，在一些场景下能明显提高性能。

直接内存的分配不会受到 Java 堆的限制，但是，既然是内存就会受到本机总内存大小以及处理器寻址空间的限制。

类似的概念还有 堆外内存 。在一些文章中将直接内存等价于堆外内存，但这个说法不是特别准确。

堆外内存就是把内存对象分配在堆（新生代+老年代+永久代）以外的内存，这些内存直接受操作系统管理（而不是虚拟机），这样做的结果就是能够在一定程度上减少垃圾回收对应用程序造成的影响。