【JVM】运行时数据区的堆内存详解（含内存结构,分代思想,堆内存垃圾收集）-优快云博客

本文链接：https://blog.youkuaiyun.com/qq_40742223/article/details/109828899

前文推荐
JVM运行时方法区介绍,以及栈结构详解
温馨提示:本文篇幅较长,但是看完希望你能有收获

JVM部分的概念真的还不少,但是可能看完之后会对java的日常撸代码会有不一样的体会。

堆

堆空间时JVM内存中运行时数据区中非常重要的内存空间,也是最大的内存空间(现在的方法区的空间时使用物理内存,也很大,不参与比较)。

先看看堆内存在JVM中的位置。

1.堆的核心概述(重要)

堆是线程共享，进程唯一的。
- 怎么理解这个进程唯一？在程序运行时，就可以创建一个JVM的实例，而在JVM实例中又会创建一个唯一的堆内存。因此在进程中堆也是唯一的。但是一个进程中可能包含着多个线程，堆内存是线程间共享的。
一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域。
Java堆区在JVM启动的时候创建，其空间大小也就确定了。是JVM管理的最大一块内存空间。
- 堆内存的大小是可以调节的。（后期是可以通过参数来设置分配堆内存的大小）
《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但是逻辑上它应该被视为连续的。
- 堆内存是JVM中比较大的一块内存区域，在逻辑上连续的好处是，如果有比较大的对象，那我们直接分配一块比较大的内存地址就可以了，但是物理内存往往是不连续的，因为但是这也是可以实现的，因为我们即使分配的物理内存是不连续的，我们仍然可以使用地址映射（地址映射表）的方式组成一块较大的内存实现对于大的对象的内存分配。
所有的线程共享Java堆，在这里还可以划分线程私有的缓存区（Threa Local Allpcation Buffer ，TLAB）
- 避免了堆中的数据都是线程共享的而导致线程同步的问题，而在TLAB空间内为每个线程都分配一些空间，是线程私有的。
Java虚拟机规范中Java堆的描述：所有的对象实例都应该在堆上分配空间。
- 实际上，是几乎所有的对象，还是有部分的对象并不是在堆上分配对象的。（在JVM的更新迭代中，为了性能的提升，引入了逃逸分析，也就是说如果在栈方法中的对象是否发生了逃逸，如果没有发生逃逸的话，那么就可以在栈中分配对象）。
数组和对象可能永远不会存储在栈上，因为栈上保存引用，指向堆中对象或者数组的位置。
在方法结束后，堆中的对象不会马上移除，仅仅在垃圾收集的时候才会被移除。
- 也就是说，方法执行之后，可能堆中的对象和数组已经没有任何人引用它，但是它并不会立即被移除，而是等待垃圾回收线程进行回收。这里要和栈中的数据进行区分。栈不考虑垃圾回收，也正是因为出栈之后，就自动的回收。
- 不会立即执行垃圾回收是为了性能考虑，不希望经常的进行垃圾回收，因为在垃圾回收时是可能发生 stop the world。那么原本的线程（用户线程）就停滞，等待垃圾回收机制进行完毕。这里也提到了GC和用户线程是否能并发执行的问题。
堆，是GC（Garbage Collection垃圾收集器）执行垃圾回收的终点。

查看进程的内存大小

使用ava自带的监控工具jvisualVM可以监控堆内存的使用情况

堆的细分内存结构（重要）

现代垃圾收集器大部分都是基于分代收集理论设计的，堆空间细分：

Java7及之前堆内存逻辑上分为三部分：新生区+老年区+永久区

Java8及之后堆内存逻辑上分为三部分：新生代+老生代+元空间

约定：新生区= 新生代=年轻代

约定：养老区=老年区=老年代

约定：永久区=元空间

逻辑上包括三部分:但是事实上我们现在讲的堆的内存只包含新生代和老生代的内存,而元空间(永久代)的内存在方法区中，并不受到堆的管理。

2.设置堆内存大小与OOM

Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就设定好了，如果设置的不合适，那么就容易造成OOM问题。可以通过"-Xmx"和 "-Xms"来设置。

