五、堆和GC介绍

Lundy_H

已于 2022-07-15 20:32:08 修改

阅读量507

点赞数 2

文章标签： jvm java 算法

于 2022-07-07 18:16:28 首次发布

本文链接：https://blog.csdn.net/weixin_40181736/article/details/125620611

版权

1、java堆的特点

《深入理解java虚拟机》是怎么描述java堆的

java堆（Java Heap）是java虚拟机所管理的内存中最大的一块
java堆被所有线程共享的一块内存区域
虚拟机启动时创建java堆
java堆的唯一目的就是存放对象的实例
java堆是垃圾收集器管理的主要区域
从内存回收的角度来看，由于现在收集器基本都采用分代收集算法，所以java堆可以细分为新生代（Young）和老年代（Old）。新生代又被划分为三个区域Eden、From Survivor、To Surivivor等。无论怎么划分，最终存储的都是实例对象，进一步划分的目的是为了更好的回收内存，或者更快的分配内存。
java堆的大小是可扩展的，通过-Xmx和-Xms控制。
- 如果堆内存不够分配实例对象，并且堆也无法再扩展时，将会抛出outOfMemoryEeeor异常

2、堆内存划分：

堆大小 = 新生代 + 老年代。堆的大小可通过参数-Xms（堆的初始容量）、-Xmx（堆的最大容量）来指定。
- 默认堆空间的大小
  - 如果不设置堆空间的大小：那么
  - 初始堆内存大小：物理电脑内存大小1 / 64.（64分之一）。
  - 最大堆内存大小：物理电脑内存大小1 / 4.(4分之一)。
- 手动设置：-Xms600m -Xmx600m
  - 开发中建议将初始堆内存和最大的堆内存设置成相同的值。设置成相同的值避免了频繁的回收和重新分配内存。
其中，新生代（Young）被细分为Eden和两个Survivor区域，这两个Survivor区域分别被命名为From和To，以示区分，Eden：From：To = 8：1：1。可以通过参数-XX：SurvivorRatio来设定。
即：Eden = 8/10的新生代空间大小，from = to = 1/10的新生代空间大小。
JVM每次只会使用Eden和其中的一块Survivor区域来为存储对象，所以无论什么时候，总是有一块Survivor区域是空闲的
新生代实际可用的内存空间时9/10（90%）的新生代空间

3、堆的垃圾回收方式

在讲垃圾回收方式前，我们需要知道如何确定视为垃圾和怎么回收垃圾？

3.1 如何确定垃圾

1）引用计数算法

引用计数算法（Reachability Counting）是通过在对象中分配一个空间来保存该对象被引用的次数。如果该对象被其他对象引用，则他的引用计数加1，如果删除该对象的引用，那么他的引用计数就减1，当该对象的引用计数为0时，那么该对象就会被回收。

对象如果没有任何与之关联的引用，即他们的引用计数都为0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。

举个例子：

然后将m设置为null，这时候“jack”的引用次数就等于0了，在引用计数算法中，意味着这块内容就需要被回收了。

引用计数算法是将垃圾回收分摊到整个应用程序的运行当中了，而不是在进行垃圾回收时，要挂起整个应用的运行，直到对堆中所有对象的处理都结束。因此，采用引用计数算法的垃圾收集不属于严格意义上的“Stop-The-World”的垃圾收集机制。

看似很美好，但是我们知道JVM的垃圾回收就是“Stop-The-World”的，那么是什么原因导致我们放弃了引用计数算法呢？如下例子说明。

public class RefrenceCountingGC {

    public object instance;
    
    public ReferenceCountingGC(String name){}

    public static void  testGC(){
    
    RefrenceCountingGC  a = new RefrenceCountingGC("objA");
    RefrenceCountingGC  b = new RefrenceCountingGC("objB");

    a.instance = b;
    b.instance = a;

    a = null;
    b = null;
    
    }
}

// 定义两个对象
// 相互引用
// 置空各自的声明引用

我们可以看到。最后这两个对象已经不可能再被访问了，但是由于他们相互引用对方，导致他们的引用计数永远都不为0，通过引用计数算法，也就是永远无法通知GC收集器回收他们。

2）、可达性分析算法

可达性分析算法的基本思路是，通过一系列的名为GC Roots的对象作为起点，从这些节点开始向下搜索，搜索走过的路径被称为引用链，当一个对象到GC Roots没有任务引用链相连时，（即从GC Roots节点到该节点不可达），则证明该对象是不可用的。

通过可达性算法，成功解决了引用计数算法所无法解决的问题（循环依赖），只要你无法与GC Roots建立直接或间接的连接，系统就会判定你为可回收对象。

