第八篇_堆

概述

• 每个进程拥有一个JVM实例
• 一个JVM实例只存在一个堆内存，堆也是Java内存管理的核心区域
• Java堆区在JVM启动时被创建。其空间大小被确定，JVM管理的最大一块内存空间，堆内存大小可调节
• 《Java虚拟机规范》规定，堆可以处于物理上不连续的内存空间中，但是在逻辑上他应该是连续的
• 所有线程共享Java堆，这里还可以划分线程私有缓冲区（Thread Local Allocation Buffer，TLAB）
• 《Java虚拟机规范》中对Java堆描述是：所有的对象实例以及数组都对应在运行时分配在堆上
  • 几乎所有的对象实例都在这里进行分配内存
• 数组和对象可能永远不会存储在栈上，因为栈帧中保存引用，这个引用指向对象或者数组在堆中的位置
• 在方法结束后，堆中的对象不会马上被移除，仅仅在垃圾收集时才会被移除
• 堆是GC（Garbage Collection 垃圾收集器）执行垃圾回收的重点区域
• 测试代码 - jdk自带的工具查看堆内存分析 在jdk的安装目录bin下的jvisualvm.exe工具

public class SimpleHeap {
    private int id;

    public SimpleHeap(int id) {
        this.id = id;
    }

    public void show() {
        System.out.println("my id is:" + id);
    }

    public static void main(String[] args) {
        SimpleHeap s1 = new SimpleHeap(1);
        SimpleHeap s2 = new SimpleHeap(2);
        int[] arr = new int[10];
        Object[] arr1 = new Object[10];
    }
}

堆内存细分

现代的垃圾收集器大部分基于分代收集理论设计

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

• Young Generation Space 新生区 Young/New
  • 又被划分为Eden区和Survivor区
• Tenure Generation Space 养老区 Old/Tenure
• Permanent Space 永久区 Perm

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

• Young Generation Space 新生区 Young/New
  • 又被划分为Eden区和Survivor区
• Tenure Generation Space 养老区 Old/Tenure
• Meta Space 元空间 Meta

堆空间大小设置

Java堆用来存储Java对象实例，堆的大小在JVM启动时就已经设定好了，可以通过选项设置"-Xmx"和"-Xms"来进行设置（设置的是年轻代+年老代大小）

• -Xms：表示堆区的起始内存大小，等价于 -XX:InitialHeapSize
• -Xms：表示堆区的最大内存，等价于-XX:MaxHeapSize
• 说明：-X是JVM运行参数，ms是Memory Start的缩写

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

通过将 -Xms和 - Xmx两个参数设置为相同值，可将垃圾回收机制清理完堆区之后不需要重新分隔计算堆区的大小，从而提升性能

默认情况下：

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

public class HeapSizeDemo {
    public static void main(String[] args) {
        long initialMemory = Runtime.getRuntime().totalMemory();
        long maxMemory = Runtime.getRuntime().maxMemory();

        System.out.println("-Xms:" + (initialMemory / 1024 / 1024) + " M");
        System.out.println("-Xms:" + (maxMemory / 1024 / 1024) + " M");
        System.out.println("系统内存大小：" + (initialMemory * 64 / 1024 / 1024 / 1024) + " G");
        System.out.println("系统内存大小：" + (maxMemory * 4 / 1024 / 1024 / 1024) + " G");

    }
}

/**执行结果
-Xms:366 M
-Xms:5428 M
系统内存大小：22 G
系统内存大小：21 G
 */

在代码中会发现计算的结果不一致，因为s0 和 s1区在进行计算时，只使用了一个

查询参数

• jps / jstat -gc 进程id
• -XX: +PrintGCDetails

OutOfMemoryError举例

/**
 * VM args: -Xms20m -Xmx20m
 * Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
 */
public class HeapOomCase {
    static class OomObject {

    }

    public static void main(String[] args) {
        ArrayList<OomObject> list = new ArrayList<>();
        while (true) {
            list.add(new OomObject());
        }
    }
}

年轻代和老年代

存储在JVM中的Java对象可以被划分为两类

• 一类是生命周期短的瞬时对象，这类对象的创建和消亡都非常迅速
• 另外一类对象的生命周期非常长，在某些极端的情况下还能与JVM的生命周期保持一致

Java堆区进一步可细分为：年轻代（YoungGen）、老年代（OldGen）

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

下面的参数在开发中一般不会调整

