【JVM】8、堆

1、堆的核心概述

• 一个JVM实例只存在一个堆内存，并且 Java的堆区在JVM启动时（即程序开始运行）大小就确定了。如果想要调整堆区大小，可以在运行前设置其参数

如在配置文件中这么设置：

• 堆可以在物理上不连续的内存空间中，但是逻辑上应该视为连续的
• 所有的线程共享堆空间，在这里还可以划分线程私有的缓冲区（Thread Local Allocation Buffer,TLAB）
• 在方法结束后，分配在堆中的对象不会马上被移除，仅仅在垃圾收集的时候才会被移除
• 堆是垃圾收集器回收的重点区域

Java栈、堆和方法区的联系：

类的结构和方法等相关信息存储在方法区中

堆内存细分（重要）

由于现在主流版本是 jdk8 及之后的版本，因此应该更多的关注新生区+老年区+元空间 这样的结构

2、设置堆内存大小与OOM

• Java堆区用于存储Java对象实例，那么堆的大小在JVM启动时就已经设定好了，可以通过如下参数进行设置：

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

• 一旦堆区的内存大小超过 -Xmx 所设置的值，那么就是抛出 OutOfMemoryError 异常

• 通常会将 -Xms 和 -Xmx 两个参数配置相同的值，原因是为了能够在进行垃圾回收后无需重新计算堆区的大小，从而提高性能

• 默认情况下：

  • 初始内存大小：物理电脑内存大小/64
  • 最大内存大小：物理内存大小/4

示例代码（电脑内存为 8G ）：

public static void main(String[] args) {
    //返回虚拟机中堆内存的总量
    long initialMemory = Runtime.getRuntime().totalMemory() / 1024 / 1024;
    //返回虚拟机可使用的最大容量
    long maxMemory = Runtime.getRuntime().maxMemory() / 1024 / 1024;

    System.out.println("-Xms: " + initialMemory + "M");
    System.out.println("-Xmx: " + maxMemory + "M");

    System.out.println("系统内存大小为:" + initialMemory * 64.0 / 1024 + "G");
    System.out.println("系统内存大小为:" + maxMemory * 4.0 / 1024 + "G");
}

输出结果：

-Xms: 121M
-Xmx: 1790M
系统内存大小为:7.5625G
系统内存大小为:6.9921875G

可以通过如下两种方式查看GC情况：
第一种：在配置中设置如下

-Xms 600m -Xmx 600m -XX:+PrintGCDetails

输出结果：

第二种：在命令行

1. 输入 jps 查看当前运行的进程
   得到对应的进程号xxx

2. 再输入jstat -gc xxx得到结果如下：

在可用内存中，由于垃圾收集算法采用的是标志复制算法，因此Survivor 区会有一半的空的，不作为使用。即上述图中的S1C和S0C只会使用一个区域。因此可用内存组成为:
S0C + EC +OC 或者S1C + EC +OC

3、年轻代和老年代

概述

• 存储在JVM中的Java对象根据生命周期可以分为两大类：

  1. 一类是生命周期较短的对象，这类对象的创建和消亡都比较快
  2. 另一类是生命周期较长的对象，甚至和JVM的生命周期一样长

• Java堆区进一步细分可分为：年轻代和老年代

• 年轻代又可分为 Eden 空间、Survivor0 空间和Survivor1 空间（也叫 from 区和 to 区）

新生代和老年代堆空间占比：

• 在HotSpot中，Eden空间和另外两个survivor空间缺省所占的比例是8 : 1 : 1
• 开发人员可以通过选项-XX:SurvivorRatio调整这个空间比例。比如-XX:SurvivorRatio=8
• 几乎所有的Java对象都是在Eden区被new出来的。
• 绝大部分的Java对象的销毁都在新生代进行了（有些大的对象在Eden区无法存储时候，将直接进入老年代）
  IBM公司的专门研究表明，新生代中80%的对象都是“朝生夕死”的。
• 可以使用选项-Xmn设置新生代最大内存大小，但这个参数一般使用默认值就可以了。
• 新生区的对象默认生命周期超过 15 ，将进入老年代

在命令行查看新生代与老年代的比例

jps
jinfo -flag NewRatios 进程id 