哪些属于GC Roots

在java语言中，可作为GC Roots的对象包括以下4种：

1、虚拟机栈（栈帧中的局部变量表）中引用的对象

2、方法区中类静态属性引用的对象

3、方法区中常量引用的对象

4、本地方法栈中JNI（一般说的是Native方法）引用的对象

举例子说明：

1、虚拟机栈（栈帧中的局部变量表）中引用的对象

public class StackLocalParameter{

    public StackLocalParameter(String name){}

    public static void testGC(){

        StackLocalParameter s = new StackLocalParameter("localParameter);
        s = null;
    }

}

此时的s，即为GC Root，当s = null时，localParameter对象也断掉了与GC Root的引用链，将被回收。

2、方法区中类静态属性引用的对象

public class MethodAreaStaicProperties{

    public static MethodAreaStaicProperties m;
    
    public MethodAreaStaicProperties(String name){}

    public static void testGC(){

        MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties");
        s.m = new MethodAreaStaicProperties("parameter");
        s = null;
    }

}

s为GC Root，当s = null时，经过GC 后，s所指向的properties对象由于无法与GC Root建立关系被回收。

而m作为静态属性，也属于GC Root，parameter 对象依然与GC Root建立连接，所以此时parameter对象并不会被回收。

3、方法区中常量引用对象

public class MethodAreaStaicProperties{

    public static final MethodAreaStaicProperties m = new MethodAreaStaicProperties("final");
    
    public MethodAreaStaicProperties(String name){}