"-Xms"用于表示堆区的起始内存，等价于-XX：InitialHeapSize
"-Xmx"用于表示堆区的最大内存,等价于-XX:MaxHeapSize

一旦堆区的内存大小超过"-Xmx"所指定的最大内存时,就会抛出OutOfMemoryError异常。

如何来记忆这些指令呢？

-x: 是jvm的运行参数

ms:memory start

比如-Xms256M, -Xms14420,-Xms2G都是可以的

这里所说的指令来设置对空间的大小,设置的其实就是新生代+老生代所占内存的大小。

通常情况下将-Xms和-Xmx设置为相同的值,其目的是为了能够在java垃圾回收机制清理玩堆区后不需要重新分隔计算堆区的大小,从而提高性能。频繁的扩容和释放堆空间会消耗一定的系统性能。
默认情况下,初始化内存大小:物理电脑内存大小/64
默认情况下,最大内存大小:物理电脑内存大小/4
使用jps命令可以查看当前程序中运行的进程
jstat：来显示JVM在GC时候的统计信息和进程的使用情况
- jstat -gc 9928:9928代表的是通过jps命令得到的运行进程的id。

如果我们设置的堆的初始内存和最大内存都是600M的话，实际上我们的堆真正能使用的内存不能达到600M。

原因：

堆中的内存内存又可以分为eden区+From区+To区，其中From区和To区中最多只有一个区域是有对象的。

OOM的举例

package Solutions;

import java.util.ArrayList;
import java.util.Random;

/**
 * @author 雷雨
 * @date 2020/11/19 15:30
 */
public class OOMTest {

