JVM 运行时堆内存如何分代?

Posted 2021-09-06 敲代码的程序狗

对于Java应用程序来说，Java堆（Java Heap）是虚拟机所管理的内存中最大的一块。Java堆是被所有线程共享的一块内存区域，在虚拟机启动时创建。此内存区域的唯一目的就是存放对象实例，所有的对象实例都在这里分配内存。

Java堆是垃圾收集器管理的内存区域。从回收内存的角度看，由于大部分垃圾收集器大部分都是基于分代收集理论设计的，所以 Java 堆中经常会出现“新生代”,“老年代”,“永久代”,“Eden空间”,“From Survivor空间”,“To Survivor空间”等区域。这些区域划分仅仅是一部分垃圾收集器的共同特性或者说设计风格而已，而非某个Java虚拟机具体实现的固有内存布局，不是《Java虚拟机规范》里对Java堆的官方的定义。比如：Shenandoah、ZGC 就不支持分代。

JDK 1.7 分代结构

在 JDK 1.7 以及之前堆空间分为 3 部分：新生代，老年代，永久代。
然后新生代分为：Eden 区， 和两个 Survivor 区。如下图所示:

JDK 1.8 分代结构

在 JDK 1.8 及其以后，堆空间中移除了永久代。

1. 这是 Hotspot 和 JRockit 虚拟机融合。JRockit 客户不需要配置永久代（因为JRockit 没有永久代），习惯不配置永久代。
2. 增加元空间解决类加载所需要的内存空间，而且元空间默认是自动拓容的。这样减少内存溢出的可能。

堆空间移除永久代过后，堆空间的结构如下图所示：

运行时数据区结构如下图所示：

G1 收集器

G1将新生代，老年代的物理空间划分取消了。取而代之的是，G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有cms内存碎片问题的存在了。

在G1中，还有一种特殊的区域，叫Humongous区域。 如果一个对象占用的空间超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在年老代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

对象内存分配

对象内存分配过程如下：[图片上传失败…(image-12eb2e-1628923695102)]

下面是具体的几种内存分配规则

对象优先分配在 Eden 区

大多数情况下，对象在新生代 Eden 区中分配。当Eden区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。 HotSpot虚拟机提供了-XX:+PrintGCDetails 这个收集器日志参数，告诉虚拟机在发生垃圾收集行为时打印内存回收日志，并且在进程退出的时候输出当前的内存各区域分配情况。

测试代码：

/**
 * -XX:+PrintGCDetails
 */
public class GCTest {

    public static void main(String[] args) {
        byte[] allcation2 = new byte[8000 * 1024];
    }
}

输出结果

Heap
 PSYoungGen      total 38400K, used 11353K [0x0000000795580000, 0x0000000798000000, 0x00000007c0000000)
  eden space 33280K, 34% used [0x0000000795580000,0x00000007960966f8,0x0000000797600000)
  from space 5120K, 0% used [0x0000000797b00000,0x0000000797b00000,0x0000000798000000)
  to   space 5120K, 0% used [0x0000000797600000,0x0000000797600000,0x0000000797b00000)
 ParOldGen       total 87552K, used 0K [0x0000000740000000, 0x0000000745580000, 0x0000000795580000)
  object space 87552K, 0% used [0x0000000740000000,0x0000000740000000,0x0000000745580000)
 Metaspace       used 3017K, capacity 4556K, committed 4864K, reserved 1056768K
  class space    used 319K, capacity 392K, committed 512K, reserved 1048576K

我们可以通过内存空间的分布可以看出 allcation2 是被分配到 eden 区中的。

大对象直接进入老年代

大对象就是指需要大量连续内存空间的Java对象（比如：字符串、数组），JVM 参数 -XX:PretenureSizeThreshold 参数可以设置大对象的大小，指定大于该设置值的对象直接在老年代分配，不会进入年轻代，这个参数只有在 Serial 和 ParNew 两个收集器下有效。

比如设置：JVM 参数：

-XX:PretenureSizeThreshold=1000000（单位字节）

-XX:+UseSerialGC

在执行上面的第一个程序就会发现大对象直接进入了老年代。
这样做的目的就是避免在Eden区及两个Survivor区之间来回复制，产生大量的内存复制操作。

长期存活的对象将进入老年代

HotSpot虚拟机中多数收集器都采用了分代收集来管理堆内存，那内存回收时就必须能决策哪些存活对象应当放在新生代，哪些存活对象放在老年代中。为做到这点，虚拟机给每个对象定义了一个对象年龄（Age）计数器，存储在对象头中。

对象通常在Eden区里诞生，如果经过第一次 Minor GC 后仍然存活，并且能被 Survivor 容纳的话，该对象会被移动到 Survivor 空间中，并且将其对象年龄设为1岁。对象在Survivor区中每熬过一次Minor GC，年龄就增加1岁，当它的年龄增加到一定程度（默认为15），就会被晋升到老年代中。对象晋升老年代的年龄阈值，可以通过参数 -XX:MaxTenuringThreshold 设置。

动态对象年龄判断

为了能更好地适应不同程序的内存状况，HotSpot 虚拟机并不是永远要求对象的年龄必须达到 -XX:MaxTenuringThreshold 才能晋升老年代，如果在 Survivor 空间中相同年龄所有对象大小的总和大于 Survivor 空间的一半，年龄大于或等于该年龄的对象就可以直接进入老年代，无须等到 -XX:MaxTenuringThreshold 中要求的年龄。

空间分配担保

在发生 Minor GC 之前，虚拟机必须先检查老年代最大可用的连续空间是否大于新生代所有对象总空间。