• Young：Old = 1:2
• Eden：s0：s1 = 8:1:1

配置新生代与老年代在堆结构的占比

• 默认 -XX：NewRatio = 2 表示新生代占1/3，老年代占2/3
• 可修改 -XX:NewRatio=4 表示新生代1/5，老年代4/5

在Hotspot中，Eden空间和另外两个Survivor空间缺省比为：8:1:1

当然开发人员可以通过选项"XX:SurvivorRatio"调整这个比例，如 -XX:SurvivorRatio=8

• 但是默认情况下，我们看到的并不是 8:1:1 而是 6:1:1 如果像看到，就可以设置 VM参数 -XX:SurvivorRatio=8

几乎所有的Java对象都是在Eden区被new出来的

绝大部分的Java对象的销毁都在新生代进行

• IBM公司的专门研究表明：新生代 80%的对象都是朝生夕死

可使用 -Xmn设置新生代的最大内存大小（该参数一般使用默认值）

图解对象的分配过程

为新对象分配内存是一件非常严谨和复杂的任务，JVM的设计者们不仅仅需要考虑内存如何分配，在哪里分配等问题，并且由于内存分配算法与内存回收算法密切相关，所以还需要考虑GC执行完内存回收之后是否会在内存空间中产生内存碎片

• new的对象先放在伊甸园区，此区没有大小限制
• 当伊甸园填满时，程序又需要创建新对象，JVM的垃圾回收期将对伊甸园进行垃圾回收（Minor GC），将伊甸园区中的不再被其他对象所引用的对象进行销毁，在机载新的对象放在伊甸园区
• 将伊甸园区的幸存对象移动到幸存者0区
• 如果再次触发垃圾回收，此时上次幸存下来的放到幸存者01区域，如果没有回收，就放到幸存者1区
• 如果再次经历垃圾回收，此时会重新放回幸存者0区，接着再去幸存者1区
  • 注意：只有Eden区满了之后才会触发YGC，而幸存者区满了不会触发YGC，但是会将Eden区和幸存者区一起回收
• 当一个对象经历了15次 Minor GC之后，就会放到养老区
  • 可设置参数：-XX:MaxTenuringThreshold=进行设置
• 在养老区，当养老区内存不足时，再次出发GC：Major GC 进行养老区的内存清理
• 如果养老区执行了Major GC之后依旧无法进行对象保存，就会产生OOM异常

总结

• 针对幸存者s0、s1区的总结：复制之后有交换，谁空谁是to
• 关于垃圾回收：频繁在新生区收集，很少在养老区收集，几乎不再永久区/元空间收集

监控案例

/**
 * VM args: -Xms20m -Xmx20m
 */
public class HeapOomCase {
    static class OomObject {

    }

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

常用的调优工具

• JDK命令行
• Eclipse：Memory Analyzer Tool
• Jconsole
• VisualVM
• Jprofiler
• Java Flight Recorder
• GC Viewer
• GC Easy

Minor GC、Major GC和Full GC

JVM在进行GC时，并非每次都对上面三个内存区域一起回收，大部分的时候回收都都是新生代

针对Hotspot VM的实现，它里面的GC按照回收区域又分为2种类型：部分收集（Partial GC）、整堆收集（Full GC）

部分收集：不是完整的整个Java堆收集

• 新生代收集（Minor GC 完全等价于 YGC）：在新生代的垃圾收集
• 老年代收集（Major GC / Old GC）：在老年代的垃圾收集
  • 目前只有CMS GC会有单独收集老年代的的行为
  • 注意很多时候 Major GC 和 Full GC混淆使用，需要具体判别老年代回收还是整堆回收
• 混合收集（Mixed GC）：收集整个新生代和部分老年代的垃圾收集
  • 目前 只有G1、C会有这种行为
• 整堆收集（Full GC）：收集整个Java堆和方法区的垃圾收集

年轻代GC的触发机制

• 当年轻代里的Eden区满时会触发Minor GC
• Java对象大多都具备朝生夕死的特性，故Minor GC非常频繁、回收速度快
• Minor GC会引发 STW（Stop the World），暂停其他用户线程，等待垃圾回收结束，用户线程才恢复执行

老年代GC的触发机制

• 对象从老年代消失时，通常说是Major GC 或 Full GC发生了

• 出现了Major GC，经常会伴随至少一次的Minor GC（非绝对，在Parallel Scavenge 收集器的收集策略里就有直接进行Major GC的策略选择过程）