    public static void main(String[] args) {


        ArrayList<People>  arrayList = new ArrayList<>();
        while (true){
            try {
                Thread.sleep(200);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            arrayList.add(new People(new Random().nextInt(1024*1024)));
        }

    }
}
class People{
    private byte[] families;
    public People(int num){
        this.families = new byte[num];
    }
}

使用 VisualVM监控执行观察,堆内存的变化情况(该图是一个动图,害录得时候时间调的比较慢,可能动图不是很明显)

在这里插入图片描述

3.年轻代与老年代

存储在JVM中的java对象可以被划分为两类:
- 一类是生命周期较短的瞬时对象,这类对象的创建和消亡都非常的迅速
- 另一类对象的生命周期非常长,在某些极端的情况下还能够与JVM的生命周期保持一致。
Java堆区进一步划分的话，可以划分为年轻代（YoungGen）和老年代(OldGen)
其中年轻代又可以划分为Eden空间、Survivor0空间和Suervivor1空间（有时也叫From区和To区）

默认情况下：新生代：老年代 = 1:2

也就是说，堆区的内存，老年代占2/3，新生代占1/3。这个参数在开发中一般是不会修改的，但是JVM提供了修改的命令

-XX:NewRatio代表的是老生代和新生代的比例,默认值是2

可以修改: -XX:NewRatio=1

设置新生代中Eden和Survivor区的比例

在JAVA的JVM文档中注明,默认的比例(Eden:Survivor0:Survivor1)为8:1:1。

但是多次的通过命令行（jps jstat -gc 进程id）得到的比例还是6:1:1,后面查阅了相关资料,发现JVM是有自适应的堆内存分配可能导致的

然后配置了关闭自适应分配,发现问题还是没有解决

-XX:-UseAdaptiveSizePolicy

如果我们希望JVM的新生代的分区空间大小比例为8:1:1,需要显式的去指定。

-XX:SurvivorRatio=8

几乎所有的对象都在Eden区分配的。
- 例外就是:假如分配的对象特别大,在Eden区不能很好的分配,那就会直接在老年代分配
绝大部分的Java对象的销毁都发生在新生代

4.图解对象分配过程

对象分配的一般过程:

new的对象先放在伊甸园区。此区有大小限制。
当伊甸园区的空间填满时，程序又需要创建对象，JVM的阿基回收期将对伊甸园区进行垃圾回收（Minor GC），将伊甸园区中的不再被其他对象引用的对象进行销毁。再加载新的对象放到伊甸园区。
然后将上次垃圾回收存放的对象移动到幸存者0区。
如果再次触发垃圾回收，此时上次幸存下来的放到幸存者0区的，如果没有回收，就会放到幸存者1区。
如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区。
啥时候能去老年区呢？可以设置次数。默认是15次。
- 也就是说每经过一次垃圾回收的对象，如果该对象没有被销毁，那么它的age值就会+1，达到15时，就会将其放到老年代。
- 可以设置参数:-XX:MaxTenuringThreshold=<N>进行设置
那么幸存者0区和幸存者1区如何进行垃圾回收呢?
- 幸存者0区和幸存者1区的对象是跟随这MinorGC一起进行垃圾回收的。
- 并且当这两个区的对象空间满了的时候，也有机制让其提前转为老生代的对象。

总结：

针对幸存者S0，S1区的总结：复制之后有交换，谁空谁是To。

这是说，我们的幸存者0区和幸存者1区这个内存空间还可以叫From区和To区，但是From区和To区所表示的位置是不固定的，会发生交换，也就是发生交换后永远会保证空的是To区（To区，表示下一次GC时要转入对象的区域）。From区表示：下一次GC发生时的要转移对象的原空间。

关于垃圾回收：频繁发生在新生区收集，很少在养老区收集，几乎不再永久区/元空间收集。

特殊的对象分配内存

使用VisualVM监控对象内存分配情况

当我们持续的创建对象并一直持有对象的引用（也就是不让垃圾收集回收它），这样一定是会出现OOM问题的。

观察Eden区的内存是逐渐增长的，对应着我们创建的对象放在了Eden区。
Survivor0 和Survivor1区的内存每次在GC之后交替的变化（空或者有对象）
Old区的内存在发生GC之后就会内存持有的对象增加，因为可能有Eden区转到Survivor区的对象放不下的情况，也可能是age值超过15（上图中并不是age超过15因为我们还没有进行15次Minor GC）
当Old区满时，虚拟机渴望进行Full GC从来销毁Old区中无效的对象，但是发现我们的对象都持有引用，就发生了OOM
上图的OOM发生的地点是在Old区。

5.Minor GC Major GC Full GC

JVM在进行GC时，并非每次都对上面三个内存（新生代、老年代；方法区）区域一起回收的，大部分时候回收的都是指新生代。

针对HotSpot VM的实现，它里面的GC按照回收区域又分为两大类型：一种是部分收集（Partial GC），一种是整堆收集。

部分收集：不是完成收集java堆的垃圾收集。其中又分为：

新生代收集（Minor GC/Young GC）:只是新生代(Eden/S0,S1)的垃圾收集
老年代收集(Major GC/Old GC):只是老年代的收集
- 目前只有CMS GC会有单独收集老年代的行为。
混和收集（Mixed GC）：收集整个新生代和部分老年代的垃圾收集。
- 目前只有G1 GC会有这种收集方式。
整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集。

最简答的分代式GC策略的触发条件

1.年轻代GC（Minor GC）触发条件

当年轻代空间不足时就会触发Minor GC，这里的年轻代满的意思是：Eden区满，Survivor满是不会触发Minor GC的，而是直接将对象存入到老年代。
因为新生代的对象虽然创建的很多，但是很多都是创建出来然后短时间就又销毁掉，因此Minor GC发生的很频繁，一般回收的速度也比较快。
Minor GC会引发STW（Stop the world）,暂停其他线程,等待垃圾回收结束,用户线程才能恢复。
- 为什么发生STW？
  - 因为在GC线程运行的时候，是要判断哪些是垃圾，哪些对象需要被回收，并对对象进行位置的调节，这时候如果有用户线程在操作，那就可能造成并发的问题。

2.老年代GC（Major GC）

指发生在老年代的GC,对象从老年代消失时,我们就说"Minor GC"发生了"Full GC"发生了
出现了Major GC,经常会伴随至少一次的Minor GC(但并非绝对的,在Parallel Scaenge收集器的收集策略中有直接进行Major GC的策略选择过程)。
- 也就是在老年代空间不足时，会先尝试触发Minor GC。如果之后空间还不足则触发Major GC
Major GC的速度一般会比Minor GC慢10倍以上，STW的时间更长。
如果Major GC后，内存还不足，就报OOM
Major GC的速度一把会比Minor GC慢10倍以上。

3.Full GC的触发机制

总的来说，Full GC触发的情况涵盖了整个堆空间，并且包括了方法区。

触发Full GC执行的情况有如下5种:

调用System.gc()时,系统建议执行Full GC,但是不是一定执行。
老年代空间不足时
方法区空间不去
通过Minor GC后进入老年代的平均大小大于老年代的可用内存。
由Eden区和Survivor space0向 Survivor space1区复制时，对象大小大于To Space区的内存，则想要将该部分的对象转存到老年代，但是发现又大于老年代的可用内存。

Full GC是开发和调优中要尽量避免的,这样暂停的时间会短一些。

6.堆空间分代思想

堆空间为什么要采用分代收集的思想？可以不采用分代收集吗？

采用分代收集的思想是因为:经过大量的研究和实验,不同的对象的生命周期是不同的。70-99%都是临时对象，也就是说这些对象在创建之后使用一段时间后，就需要被销毁掉。因此采用分代收集的思想就会很高效率的回收掉需要被销毁的对象。

总的来说，分代就是为了优化GC的性能。不采用分代收集也是可以的，只是GC的效率比较低。

分为Eden，Survivor区和Old区。

7.内存分配策略（对象提升规则）

策略：

如果对象在Eden区出生经过一个Minor GC后背存在Survior区，这时设置该对象的初始年龄为1。之后该对象没进行一次Minor GC只要还存活，那么它的年龄就+1，当它的年龄增长到一定程度（默认为15），那么就可以将其转移到老年代。

对象晋升老年代的年龄阈值可以通过-XX:MaxTenuringThreshold来设置。

针对不同年龄段的对象分配原则如下：

优先分配到Eden区
大对象可以直接分配到老年代
- 避免程序中出现大量的大对象
长期存活的对象分配到老年代
动态对象年龄判断
- 如果Survivor中相同年龄的对象大小的总和大于Survivor空间的一半，那么可以直接将年龄大于或者等于该年龄的对象进入老年代，而不需要等待到最大年龄。
空间分配担保
- -XX:HandlePromotionFailure

给自己的提示:在开发中一定要避免创建大量的大对象,因为大对象可能伴随着频繁的GC,再者如果大对象是朝生夕死的,那就会更加频繁的GC!!

大对象直接进入到老年代

package Solutions;

/**
 * @author 雷雨
 * @date 2020/11/19 21:38
 *
 * 参数设置为
 * -Xms60m      初始化堆空间60M
 * -Xmx60m      最大堆空间60M
 * -XX:NewRatio=2      老生代:新生代= 2:1
 * -XX:SurvivorRatio=8    Eden:Survivor space0: Survivor space1:=8:1:1
 * -XX:+PrintGCDetails   打印GC日志
 */
public class YoungOldAreaTest {
    public static void main(String[] args) {
        byte [] bytes = new byte[1024*1024*2];//初始化一个20m的数组
    }
}

看下结果的截图

8.为对象分配内存:TLAB

为什么是TLAB(Thread Local Allocation Buffer)?

堆区是线程共享区域,任何线程都可以访问到堆区中共享的数据(有利于进程之间的通信)
由于对象实例的创建都在JVM中非常频繁,那么在并发环境下从堆区操作对象可能是不安全的
为了避免多个线程操作同一地址的话，就考虑加锁的机制，但是加锁就会影响效率。

什么是TLAB?

从内存模型而不是垃圾回收角度考虑，对Eden区域继续进行划分，JVM为每个线程分配了一个线程私有缓冲区域,它包含在Eden区域内
多线程同时分配内存时,使用TLAB可以避免一系列的非线程安全的问题,同时还能够提升内存分配的吞吐量,因此将这种分配方式称为快速分配策略
已知的OpenJDK都是默认开启TLAB的

代码测试TLAB是否默认开启

package Solutions;

/**
 * @author 雷雨
 * @date 2020/11/19 22:13
 */
public class TLABTest {
    public static void main(String[] args) {
        System.out.println("快去打开控制台看看TLAB是不是默认开启的");
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}