    public static void testGC(){

        MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties");
        s = null;
    }

}

m即为方法区中的常量引用，也为GC Root，当s = null时，final对象也不会因为没有与GC Root建立联系而被回收。

4、本地方法栈中引用的对象

任何 native 接口都会使用某种本地方法栈，实现的本地方法接口是使用 C 连接模型的话，那么他的本地方法栈这就是C栈。当线程调用Java方法时，虚拟机会创建一个新的栈帧并压入新的栈帧，虚拟机只是简单地动态链接并直接调用指定的本地方法。

要注意的是：不可达对象不等价于可回收对象，不可达对象变为可回收对象至少要经过两次的标记过程。两次标记后仍然是可回收对象，则将面临回收。

在分析怎么回收垃圾对象时先了解GC（垃圾收集器）

3.2 堆的垃圾回收方式

java堆是GC垃圾回收的主要区域。GC分为两种：Minor GC、Full GC（也叫Major GC）

1） Minor GC（简称GC）

Minor GC是发生在新生代中的垃圾收集动作，所采用的是复制算法。

GC一般为堆空间某个区发生了垃圾回收，

新生代（Young）几乎是所有java对象出生的地方。即Java对象申请的内存以及存放都是在这个地方。java中的大部分对象通常不会长久，具有朝生夕死的特点。

当一个对象被判定为“死亡”的时候，GC就有责任来回收掉这部分对象的内存空间。

回收过程如下：

当对象在Eden（包括一个Survivor区域，这里假设是from区域）出生后，在经历一次Minor GC后，如果对象还活着，并且能够被另外一块Survivor区域所容纳（上面已经假设为from区域，这里因为to区域，即to区域有足够的内存空间在存储Eden和from区域中存活的对象），则使用复制算法将这些仍然还存活的对象复制到另一块Survivor区域（即to区域）中，然后清理所使用过的Eden以及from Survivor区域，并且把复制到to Survivor区域的对象年龄设置为1，然后再第二轮存储对象时，From和to区域会调换位置（刚开始是Eden和From区域，然后第二轮就是Eden和To区域），后续也是一样会把复制的区域与Eden区域继续存储对象，空的Survivor区域就会等待下一次Minor GC回收复制再进行调换。以后对象在Survivor区域每熬过一次Minor GC，就将对象的年龄+1，当对象的年龄达到某个值时（默认是15岁，可以通过参数-XX:MaxTenuringThreshold来设定），这些对象就会成为老年代。

但这也不是一定的，对于一些较大的对象（即需要分配一块较大的连续内存空间）则是直接进入到老年代。

2） Full GC

Full GC 基本都是整个堆空间及持久代发生了垃圾回收，所采用的是标记-清除算法。现实生活中，老年代的人通常会比新生代的人“早死”。堆内存中的老年代（Old）不同于这个，老年代里面的对象几乎个个都是在Survuvor区域中熬过15次Minor GC垃圾回收留下来的，他们是不会那么容易就“回收”的。因此，Full GC 发生的次数不会又Minor GC那么频繁，并且做一次Full GC要比进行一次Minor GC的时间更长，一般是Minor GC的10倍以上。

另外，标记-清除算法收集垃圾的时候会产生许多的内存碎片（即不连续的内存空间），此后需要为较大的对象分配内存空间时，若无法找到足够的连续内存空间，就会提前触发一次GC的收集动作

扩展：Minor GC是如何触发的，又是如何工作的？如下图：

Minor GC是由字节码执行引擎触发的，当我们的程序中需要new一个对象的时候，就会将这个对象放入到Eden区域，当Eden区域的对象越来越多，直到满了，这时放不下了，就会触发字节码执行引擎发起GC操作。这一次发起的GC，将会看看哪些对象还活着，哪些对象已经不用了，活着的对象放入Survivor中的一个区，不在被引用的对象直接被回收了。

3.3、怎么回收垃圾

在确定了哪些垃圾可以回收后，垃圾收集器要做的事情就是开始进行垃圾回收，但是这里涉及到一个问题：如何高效的进行垃圾回收。由于java虚拟机规范并没有对如何实现垃圾收集器做出明确的规定，因此各大厂商的虚拟机可以采用不同的方式来实现垃圾收集器。

1）标记 - - - 清除算法（Mark-Sweep）

最基础的垃圾回收算法，分为两个阶段，标记和清除

先把内存区域中这些对象进标记，哪些属于可以回收标记出来。然后把这些垃圾清除掉。就像上图一样，清理掉的垃圾就变成未使用的内存区域，等待被再次使用。

该算法最大的问题是内存碎片化严重，后续可能发生大对象不能找到可以利用空间的问题。

假设有一个对象是2M，内存碎片小的一些的1M，大一些的是4M，等我们回收完，内存就会切成了很多段，我们开辟的内存空间时，需要的是连续的内存区域，这时我们需要一个2M的内存区域，其中有两个1M是没法用的，这样就导致本来还有很多内存，但是却用不了。

2）标记 - - - 复制算法（copying）

复制算法是在标记清除算法上演化而来，解决标记清除算法的内存碎片问题。他讲可用的内存按容量划分为大小相等的两块，每次只使用其中的一块，当这一块的内存用完了，就将还存活着的对象复制到另一块上面，然后再把已使用过的内存空间一次清理掉。保证了内存连续可用，内存分配时也就不用再考虑内存碎片等复杂情况，逻辑清晰，运行高效。

上面的图很清楚，也很明显的暴露了另一个问题，合着我这140平的大三房，只能当70平米的小两房来使用？代价太高。

3）标记 - - - 整理算法(Mark-Compact)

标记整理算法：标记过程仍然与标记 - - - 清除算法一样，但是后续步骤不是直接对可回收对象进行清理，而是让所有存活的对象都向一端移动，在清理掉端边界以外的内存区域。

标记整理算法一方面在标记-清除算法上做了升级，解决了内存碎片的问题，也规避了复制算法只能利用一半内存区域的弊端。看起来很美好，但是从上图可以看到，它对内存变动跟频繁，需要整理所有存活对象的引用地址，在效率上比复制算法要差很多。

4）分代收集算法（重点）

分代收集算法目前大部分JVM所采用得方法，其核心思想是根据对象存活的不同生命周期将内存划分为不同的区域，一般情况下将GC堆划分为新生代和老年代。新生代的特点是每次垃圾回收时都有大量垃圾需要被回收，而老年代的特点是每次垃圾回收时只有少量对象需要被回收，因此可以根据不同区域选择不同的算法。

java堆是JVM所管理的内存中最大的一块，堆又是垃圾收集器管理的主要区域，java堆主要分为2个区域-新生代和老年代，其中新生代又分为Eden区和Survivor（幸存者）区，其中Survivor区又分为From和To2个区。

疑问：为什么需要Survivor区，为什么Survivor区又分为From和To2个区。

Eden 区

IBM 公司的专业研究表明，有将近98%的对象是朝生夕死，所以针对这一现状，大多数情况下，对象会在新生代Eden 区中进行分配，当Eden区没有足够空间进行分配时，虚拟机会发起一次Minor GC,Minor GC相比Major GC（Full GC）跟频繁，回收速度更快。

通过Minor GC之后，Eden会被清空，Eden 区中绝大部分对象会被回收，而那些没有回收的存活对象，将会进到Survivor的From区（若From区不够，则直接进去Old区）。

Survivor 区

Survivor 区相当于是Eden 区和Old 区的一个缓冲区，类似于我们交通灯中的黄灯。Survivor 又分为2个区，一个是From区，一个是To区。每次执行Minor GC,会将Eden 区和From存活的对象方法哦Survivor的To 区（如果To区不够，则直接进入Old区）

Old 区

老年代占据着2/3的堆内存空间，只有在Full GC的时候才会进行清理，每次GC都会触发“Stop-The-World”。内存越大，STW的时间也越长，所以内存也不仅仅是越大就越好。由于复制算法在对象存活率较高的老年代会进行很多次的复制操作，效率很低，所以老年代这里采用的是标记 --- 整理算法。

在内存担保机制下，无法安置的对象会直接进到老年代，以下几种情况也会直接进入老年代。

1、大对象

大对象指需要大量连续内存空间的对象，这部分对象不管是不是“朝生夕死”，都会直接进到老年代。这样做主要是为了避免在Eden区及两个Survivor区直接发生大量的内存复制。当你的系统有非常多的“朝生夕死”的大对象时，得注意了。

2、长期存活对象

虚拟机给每个对象定义了一个对象年龄计数器。正常情况下对象会不断的在Survivor的From区与To区之间移动，对象在Survivor区中每经历一次Minor GC，年龄就会增加1，当年龄增加到15岁时，这时候就会被转移到老年代。当然，这里的15，JVM也支持进行特殊设置。

3、动态对象年龄

虚拟机并不重视要求对象年龄必须到15岁，才会放入到老年区，如果Survivor空间中相同年龄所有对象大小的综合大于Survivor空间的一半，年龄大于等于该年龄的对象就可以直接进去老年区，无需等你“成年”。

解答：1、为啥需要Survivor？

不就是新生代到老年代么，直接Eden 到 Old不好吗？为啥要那么复杂。想想如果没有Survivor区，Eden区每进行一次Minor GC，存活的对象就会被送到老年代，老年代很快就会被填满。而有很多对象虽然一次Minor GC没有消灭，当其实也并不会蹦跶多久，或许第二次，第三次就需要被清除。这时候移入老年区，很明显不是一个明智的决定，因此需要一个Survivor区作为缓冲区。

2、为啥需要俩？

设置两个Survivor区最大的好处就是解决内存碎片化。

我们先假设一下，Survivor如果只有一个区域会怎么样。Minor GC执行后，Eden区会被清空了，存活的对象放到了Survivor区，而之前Survivor区中的对象，可能也有一些是需要被清除的。问题来了，这时候我们怎么清除他们？在这种场景下，我们只能标记清除，而我们知道标记清除最大的问题就是内存碎片化，在新生代这种经常会消亡的区域，采用标记清除必然会让内存产生严重的碎片化。因此Survivor有2个区域，所以每次Minor GC，会将之前Eden区和From区中的存活对象复制到To区域。第二次Minor GC时，From与To职责兑换，这时候会将Eden区和To区中的存活对象再复制到From区域，以此反复次数达到15次后就会把存活的对象放到Old区。

这种机制最大的好处就是，整个过程中，永远有一个Survivor区是空的，另一个非空的Survivor去是无碎片化的。那么，Survivor为什么不分更多块呢？比方说分成三个、四个、五个？显然，如果Survivor区再细分下去，，每一块的空间就会比较小，容易导致Survivor区满，两块Survivor区可能是经过权衡之后的最佳方案。

3、如何判断对象是否还活着呢？

字节码执行引擎会去找很多GC Root

4、什么是GC Root呢？

GC Root是一个对象，以这个对象作为启动点，从这些节点开始向下搜索引用的对象，找到的对象都标记为非垃圾对象，其余未标记的对象都是垃圾对象。

5、GC Root根节点有哪些？

线程栈中栈帧的局部变量，方法区中的静态变量和常量，本地方法栈的变量等等。

6、垃圾收集器的原理（还是以Math.class为例子）

在Math中，我们看栈中main方法的局部变量表中的math变量，方法区中的user变量，他们都是GC Root根对象，他们指向的是一块堆内存空间。

实质是，GC垃圾回收的过程，就是寻找GC Root的过程，从栈中找局部变量，从方法区中找静态变量，从GC Root出发，找到所有的引用变量，这些变量可能会引用其他的变量，变量还会再引用其他的变量，直到不再引用其他变量为止，以上这些都是非垃圾对象，如果一个对象没有被任何对象引用，那它就是垃圾对象。

垃圾对象最后就被回收，非垃圾对象进入到Survivor的一个区域里面，每次进入Survivor区域，对象的分代年龄都会＋1，分代年龄保存在哪里呢？保存在对象头里面。

程序还在继续运行，又会产生新的对象放入到Eden区，当Eden区（含Survivor区中的其中一个）又被放满，就会再次触发GC，此时会寻找Eden+Survivor(一个区域)中的GC Root，将其标记，

没有被引用的对象被回收，其他被引用的对象会保存到另一个survivor区域，分代年龄+1

这样运行，知道分代年龄为15（默认15，可以设置）时，也就是GC发生了15次还活着的对象，就会被方法老年代。

7、通常什么样的对象会直接放到老年代呢？

静态变量引用的对象，静态常量，比如说：对象池，缓存对象和Spring容器里面的对象等。

4、使用工具查看GC流程的过程

我们使用的工具是jvisualvm工具，这是JDK自带的一个工具。这个工具通常是在开发环境使用，因为其本身比较耗性能，所以线上一般不用。本地调试可以使用。

先来准备一段代码，一段简单的代码，不停的去产生新的对象。

package com.jvm;

import java.util.ArrayList;
import java.util.List;

public class HeapTest {