  • 在老年代空间不足时，会先尝试触发Minor GC。若空间仍不足，则触发Major GC

• Major GC速度比Minor GC慢十倍，STW的时间或更长

• 如果Major GC之后，内存还不足，就报OOM了

Full GC触发机制

触发Full GC的情况有五种

• 调用System.gc()时，系统建议执行Full GC，但是不是必然执行的
• 老年代空间不足
• 方法区空间不足
• 通过Minor GC后进入老年代的平均大小大于老年代的可用内存
• 由Eden区、Survivor space0（From Space）区向Survivor space1（To Space）区复制的时候，对象大小大于 To Space的可用内存，则把该对象转存到老年代。且老年代 的可用内存大小小于该对象大小

堆空间分代思想

不同对象的生命周期不同，70-99% 都是临时对象

• 新生代：由Eden、两块大小相同的Survivor（又称from/to，s0/s1）构成
• 老年代：存放新生代中经历多次GC依然存活的对象

分代的引入：优化GC性能；若没有分代，那么所有对象都在一起，GC时将会对整堆进行全局扫描，然而很多对象都是朝生夕死，分代后能将对象聚集在一起，优先回收这部分，节省空间、资源

堆内存分配策略

对象提升规则

• 对象在Eden出现并经过第一次Minor GC之后仍然存活，并且能被Survivor容纳，将被移动到Survivor区中。每熬过一次Minor GC,年龄+1，当年龄（默认15岁）达到一定程度将晋升老年代
• 针对晋升老年代的年龄，可通过：-XX:MaxTenuringThreshold 来设置

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

• 优先分配待Eden
• 大对象直接分配到老年代，尽量避免程序中出现过多的大对象
• 长期存活的对象分配到老年代
• 动态对象年龄判断，Survivor区中的相同年龄的所有对象总会大于Survivor空间一半，年龄>=该年龄的对象可直接进入老年代，无需等到MaxTenuringThreshold中要求的年龄
• 空间分配担保：-XX:HandlePromotionFailure

为对象分配内存：TLAB

什么是TLAB（Thread Local Allocation Buffer）

• 从内存模型而不是垃圾收集的角度，堆Eden区继续进行划分，JVM为每个线程分配了一个私有缓存区域，它包含在Eden区内
• 多线程同时分配内存时，使用TLAB可以避免一系列的非线程安全问题，同时还能提升内存分配的吞吐量，因此我们可以将这种内存分配方式称为 快速分配策略
• 几乎所有的OpenJDK衍生出来的JVM都提供TLAB设计

为什么要有TLAB

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

TLAB补充说明

• 尽管不是所有的对象实例都在TLAB中成功分配内存，但是 JVM确实把TLAB作为内存分配的首选
• 在程序中，开发人员可以通过选项“-XX:UseTLAB”设置是否开启TLAB空间
• 默认情况下，TLAB空间的内存非常小，仅仅占有整个Eden空间的1%。可通过设置：-XX:TLABWasteTargetPercent改变
• 一旦对象在TLAB空间分配内存失败，JVM就会尝试使用 加锁机制 来确保数据操作的原子性，从而在Eden区中直接分配内存

对象分配过程

小结堆空间的参数设置

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

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

• 若大于，则Minor GC安全
• 若小于，虚拟机会查看 -XX:HandlePromotionFailure 设置值是否运行担保失败
  • 若HandlePromotionFailure=true，继续检查老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小
    • 若大于，则尝试进行一次 Minor GC，这次Minor GC仍然有风险
    • 若小于，改为一次Full GC
  • 若HandlePromotionFailure=false，改为一次Full GC

在JDK6 Update24之后，HandlePromotionFailure参数不会再影响到虚拟机的空间分配担保策略，观察OpenJDK中的源码变化，虽然源码中定义了HandlePromotionFailure参数，但是在代码中已经不会使用它。在此版本之后规则变为 只要老年代的连续空间大于新生待对象总大小或者历次晋升的平均大小就会进行Minor GC，否则就执行Full GC

堆是分配对象存储的唯一选择吗

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

• 随着JIT编译器的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换优化技术将会导致一些微妙的变化，所有对象都分配到堆上就渐渐变得不是那么绝对了
• 在Java虚拟机中，对象是在Java堆中分配内存的，这是一个普遍常识。但又一种特殊情况，那就是 经过逃逸分析（Escape Analysis）后发现，若一个对象并没有逃逸出方法，那么久可能被优化为栈上分配，这就无需再堆上分配内存，也无需进行垃圾回收了
• 此外，基于OpenJDK深度定制的TaoBaoVM，其中创新GCIH（GC invisible heap）技术实现 off-heap，将生活周期比较长的Java对象从heap移到heap外，并且GC不能管理GCHI内部的对象，以此降低GC的回收频率和提升GC的回收效率和目的

逃逸分析概述

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

这是一种可以有效减少Java程序中同步负载和内存堆分配压力的跨函数全局数据流的分析算法

通过逃逸分析，Java Hotspot编译器能够分析出一个新的对象的引用适用范围从而觉得是否要将这个对象分配到堆上

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

• 当一个对象在方法中被定义之后，对象只在方法内部使用，则认为没有发生逃逸
• 当一个对象在方法中被定义后，它被外部的方法所引用，则认为发生逃逸。例如参数传递到其他方法中

快速判断是否发生逃逸分析：只在方法内部使用此对象

JDK 6u23版本之后，Hotspot中默认开启了逃逸分析

如果使用较早的版本

• 选项 ”-XX:+DoEscapeAnalysis“显示开启
• 选项 ”-XX:+PrintEscapeAnalysis“查看逃逸分析筛选

结论：开发中能使用局部变量的，就不要在方法外进行定义

逃逸分析：代码优化

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

• 栈上分配：将堆分配转化为栈分配，如果一个对象在子程序中被分配，要使指向该对象的指针永远不会逃逸，对象可能是栈分配的候选，而不是堆分配
• 同步策略：若对象被发现只能从一个线程被访问，那么对于这个对象的操作可以不考虑同步
• 分离对象或者标量替换：有的对象可能不需要作为一个联系的内存结构存在也可以被访问到，那么对象的部分可以不存储在内存，而是存储在CPU寄存器中

栈上分配

JIT编译器再编译期间根据逃逸分析的结果，发现某个对象没有逃逸出方法，就可能被优化为栈上分配。分配完成之后，继续调用栈内执行，最后线程结束，栈空间回收，局部变量对象也被回收，这样就无需进行垃圾回收

常见的栈上分配场景：给成员变量赋值、方法返回值、实例引用传递

同步策略 - 锁消除

线程之间同步的代价是降低并非性、性能

在动态编译同步块时，JIT编译器可借助逃逸分析来判断同步块所使用的锁对象是否只能被一个线程访问而没有被发布到其他线程。若没有，JIT编译器在这个同步块的时候就会取消堆这部分代码同步。这个取消同步的过程叫同步省略，也叫锁消除

分离对象或者标量替换

标量（Scalar）：一个无法在分解成更小的数据，Java中的原始数据类型就是标量

相对的，还能被分解的数据称为聚合量，Java中的对象就是聚合量，可分解为其他聚合量和标量

在JIT阶段，经过逃逸分析，发现一个对象不会被外界访问，那么经过JIT优化，就会把这个对象拆解成若干个成员变量来替代，这个过程就是标量替换

public class Test {
    public static void main(String[] args) {
        alloc();
    }

    public static void alloc() {
        Point point = new Point(1, 23);
        System.out.println(point.x);
        System.out.println(point.y);

    }
}

class Point {
    public int x;
    public int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

标量替换之后

public class Test {
    public static void main(String[] args) {
        alloc();
    }

    public static void alloc() {
        int x = 1;
        int y = 23;
        System.out.println(x);
        System.out.println(y);

    }
}

class Point {
    public int x;
    public int y;

    public Point(int x, int y) {
        this.x = x;
        this.y = y;
    }
}

Point这个聚变量经过逃逸分析之后，发现并没有逃逸，就会被替换为两个聚合量了

标量替换的好处：大大减少堆内存的占用，一旦不需要创建对象，就不再需要分配堆内存

• 开标量替换：-XX:+EliminateAllocations 开启了标量替换（默认打开），允许将对象打散分配在栈上

总结

逃逸分析的论文于1999年发表，但在JDK6才实现，技术还不成熟

根本原因：无法保证逃逸分析的性能消耗一定能高于他的消耗，虽然经过逃逸分析可以做标量替换、栈上分配、锁消除。但是逃逸分析自身也需要进一系列复杂的分析，也是一个相对耗时的过程