在命令行查看新生区中 Eden 区与 Survivor 区的比例

jps
jinfo -flag SurvivorRatio 进程id 

4、图解对象分配过程

对象的分配过程概述：

• new的对象先放 Eden 区。此区有大小限制。
• 当 Eden 区的空间填满时，程序又需要创建对象，JVM的垃圾回收器将对 Eden 区进行垃圾回收（MinorGC），将 Eden 区中的不再被其他对象所引用的对象进行销毁。然后又可以在 Eden 区中创建新的对象了
• 将 Eden 区中存活的对象移动到 S0 区
• 如果再次触发 MinorGC ，此时 S0 中如果有存活的对象，会移动到 S1 区。下一次再触发 MinorGC 时，就是将 S1 区中存活的对象，移动到 S0 区，反复在两者间移动
• 如何判断对象可以移动到养老区呢？可以设置次数，默认为 15 次
  设置方式：-XX:MaxTenuringThreshold=<N>

• 我们创建的对象，一般都是存放在Eden区的，当我们的Eden区满了后，就会触发GC操作，一般被称为 YGC / Minor GC操作

注意： 只有Eden区满了才会触发 GC 操作，幸存者区 S0 和 S1 满了都不会触发 GC 操作，但是Eden区满了以后触发 GC 操作时，也会扫描S0/S1，看里面是否有垃圾对象需要进行回收

当我们进行一次垃圾收集后，垃圾对象（标为红色的）将会被回收，而存活的对象（标为绿色的）仍有引用在使用，因此从Eden区移到S0区。同时给每个对象设置了一个年龄计数器，经过一次垃圾回收后还存在的对象，将其年龄加 1。

• 同时Eden区继续存放对象，当Eden区再次存满的时候，又会触发一个MinorGC操作，此时GC将会把 Eden 和 S0 中的对象进行一次垃圾收集，把存活的对象放到 S1 区，同时让存活的对象年龄 + 1

注意：S0 和 S1在进行垃圾回收后，必然有一个是空的，因为这里的垃圾收集算法采用的是 “标记复制算法”，因此需要保证其中一个区域是空的，哪个区域是空的，就将哪个作为 to 区域，另一个作为 from 区域

• 继续进行对象的创建和垃圾回收，当 Survivor 中的对象的年龄达到 15 的时候，将会触发一次晋升的操作，也就是将年轻代中的对象晋升到老年代中。也会有其它特殊情况，例如新生区都满了，那么就算某个对象的 “年龄” 未达到15，也可以提前 “晋升” 到老年代

总结：

• 针对 S0 和S1 区，复制之后进行交换，谁空谁就是 to
• 关于垃圾回收：频繁在新生区收集，很少在老年区收集，几乎不在永久区/元空间收集

对象分配的特殊情况

图解析如下：

（1）新对象申请，Eden 放得下？

• 放得下，直接分配对象内存，存放在 Eden 区
• 放不下，进行 YGC 进行垃圾收集，如果进行了 YGC 发现还放不下，则将查看老年区。
  • 看老年区是否放得下？
    • 如果老年区放得下，则直接在老年区为其分配内存；
    • 如果老年区也放不下，先进行一次 FGC ，如果还是放不下，则抛出 OutOfMemoryError 异常

（2）进行 YGC 时，会将 Eden 区存活的对象先放到 Survivor 区，要是 Survivor 区放不下了，那么就只能将其中一些对象直接 “晋升” ，放置到老年区

代码演示：

/**
 * -Xms600m -Xmx600m
 */
public class HeapInstanceTest {
    byte[] buffer = new byte[new Random().nextInt(1024 * 200)];