    public static void main(String[] args) throws InterruptedException {
        List<User> userList = new ArrayList<>();

        while (true) {
            userList.add(new User());
            Thread.sleep(10);
        }
    }
}

我们来按照上面的逻辑分析代码

1、userList：是放在栈中的局部变量表中的一个变量

new ArrayList<>：是放在堆中的一个对象

2、new User()：在堆中构建一个新的User对象，并分配了一个地址，并将这个地址添加到 new ArrayList()中。

这里面userList是根对象，new User（）最终会被new ArrayList()引用，而userList又引用new ArrayList()；所以，他们都不会是垃圾对象，因此都不会被回收。

那么死循环不停的构造对象，添加引用，Eden区迟早会放满，放满了就会触发GC，那么GC能把他们回收呢？回收不了，因为都在被GC Root直接或间接引用。最终都会被放入老年代。然后还在持续构造对象，最终会怎么样呢？最终会内存溢出，我们来看看可视化效果。

首先，我们启动程序，然后在控制台中启动jvisualvm

我们来看的是HeapTest，这里面有很多性能指标可以查看，我们重点看visual GC,如果没有visual GC可以参考这篇文章：jdk8 jvisualvm 插件安装报错_猎人在吃肉的博客-CSDN博客

从这个图上，我们可以看到每过一段时间就会触发一次GC，因为不能被回收，因此会转移到另一个survivor区域，经过15次回收，还没有回收清理，那么就进入到old老年区。

老年区的对象越来越多，当老年代对象满了以后，会触发full GC,full GC回收的是整个堆以及方法区的内容，实际上老年代没有能够回收的对象，这时候在往老年代放，就会OOM

使用这个工具还可以分析我们自己的程序代码的来及回收情况。

5、Stop The World

在发生GC的时候，会发生STW，Stop the world

1、什么是Stop The World呢？

举个例子：在一个电商网站，用户正在下单，这是由于内存满了，触发了GC，这时候整个线程就会处于停滞状态。用户的感觉就是一直在loading。。。直到GC完毕，应用线程恢复工作。所以Stop the World对我们的用户是有一定影响的。JVM调优主要的目的就是减少Full GC的次数和时间。minor gc也会stop the world，但是他的时间很短，所以我们重点调优还是在Full GC.

2、那么为什么一定要stop the world呢？不STW可以吗？

回答这个问题，我们可以使用假设法，假设没有stop the world会怎么样？

我们知道，在垃圾回收之前，要先找到 GC Root，然后标记是否被引用，最终没有被引用的对象就是我们要回收的垃圾对象。那就是没有对象引用他了，通常会回收这块内存空间地址，这个时候如果主线程也在运行，刚好有一个变量存放在这个内存，而你并行触发了GC，这时候程序就发生混乱了。

这是一种情况，另一种情况是在触发GC的过程中，一部分变量正在被标记，而GC已经开始了，标记完以后，发现了垃圾，结果由于GC已经扫描完这里了，到这一块垃圾没有被清理掉，要等待下一次垃圾回收清理。

阿里二面：说说JVM的Stop the World？

Lundy_H

关注

2
点赞
踩
8

收藏

觉得还不错? 一键收藏
0
评论
五、堆和GC介绍

《深入理解java虚拟机》是怎么描述java堆的在讲垃圾回收方式前，我们需要知道如何确定视为垃圾和怎么回收垃圾？对象如果没有任何与之关联的引用，即他们的引用计数都为0，则说明对象不太可能再被用到，那么这个对象就是可回收对象。举个例子：然后将m设置为null，这时候“jack”的引用次数就等于0了，在引用计数算法中，意味着这块内容就需要被回收了。看似很美好，但是我们知道JVM的垃圾回收就是“Stop-The-World”的，那么是什么原因导致我们放弃了引用计数算法呢？如下例
复制链接

扫一扫