堆（线程共享）

scj1022

已于 2024-02-21 23:21:12 修改

阅读量421

点赞数 11

分类专栏： JVM 文章标签： jvm java

于 2023-12-24 21:22:43 首次发布

本文链接：https://blog.csdn.net/scj1022/article/details/135187210

版权

JVM 专栏收录该内容

14 篇文章 1 订阅

订阅专栏

堆（线程共享）

一、基本概念

1、概述

一个 JVM 进程只有一块堆内存，JVM 进程包含多个线程，他们是共享同一堆空间的。
- 可以划分线程私有的缓冲区（TLAB：Thread Local Allocation Buffer）
堆内存是 JVM管理的内存中最大的一块，也是垃圾收集器管理的主要区域，因此也被称作"GC堆"。
《Java 虚拟机规范》描述：所有的对象实例以及数组都应当在运行时分配在堆上。
- 栈帧中保存引用，指向对象或者数组在堆中的位置。
《Java 虚拟机规范》规定：堆可以处于物理上不连续的内存空间中，但在逻辑上它应该被视为连续的。

2、设置堆内存大小

Java 堆区在 JVM 启动的时候即被创建，其空间大小也就确定了。

设置堆内存大小：

-Xms 设置堆的起始内存，等价于-XX:InitialHeapSize
-Xmx 设置堆的最大内存，等价于-XX:MaxHeapSize

建议：将 -Xms 和 -Xmx 两个参数配置相同的值（避免GC前后堆内存的扩容和释放，减少不必要的性能损耗）

查看堆内存大小：

方式一：VM option 添加 -XX:+PrintGCDetails（程序运行结束打印堆空间信息）
方式二：jstat -gc 进程id（通过jps获取进程id）

默认情况下

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