    public static void main(String[] args) {
        ArrayList<HeapInstanceTest> list = new ArrayList<HeapInstanceTest>();
        while (true) {
            list.add(new HeapInstanceTest());
            try {
                Thread.sleep(10);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }
}

Eden 区满了往 S0/S1放。S0/S1满了往Old区放，同时S0 和 S1 在一次GC后必须得有一个为空，Old区满了无法再分配新对象了则抛出 OOM 异常

5、Minor GC、Major GC、Full GC

JVM 在进行 GC时，并非每次都对新生代、老年代和方法区三个区域一起进行回收，大部分情况下都是对新生代进行回收

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

(1) 部分收集：不是完整地收集整个Java堆的垃圾收集。其中分为：

• 新生代收集（Minor GC/Young GC）：只是新生代（Eden,S0,S1）的收集

• 老年代收集（Major GC/Old GC）：只是老年代的垃圾收集
  目前只有CMS GC会单独收集老年代

• 混合收集(Mixed GC)：收集整个新生代以及部分老年代
  目前只有G1 GC这么做

（2）整堆收集（Full GC）：收集整个Java堆和方法区

注意不要混淆Major GC 和Full GC，分清是部分收集还是整堆收集

GC策略的触发条件

• 年轻代GC（Minor GC）触发机制：

1. 当 Eden 区满了，就会触发Minor GC,Survivor 区满了不会触发 Minor GC。触发GC后将清理整个年轻代区

2. Minor GC比较频繁，因为Java对象大多具有朝生夕死的特性

3. Minor GC 会触发Stop The World，即暂停其他用户的线程，等垃圾回收结束，用户线程才恢复运行

• 老年代GC触发机制

1. Major GC 和 Full GC 都会对老年代进行垃圾回收

2. 出现了Major GC通常会伴随至少一次Minor GC（非绝对的）
   也就是说，在老年代空间不足时，会先尝试触发Minor GC，如果仍旧空间不足，则触发Major GC。如果Major GC后内存仍旧不足，则OOM

3. 老年代区域比较大，因此 Major GC 的速度比 Minor GC 慢10倍以上，Stop The World的时间会更长

• Full GC 触发机制

1. 调用System.gc()时，系统建议执行Full GC，但不是必然执行

2. 老年代空间不足和方法区空间不足都会触发 Full GC

3. 由Eden区、survivor space0（From Space）区 向survivor space1（To Space）区复制时，如果对象大小 大于 To Space可用内存，则把该对象转存到老年代，且老年代的可用内存 小于 该对象大小

6、堆空间分代思想

为什么需要将 Java 堆分代？不分代就不能正常工作了吗？

首先，分代其实是根据对象的生命周期进行区分，而在开发过程中，绝大部分对象都是临时对象，因此应该将其放在新生代中

• 新生代：有Eden、两块大小相同的 Survivor（又称from/to，S0/S1）构成，to 总为空
• 老年代：新生代中经历多次GC仍然存活的对象

之所以需要将堆空间进行分代，是为了优化 GC 性能。
如果不进行分代，那么在 GC 时，将对所有的对象进行扫描，然后清理。然而实际上老年代的对象生命周期很长，很少需要被清理。因此我们应该将 GC 的重心对准那些 “朝生夕死” 的对象，也就是所谓的新生代。
如此一来，将堆空间进行分代，就减少了对老年区对象的扫描操作，从而提高了 GC 性能

JDK 7 中的永久代（Permanent）在 JDK 8中变成了元空间（Meta space）

7、内存分配策略(重要)

当对象在 Eden 区创建并经过第一次 Minor GC 后仍然存活，并且能够被 Survivor 容纳的话，将移动到 Survivor 空间中，并将对象年龄设置为 1。存活的对象每熬过一次 Minor GC，则年龄加 1，当年龄到达一定的阈值（默认15，每个JVM、GC都不同），就会晋升到老年代

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

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

• 优先分配到 Eden 区，长期存活的对象将放到老年代

• 大对象直接分配到老年代（应避免程序出现过多的大对象，特别是“朝生夕死”的大对象）

• 动态对象年龄判断
  如果 Survivor 区中相同年龄的所有对象大小总和大于Survivor空间的一半，那么大于或等于该年龄的对象可以直接进入到老年代，无需等达到MaxTenuringThreshold阈值

• 空间分配担保
  -XX:HandlePromotionFailure

大对象直接分配到老年代演示：

/*
测试：大对象直接进入老年代
参数设置： -Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails
那么Eden:16M S0:2M S1:2M Old:40M
 */
public class HugeObjectTest {
    public static void main(String[] args) {
        byte[] arr = new byte[1024 * 1024 * 20];  //直接分配 20M 的对象
    }
}

参数设置为：

-Xms60m -Xmx60m -XX:NewRatio=2 -XX:SurvivorRatio=8 -XX:+PrintGCDetails

因此 60M 大小的堆空间中各自的占比为：

Eden: 16M 
S0: 2M 
S1: 2M 
Old:40M

输出结果如下：

可以看到，这个大对象是直接分配到了老年区，而且新生代没有经历过GC，因为没有GC日志输出

8、为对象分配内存：TLAB(Thread Local Allocation Buffer)

为什么有TLAB？

• 堆区是线程共享的，任何线程都可以访问堆区中的共享数据
• 由于对象实例的创建在JVM中十分频繁，因此在并发环境下从堆区中划分内存空间是线程不安全的
• 为了避免多个线程同时操作同一地址，需要采用加锁等机制，这影响了分配速度

什么是TLAB?

• 从内存模型的角度，TLAB 是对 Eden 区域进一步划分，JVM 为每一个线程分配了一个私有的缓存区域，它被包含在 Eden 区
• 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还可以提升内存分配的吞吐量，因此将这种内存分配方式称为快速分配策略
• 目前来看，所有OpenJDK衍生出来的JVM都提供了TLAB的设计

TLAB的再说明

• 不是所有的对象实例都能在TLAB中成功分配内存，但JVM确实将TLAB作为内存分配的首选
• 可以通过-XX:UseTLAB设置是否开启TLAB空间（默认是开启的）
• 默认情况下，TLAB的空间很小，仅占整个Eden空间的1%，可以通过-XX:TLABWasteTargetPercent 来设置TLAB占用Eden区的百分比
• 当对象在TLAB空间分配内存失败，JVM就会尝试通过加锁机制确保数据操作的原子性，从而直接在Eden空间中分配内存

对象分配内存图示：

分配对象内存时先看TLAB是否足够，如果不够，则将Eden区中非TLAB的区域的内存进行分配，如果还是不足，那么进行一次Minor GC，如果可以，那么直接分配对象内存；如果还是不足，则需要考虑分配到老年区，或者进行Major GC ，甚至产生 OOM

9、小结堆空间的参数设置

-XX:+PrintFlagsInitial：查看所有的参数的默认初始值
-XX:+PrintFlagsFinal：查看所有的参数的最终值（可能会存在修改，不再是初始值）
-Xms：初始堆空间内存（默认为物理内存的1/64）
-Xmx：最大堆空间内存（默认为物理内存的1/4）
-Xmn：设置新生代的大小（初始值及最大值）
-XX:NewRatio：配置新生代与老年代在堆结构的占比
-XX:SurvivorRatio：设置新生代中Eden和S0/S1空间的比例
-XX:MaxTenuringThreshold：设置新生代垃圾的最大年龄
-XX:+PrintGCDetails：输出详细的GC处理日志
-XX:+PrintGC 或 -verbose:gc ：打印 GC 简要信息
-XX:HandlePromotionFailure：是否设置空间分配担保

解释：-XX:HandlePromotionFailure：是否设置空间分配担保

在发生Minor GC之前，JVM会检查老年代最大可用连续空间是否大于新生代所有对象的总空间

• 如果大于，则此次Minor GC是安全的
• 如果小于，则JVM会查看 -XX:HandlePromotionFailure 设置值是否允许担保失败

  • 如果 -XX:HandlePromotionFailure=true ,那么会继续检查老年代最大可用连续空间是否大于历次晋升到老年代对象的平均大小

    • 如果大于，则尝试进行一次Minor GC，但这次Minor GC依然是有风险的
    • 如果小于，则改为进行一次Full GC

  • 如果 -XX:HandlePromotionFailure=false ，则改为进行一次Full GC

注意：JDK 7及以后的版本中HandlePromotionFailure 参数不再影响空间分配担保，即一直都是-XX:HandlePromotionFailure=true，因此当老年代最大可用连续空间是否大于新生代所有对象的总空间 或者 大于历次晋升到老年代对象的平均大小 就进行Minor GC，否则进行Full GC

扩展：如果Eden 和 Survivor区分配不合理会发生什么？

• 如果Eden区过大
  那么Survivor区就很小，当进行Minor GC时，存活的对象将放到Survivor区中。然后由于Survivor区内存空间较小，因此存活的对象大部分都直接存放到了Old区。这样就导致Minor GC失去意义了，因为我们本意是想不断在新生区进行Minor GC，但是大部分的对象都过早的进入到了老年区，这就使得Minor GC意义不大了

• 如果Survivor区过大
  那么Eden区的内存空间就会比较小，我们知道，每当Eden区满了，就会触发Minor GC，假如Survivor区过大导致Eden 区过小，那么Eden区很快就会满了而去触发Minor GC，而Minor GC会产生Stop The World，因此频繁的触发Minor GC 不是件好事

10、堆是分配对象的唯一选择吗

在《深入理解Java虚拟机》中关于Java堆内存有这样一段描述：

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

在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍的常识。但是，有一种特殊情况，那就是如果经过逃逸分析（Escape Analysis）后发现，一个对象并没有逃逸出方法的话，那么就可能被优化成栈上分配。这样就无需在堆上分配内存，也无须进行垃圾回收了。这也是最常见的堆外存储技术。

此外，前面提到的基于OpenJDK深度定制的TaoBao VM( 淘宝虚拟机 )，其中创新的GCIH（GC invisible heap）技术实现 off-heap，将生命周期较长的Java对象从heap中移至heap外，并且GC不能管理GCIH内部的Java对象，以此达到降低GC的回收频率和提升GC的回收效率的目的。

那么堆是分配对象的唯一选择吗？
不是。假如对象没有逃逸出方法，那么可能会进行栈上分配

逃逸分析概述

• 如何将堆上的对象分配到栈，需要使用逃逸分析手段

• 通过逃逸分析，Java Hotspot编译器可以分析出一个对象的引用的使用范围从而决定是否要将这个对象分配到堆上

• 逃逸分析的基本行为就是分析对象的动态作用域：

  1. 当对象在方法内定义后，对象只在内部使用，则没有发生逃逸
  2. 当对象在方法内定义后，它还被外部方法所引用，则发生了逃逸

示例1:

public void myMethod(){
    V v = new V();
    //do something...
    v = null;
}

这里的对象只在内部使用，因此没有发生逃逸，因此是栈上分配。随着方法执行结束，栈空间就被移除

示例2：

public StringBuffer createStringBuffer(){
    StringBuffer sb = new StringBuffer();
    return sb;
}

这里创建的对象 sb 由于将其作用域传送出了方法，因此发生了逃逸，因此不能栈上分配，而是将其分配到堆空间

示例3：

public class EscapeAnalysis {
    public EscapeAnalysis obj;

    //获取EscapeAnalysis对象，发生了逃逸
    public EscapeAnalysis getInstance() {
        return obj == null ? new EscapeAnalysis() : obj;
    }

    //设置EscapeAnalysis对象值，发生了逃逸
    public void setObj() {
        this.obj = new EscapeAnalysis();
    }

    //对象 e 的作用域仅在方法中有效，未发生逃逸
    public void useObj() {
        EscapeAnalysis e = new EscapeAnalysis();
    }

    //引用成员变量的值，发生逃逸
    public void useObj2() {
        EscapeAnalysis e = getInstance();
    }
}

public void useObj2() {
    EscapeAnalysis e = getInstance();
}

为什么这里发生了逃逸呢？对象EscapeAnalysis e 在方法结束后不是随着栈帧的弹出而消亡了吗？这里的原因是因为，我们判断是否发生逃逸，看的是new 出来的对象实体是否在方法外被调用。而这里调用getInstance()得到的对象实体，在方法外有被调用，因此发生了逃逸

结论：

1. 是否发生逃逸，就看new 的对象实体是否有可能在方法外被调用，而不是看变量
2. 开发中能使用局部变量，就不要在方法外定义

逃逸分析代码优化

使用逃逸分析，编译器可以对代码做如下优化：

• 栈上分配：将堆分配转化为栈分配。如果一个对象在子程序中被分配，要使指向该对象的指针永远不会发生逃逸，对象可能是栈上分配的候选，而不是堆上分配

• 同步省略：如果一个对象被发现只有一个线程被访问到，那么对于这个对象的操作可以不考虑同步。

• 分离对象或标量替换：有的对象可能不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在内存，而是存储在CPU寄存器中。

文章部分图片参考：https://blog.csdn.net/sj15814963053/article/details/110246331