public class HeapSpaceInitial {
    public static void main(String[] args) {
        // 运行时数据区内存
        long initialMemory = Runtime.getRuntime().totalMemory();
        long maxMemory = Runtime.getRuntime().maxMemory();

        // JVM堆内存
        System.out.println("-Xms : " + initialMemory / 1024 + "K");
        System.out.println("-Xmx : " + maxMemory / 1024 + "K");

        // 电脑物理内存
        System.out.println("系统内存大小：" + initialMemory * 64.0 / 1024 / 1024 / 1024 + "G");
        System.out.println("系统内存大小：" + maxMemory * 4.0 / 1024 / 1024 / 1024 + "G");

        try {
            TimeUnit.MINUTES.sleep(5);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

3、堆内存的OOM

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

public class OOMTest {
    public static void main(String[] args) {
        ArrayList<Picture> list = new ArrayList<>();
        while (true) {
            try {
                Thread.sleep(20);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
            list.add(new Picture(new Random().nextInt(1024 * 1024)));
        }
    }
}

class Picture {
    private byte[] bytes;

    public Picture(int length) {
        this.bytes = new byte[length];
    }
}

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
	at heap.Picture.<init>(OOMTest.java:26)
	at heap.OOMTest.main(OOMTest.java:16)

二、堆空间

1、年轻代 & 老年代

Java 堆从 GC 的角度可以细分为：新生代（Eden、Survivor0 、 Survivor1 ）和老年代。

在这里插入图片描述

新生代和老年代在堆结构的占比：

默认情况：-XX:NewRatio=2，表示新生代占 1，老年代占 2，新生代占整个堆的 1/3，老生代占整个堆的 2/3
参数修改：-XX:NewRatio=4，表示新生代占 1，老年代占 4，新生代占整个堆的 1/5，老生代占整个堆的 4/5

在 HotSpot 中，Eden区和另外两个 Survivor区的占比：

默认情况：-xx:SurvivorRatio=8，表示 Eden占8，From占1，To占1，Eden占整个年轻代的 1/10
实际情况：由于新生代默认开启 内存分配自适应，实际比例为 6：1：1，可通过 -XX:-UseAddaptiveSizePolicy 关闭。

可以使用选项-Xmn设置新生代最大内存大小，这个参数一般使用默认值就可以了。

如果和-XX:NewRatio发生冲突，以-Xmn为准

在这里插入图片描述

2、堆空间分代思想

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

其实不分代完全可以，分代的唯一理由就是优化 GC 性能。

如果没有分代，那所有的对象都在一块，GC 的时候要找到哪些对象没用，这样就会对堆的所有区域进行扫描。

而很多对象其实都是朝生夕死的，如果分代的话，把新创建的对象放到某一地方，当 GC 的时候先把这块存储“朝生夕死”对象的区域进行回收，这样就会腾出很大的空间出来。

3、堆内存 GC

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

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

部分收集：只对 Java堆的一部分进行GC。其中又分为：
- 新生代收集（Minor GC / Young GC）：只是新生代的垃圾收集
- 老年代收集（Major GC / Old GC）：只是老年代的圾收集。
  - 目前，只有 CMS GC 会有单独收集老年代的行为。
  - 注意：很多时候 Major GC 会和 Full GC 混淆使用，需要具体分辨是老年代回收还是整堆回收。
- 混合收集（MixedGC）：对整个新生代以及部分老年代进行垃圾收集。
  - 目前，只有 G1 GC 会有这种行为
整堆收集（Full GC）：对整个Java堆和方法区进行垃圾收集。

1）年轻代GC（Minor GC）

当年轻代空间不足时，就会触发 Minor GC。（这里指的是Eden空间不足，Survivor空间不足不会引发 GC）
每次 Minor GC 会清理年轻代的内存，包括 Eden区和 From区。
Java 对象大多都具备朝生夕灭的特性，所以 Minor GC 非常频繁，一般回收速度也比较快。
Minor GC 会引发 STW，暂停其它用户的线程，等垃圾回收结束，用户线程才恢复运行。

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

如果大于，则此次 Minor GC 是安全的
如果小于，那么会继续检查 老年代最大可用连续空间是否大于历次晋升到老年代的对象的平均大小。
- 如果大于，则尝试进行一次 Minor GC，但这次 Minor GC 依然是有风险的；
- 如果小于，则改为进行一次 Full GC。

2）老年代GC（Major GC）

当老年代空间不足时，会先尝试触发 Minor GC。如果之后空间还不足，则触发 Major GC
- 但非绝对的，在 Parallel Scavenge 收集器的收集策略里也有直接进行 Major GC 的策略选择过程
Major GC 的速度一般会比 Minor GC 慢 10 倍以上，STW 的时间更长
如果 Major GC 后，内存还不足，就报 OOM 了

3）堆+方法区GC（Full GC）

触发 Full GC 执行的情况有如下五种：

调用 System.gc() 时，系统建议执行 Full GC，但是不必然执行
老年代空间不足
方法区空间不足
通过 Minor GC 后进入老年代的平均大小大于老年代的可用内存
由 Eden区、From区向 To区复制时，复制的对象的大小超过 To区可用内存，则放到老年代，但是老年代的可用内存也不够时。

说明：Full GC 是开发或调优中尽量要避免的。

4、对象的分配过程

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

一类是生命周期较短的瞬时对象，这类对象的创建和消亡都非常迅速（新生代中 80%的对象都是“朝生夕死”的）
另外一类是生命周期很长的对象，在某些极端的情况下还能够与 JVM 的生命周期保持一致。

Java对象的分配过程如下：

new 的对象优先分配到 Eden区。
- 大对象直接分配到老年代。（可以通过 -XX:PretenureSizeThreshold 设置多大的对象直接进入老年代）
当Eden区空间不足时（放不下新new的对象），触发 Minor GC，进行新生代的垃圾回收。
- 首次 Minor GC，将 Eden区存活的对象放到 Survivor0区（年龄为1）
- 后续 Minor GC，将 Eden区和 From区存活的对象放到 To区（年龄+1）
什么时候会将对象放到老年代呢？
- 当 GC后 Eden区存活的对象 Survivor区放不下。（空间分配担保）
- 当对象存活年龄达到阈值时。（默认为15，可以通过 -XX:MaxTenuringThreshold 设置）
- Survivor区中，相同年龄的所有对象大小的总和大于 Survivor 空间的一半，年龄 >= 该年龄的对象直接进入老年代。
当老年代空间不足时，触发 Major GC，进行老年代的垃圾回收。
若老年代执行了 Major GC 之后，发现依然无法进行对象的保存，就会产生 OOM 异常。

流程图

在这里插入图片描述

三、线程私有的堆内存：TLAB

1、什么是TLAB？

TLAB，Thread Local Allocation Buffer，是 JVM 在 Eden区为每个线程分配的一块私有缓存区域（线程私有）

2、为什么需要TLAB？

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

3、TLAB 详细说明

TLAB 是 JVM 在 Eden区为每个线程分配的一块私有缓存区域（线程私有）。多线程同时分配内存时，使用 TLAB 可以避免一系列的
线程安全问题，同时还能够提升内存分配的吞吐量（快速分配策略）

在程序中，开发人员可以通过
- 参数 -XX:UseTLAB 设置是否开启 TLAB 空间。
- 命令 jps 和 jinfo -flag UseTLAB 进程id 查看是否开启（默认是开启的）
默认情况下，TLAB 空间的内存非常小，仅占有整个 Eden 空间的 1%
- 可以通过 -XX:TLABWasteTargetPercent 设置 TLAB 空间所占用 Eden 空间的百分比大小。
尽管不是所有的对象实例都能够在 TLAB 中成功分配内存，但 JVM 确实是将 TLAB 作为内存分配的首选。

一旦对象在 TLAB 空间分配内存失败，JVM 就会通过加锁等机制确保数据操作的原子性，从而直接在 Eden 空间中分配内存。

在这里插入图片描述

四、逃逸分析

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

在《深入理解 Java 虚拟机》中关于 Java 堆内存有这样一段描述：随着 JIT 编译期的发展与逃逸分析技术逐渐成熟，栈上分配、标量替换等优化将会导致一些微妙的变化，所有的对象都分配到堆上也渐渐变得不那么“绝对”了。

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

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

但是，Oracle Hotspot JVM 中并未这么做，这一点在逃逸分析相关的文档里已经说明，所以可以明确：对于Oracle Hotspot JVM 来说，所有的对象实例都是创建在堆上。

1、逃逸分析概述

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

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

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

当一个对象在方法中被定义后，对象只在方法内部使用，则认为没有发生逃逸。（使用栈上分配）
当一个对象在方法中被定义后，它被外部方法所引用，则认为发生逃逸。例如作为调用参数传递到其他地方中。

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

2、举例分析

【例1】

public void my_method() {
    V v = new V();
    // use v
    // ....
    v = null;
}

对象V只在方法内部使用，没有发生逃逸，则可以分配到栈上，随着方法执行的结束，栈空间就被释放。

【例2】

public static StringBuffer createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb;
}

上述代码中，StringBuffer sb对象被作为方法的返回值返回出去，可能被外部方法所引用，发生了逃逸。

如果想要StringBuffer sb不发生逃逸，可以这样写

public static String createStringBuffer(String s1, String s2) {
    StringBuffer sb = new StringBuffer();
    sb.append(s1);
    sb.append(s2);
    return sb.toString();
}

【例3】

如何快速判断是否发生逃逸？就看new的对象实体是否有可能在方法外被使用

public class EscapeAnalysis {

    public EscapeAnalysis obj;

    /**
     * 方法返回EscapeAnalysis对象，发生逃逸
     */
    public EscapeAnalysis getInstance() {
        return obj == null ? new EscapeAnalysis() : obj;
    }

    /**
     * 为成员属性赋值，发生逃逸（如果obj引用被声明为静态的？仍然会发生逃逸）
     */
    public void setObj() {
        this.obj = new EscapeAnalysis();
    }

    /**
     * 对象的作用于仅在当前方法中有效，没有发生逃逸
     */
    public void useEscapeAnalysis() {
        EscapeAnalysis e = new EscapeAnalysis();
    }

    /**
     * 引用成员变量的值，发生逃逸（这个属于getInstance()创建的对象逃逸到当前方法）
     */
    public void useEscapeAnalysis2() {
        EscapeAnalysis e = getInstance();
    }
}

3、参数设置

在 JDK 6u23 版本之后，HotSpot 中默认就已经开启了逃逸分析

如果使用的是较早的版本，开发人员则可以通过：

-XX:+DoEscapeAnalysis：显式开启逃逸分析
-XX:+PrintEscapeAnalysis：查看逃逸分析的筛选结果
-server：启动 Server 模式，因为在 server 模式下，才可以启用逃逸分析。

如果本身就是Server模式，可以省略-server

在这里插入图片描述

4、代码优化

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

1）栈上分配

JIT 编译器在编译期间根据逃逸分析的结果，发现如果一个对象并没有逃逸出方法的话，就可能被优化成栈上分配。

分配完成后，继续在调用栈内执行，最后线程结束，栈空间被回收，局部变量对象也被回收。这样就无须进行垃圾回收了。

/**
 * -Xmx1G -Xms1G -XX:-DoEscapeAnalysis -XX:+PrintGCDetails
 */
public class StackAllocation {
    public static void main(String[] args) {
        long start = System.currentTimeMillis();

        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        // 查看执行时间
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为： " + (end - start) + " ms");
        // 为了方便查看堆内存中对象个数，线程sleep
        try {
            Thread.sleep(1000000);
        } catch (InterruptedException e1) {
            e1.printStackTrace();
        }
    }

    private static void alloc() {
        User user = new User(); // 未发生逃逸
    }

    static class User {

    }
}

通过 -XX:-DoEscapeAnalysis 关闭逃逸分析 和 -XX:+DoEscapeAnalysis 开启逃逸分析 对比两次的结果

-Xmx128m -Xms128m -XX:+PrintGCDetails：堆内存设小一点，看是否发生GC（栈上分配不会发生GC）
-Xmx1g -Xms1g：堆内存设大一点，在不GC的情况下，通过jvisualvm查看对象个数

下图可以看到，没有开启逃逸分析时，堆内存中有10000000个User对象

在这里插入图片描述

2）同步省略

动态编译同步块时，JIT 编译器可以借助逃逸分析，判断synchronized锁对象是不是只可能被一个线程加锁，不存在其他线程来竞争加锁的情况。如果是，JIT 编译器在编译的时候就会取消对这部分代码的同步，这个过程就叫同步省略，也叫锁消除。

参数-XX:+EliminateLocks：开启同步替换（默认打开）。

线程同步的代价是相当高的，同步的后果是降低并发性和性能。同步省略可以大大提高并发性和性能。

public void syncTest() {
    Object obj = new Object();
    synchronized(obj) {
        System.out.println(obj);
    }
}

上述代码中，对 obj 对象加锁，但是obj 对象的生命周期只在方法内，不会逃逸，所以在 JIT 编译阶段就会把锁优化掉，如下所示：

public void syncTest() {
    Object obj = new Object();
    System.out.println(obj);
}

需要注意的是，上述是字节码文件加载到内存中以后的优化，直接反编译字节码文件可以看到，synchronized还是存在的。

在这里插入图片描述

3）标量替换

如果有的对象不需要作为一个连续的内存结构存在也可以被访问到，那么对象的部分（或全部）可以不存储在堆中，而是存储栈中

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

标量替换-相关概念

标量（scalar）是指一个无法再分解成更小的数据的数据。Java 中的基本数据类型就是标量。
聚合量（Aggregate）是指那些还可以分解的数据。Java 中的对象就是聚合量，因为他可以分解成其他聚合量和标量。

标量替换-参数设置

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

/**
 * -Xmx100m -Xms100m -XX:+DoEscapeAnalysis -XX:+PrintGC -XX:+EliminateAllocations
 */
public class ScalarReplaceTest {

    public static void main(String args[]) {
        long start = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            alloc();
        }
        long end = System.currentTimeMillis();
        System.out.println("花费的时间为： " + (end - start) + " ms");
    }

    private static void alloc() {
        Point point = new Point(1, 2); // 未发生逃逸
        System.out.println("point.x" + point.x + ";point.y" + point.y);
    }

    public static class Point {
        private int x;
        private int y;

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

}

以上代码，经过标量替换后，就会变成

private static void alloc() {
    int x = 1;
    int y = 2;
    System.out.println("point.x = " + x + "; point.y=" + y);
}

可以看到，Point 这个聚合量经过逃逸分析后，发现他并没有逃逸，就被替换成两个标量了。那么标量替换有什么好处呢？就是可以大大减少堆内存的占用。因为一旦不需要创建对象了，那么就不再需要分配堆内存了。标量替换为栈上分配提供了很好的基础。

5、小结：并不成熟

关于逃逸分析的论文在 1999 年就已经发表了，但直到 JDK1.6 才有实现，而且这项技术到如今也并不是十分成熟。

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

一个极端的例子，就是经过逃逸分析之后，发现没有一个对象是不逃逸的。那这个逃逸分析的过程就白白浪费掉了。

通过逃逸分析，JVM 会在栈上分配那些不会逃逸的对象，这在理论上是可行的，但是取决于 JVM 设计者的选择。Oracle Hotspot JVM 中似乎并未这么做，这一点在逃逸分析相关的文档里已经说明，所以对于 Oracle Hotspot JVM ，所有的对象实例都是创建在堆上。

scj1022

关注

11
点赞
踩
8

收藏

觉得还不错? 一键收藏
打赏
2
评论
堆（线程共享）

堆的基本概念、分代思想、TLAB、逃逸分析
复制链接

扫一扫

专栏目录

堆（线程共享）

文章目录

堆（线程共享）

一、基本概念

1、概述

2、设置堆内存大小

3、堆内存的OOM

二、堆空间

1、年轻代 & 老年代

2、堆空间分代思想

3、堆内存 GC

1）年轻代GC（Minor GC）

2）老年代GC（Major GC）

3）堆+方法区GC（Full GC）

4、对象的分配过程

三、线程私有的堆内存：TLAB

1、什么是TLAB？

2、为什么需要TLAB？

3、TLAB 详细说明

四、逃逸分析

1、逃逸分析概述

2、举例分析

3、参数设置

4、代码优化

1）栈上分配

2）同步省略

3）标量替换

5、小结：并不成熟