JVM 垃圾回收详细学习笔记

圆锥曲线丶

已于 2022-08-02 22:43:10 修改

阅读量157

点赞数 1

分类专栏： JVM 文章标签： jvm 学习 java 算法

于 2022-07-06 17:32:35 首次发布

本文链接：https://blog.csdn.net/qq_45702539/article/details/125635356

版权

JVM 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本篇博客记录个人学习jvm的过程，如有错误，敬请指正

文章目录

一、判断对象是否可被回收
- 1.引用计数法
- 2.可达性算法
二、四种引用
三、垃圾回收算法
四、GC相关
- 1.JVM参数
- 2.GC小案例
五、垃圾收集器

一、判断对象是否可被回收

1.引用计数法

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1；当引用失效，计数器就减 1；任何时候计数器为 0 的对象就是不可能再被使用的。

这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。如下面代码所示：除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。

public class ReferenceCountingGc {
    Object instance = null;
	public static void main(String[] args) {
		ReferenceCountingGc objA = new ReferenceCountingGc();
		ReferenceCountingGc objB = new ReferenceCountingGc();
		objA.instance = objB;
		objB.instance = objA;
		objA = null;
		objB = null;

	}
}

在这里插入图片描述

2.可达性算法

这个算法的基本思想就是通过一系列的称为 “GC Roots” 的对象作为起点，从这些节点开始向下搜索，节点所走过的路径称为引用链，当一个对象到 GC Roots 没有任何引用链相连的话，则证明此对象是不可用的，需要被回收。

下图中的 Object 6 ~ Object 10 之间虽有引用关系，但它们到 GC Roots 不可达，因此为需要被回收的对象。
在这里插入图片描述

常作为GC Roots的对象

虚拟机栈（栈帧中的本地变量表）中引用的对象（这里说的对象都是指new出来存储在堆中的对象）。
本地方法栈(Native 方法)中引用的对象
方法区中类静态属性引用的对象
方法区中常量引用的对象
所有被同步锁持有的对象

二、四种引用

引用分为强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）
1．强引用（StrongReference）

以前我们使用的大部分引用实际上都是强引用，这是使用最普遍的引用。如果一个对象具有强引用，那就类似于必不可少的生活用品，垃圾回收器绝不会回收它。当内存空间不足，Java 虚拟机宁愿抛出 OutOfMemoryError 错误，使程序异常终止，也不会靠随意回收具有强引用的对象来解决内存不足问题。

2．软引用（SoftReference）

软引用，如果内存空间足够，垃圾回收器就不会回收它，如果内存空间不足了，就会回收这些对象的内存。只要垃圾回收器没有回收它，该对象就可以被程序使用。软引用可用来实现内存敏感的高速缓存。

软引用可以和一个引用队列（ReferenceQueue）联合使用，如果软引用所引用的对象被垃圾回收，JAVA 虚拟机就会把这个软引用加入到与之关联的引用队列中。在回收软引用所指向的对象时，软引用本身不会被清理，如果想要清理软引用，需要使用引用队列

3．弱引用（WeakReference）

弱引用与软引用的区别在于：只具有弱引用的对象拥有更短暂的生命周期。在垃圾回收器线程扫描它所管辖的内存区域的过程中，一旦发现了只具有弱引用的对象，不管当前内存空间足够与否，都会回收它的内存。不过，由于垃圾回收器是一个优先级很低的线程，因此不一定会很快发现那些只具有弱引用的对象。
弱引用同样可以和引用队列联合使用

4．虚引用（PhantomReference）

与其他几种引用都不同，虚引用并不会决定对象的生命周期。如果一个对象仅持有虚引用，那么它就和没有任何引用一样，在任何时候都可能被垃圾回收。虚引用必须和引用队列联合使用（因为被引用对象被回收后，其关联的直接内存是无法被直接释放的，因为这个直接内存不受jvm管控，所以为了回收这个直接内存就需要这个虚引用和队列配合起来使用）
在这里插入图片描述
软引用使用案例

package com.atguigu.test8;

import com.sun.scenario.effect.impl.sw.sse.SSEBlend_SRC_OUTPeer;

import java.io.IOException;
import java.lang.ref.SoftReference;
import java.util.ArrayList;

public class Demo1 {
    public static int _4MB = 4 * 1024 * 1024;
    public static void main(String[] args) throws IOException {
        method1();
    }
    // 设置 -Xmx20m , 演示堆内存不足,
    public static void method1() throws IOException {
        ArrayList<byte[]> list = new ArrayList<>();
        for(int i = 0; i < 5; i++) {
            list.add(new byte[_4MB]);
        }
        System.in.read();
    }
    // 演示 软引用
    public static void method2() throws IOException {
        //使用软引用对象 list和SoftReference之间是强引用，而SoftReference和byte数组之间则是软引用
        ArrayList<SoftReference<byte[]>> list = new ArrayList<>();
        for(int i = 0; i < 5; i++) {
            SoftReference<byte[]> ref = new SoftReference<>(new byte[_4MB]);
            System.out.println(ref.get());
            list.add(ref);
            System.out.println(list.size());
        }
        System.out.println("循环结束：" + list.size());
        for(SoftReference<byte[]> ref : list) {
            System.out.println(ref.get());
        }
    }
}

我们测试前，需要先设置jvm参数，将堆内存的大小设置成20mb，并且打印GC信息

-Xmx20m -XX:+PrintGCDetails -verbose:gc

运行method1，由于list是强引用，jvm不会回收而是报出异常

在这里插入图片描述
运行method2，此时我们在 list 集合中存放了软引用对象，在第五次往list中存放数据时，内存不足会触发 full gc，将软引用的对象回收

上面是没有回收软引用本身的，回收软引用得使用引用队列，修改代码如下
在这里插入图片描述

在这里插入图片描述

三、垃圾回收算法

1.标记-清除算法

该算法分为“标记”和“清除”阶段：首先标记出所有不需要回收的对象，在标记完成后统一回收掉所有没有被标记的对象。它是最基础的收集算法，后续的算法都是对其不足进行改进得到。这种垃圾收集算法会产生内存碎片

下图的蓝色是标记的，无需回收的对象
在这里插入图片描述

2.标记-整理算法

标记过程仍然与“标记-清除”算法一样，但后续步骤不是直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉端边界以外的内存，效率较低
在这里插入图片描述

3. 标记-复制算法

为了解决效率问题，“标记-复制”收集算法出现了。它可以将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收，缺点是内存需要更多（双倍）
在这里插入图片描述

4.分代收集算法

当前虚拟机的垃圾收集都采用分代收集算法，它根据对象存活周期的不同将内存分为几块。一般将 java 堆分为新生代和老年代，这样就可以根据各个年代的特点选择合适的垃圾收集算法。

比如在新生代中，每次收集都会有大量对象死去，所以可以选择”标记-复制“算法，只需要付出少量对象的复制成本就可以完成每次垃圾收集。而老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

下面是分代收集算法的具体步骤
1.新建的对象进入伊甸园

2.当伊甸园中的内存满了时，触发MirrorGC，会使用复制算法，将存活对象复制进To区，并且寿命加1
在这里插入图片描述
3.将To区和From区交换（就是复制算法），始终保持To区为空

下面那个2改成1（尴尬）

4.周而复始，当有对象年龄达到15(不是绝对的)对象还存活，就会进入老年代区
在这里插入图片描述
5.如果新生代老年代中的内存都满了，就会先触发Minor GC，再触发Full GC，扫描新生代和老年代中所有不再使用的对象并回收；

四、GC相关

1.JVM参数

含义	参数
堆初始大小	-Xms
堆最大大小	-Xmx或-XX:MaxHeapSize=size
新生代大小	-Xmn 或 (-XX:NewSize=size + -XX:MaxNewSize=size )
幸存区比例（动态）	-XX:InitialSurvivorRatio=ratio 和 -XX:+UseAdaptiveSizePolicy
幸存区比例	-XX:SurvivorRatio=ratio
晋升阈值	-XX:MaxTenuringThreshold=threshold
晋升详情	-XX:+PrintTenuringDistribution
GC详情	-XX:+PrintGCDetails -verbose:gc
FullGC 前 MinorGC	-XX:+ScavengeBeforeFullGC

2.GC小案例

首先我们需要设置jvm的一些参数：

-Xms20m -Xmx20m -Xmn10m -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc

代码如下

public class Demo1 {
    private static final int _512KB = 512 * 1024;
    private static final int _1MB = 1024 * 1024;
    private static final int _6MB = 6 * 1024 * 1024;
    private static final int _7MB = 7 * 1024 * 1024;
    private static final int _8MB = 8 * 1024 * 1024;

    // -Xms20m -Xmx20m -Xmn10m -XX:+UseSerialGC -XX:+PrintGCDetails -verbose:gc
    public static void main(String[] args) {
        List<byte[]> list = new ArrayList<>();
        list.add(new byte[_7MB]);
        list.add(new byte[_1MB]);
        list.add(new byte[_6MB]);
        list.add(new byte[_512KB]);
        list.add(new byte[_6MB]);
    }

}

首先我们在list什么都不加，可以看到如下信息
在这里插入图片描述
加入7m后，触发一次mirror GC

再次添加1mb

如果我们直接放入8mb，已经超过了新生代的总大小，这个大对象会直接放入老年代

我们再次放入8mb

当我们把上面的代码放入另一个线程运行，程序不会结束
一个进程内的OOM不会导致整个程序结束

五、垃圾收集器

如果说收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

1.Serial（串行）收集器

看名字就知道这个收集器是一个单线程收集器了。它的 “单线程” 的意义不仅仅意味着它只会使用一条垃圾收集线程去完成垃圾收集工作，更重要的是它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ “Stop The World” ），直到它收集结束。

新生代采用标记-复制算法，老年代采用标记-整理算法。

安全点：让其他线程都在这个点停下来，以免垃圾回收时移动对象地址，使得其他线程找不到被移动的对象, 因为是串行的，所以只有一个垃圾回收线程。且在该线程执行回收工作时，其他线程进入阻塞状态
在这里插入图片描述

2.Parallel Scavenge（吞吐量优先）收集器

这是 JDK1.8 默认收集器
Parallel Scavenge 收集器关注点是吞吐量（高效率的利用 CPU）
Parallel Scavenge 收集器提供了很多参数供用户找到最合适的停顿时间或最大吞吐量。使用 Parallel Scavenge 收集器配合自适应调节策略，把内存管理优化交给虚拟机去完成也是一个不错的选择。

GC自适应调节策略：Parallel Scavenge收集器可设置-XX:+UseAdptiveSizePolicy参数。当开关打开时不需要手动指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRation）、晋升老年代的对象年龄（-XX:PretenureSizeThreshold）等，虚拟机会根据系统的运行状况收集性能监控信息，动态设置这些参数以提供最优的停顿时间和最高的吞吐量，这种调节方式称为GC的自适应调节策略。
新生代采用标记-复制算法，老年代采用标记-整理算法。

在这里插入图片描述

3.CMS（响应时间优先）收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用。

CMS分为以下几个步骤
初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快；
并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。
重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短
并发清除： 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

在这里插入图片描述
缺点

无法处理浮动垃圾；
它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生。

4.G1 收集器

G1 (Garbage-First) 是一款面向服务器的垃圾收集器,主要针对配备多颗处理器及大容量内存的机器. 以极高概率满足 GC 停顿时间要求的同时,还具备高吞吐量性能特征

G1垃圾回收过程
在这里插入图片描述
第一阶段：新生代GC阶段

下面是G1收集器的堆的划分形式，它将堆划分出许多大小相同的区域，当创建新对象时会进入伊甸园区（下图的E），当伊甸园满了后进行mirrorGC触发STW，之后会复制进幸存区（下图的S），当幸存区到达一定年龄时会进入老年区（下图O）
在这里插入图片描述
这张图更加易懂：

第二阶段：新生代GC和并发标记阶段

在 Young GC （新生代GC就发生了）时会对 GC Root 进行初始标记
在老年代占用堆内存的比例达到阈值（默认45%）时，进行并发标记（不会STW既不会影响用户工作线程）（这个并发标记是指从根对象出发，顺着引用链去找其他的标记对象），阈值由下面的 JVM 参数决定：

-XX:InitiatingHea![在这里插入图片描述](https://img-blog.csdnimg.cn/aafa6ee6c1f1449aaf22e4ffb7e34e37.png)
pOccupancyPercent=percent

第三阶段：混合收集

最终标记会STW（在上一阶段的并发标记时会有用户线程在一起工作，会产生新的垃圾）
拷贝存活会STW
下面的jvm参数设置可以指定最长的停顿时间

-XX:MaxGCPauseMills=xxms

G1的老年代回收器不需要整个老年代被回收，一次只需要回收一小部分老年代的Refgion（为了保证回收时间不是太长），同时整个老年代Region是和年轻代一起被回收的
在这里插入图片描述

Full GC:
G1在老年代内存不足时（老年代所占内存(在堆中的占比)超过阈值）

如果垃圾产生速度慢于垃圾回收速度，不会触发Full GC，还是并发地进行清理
如果垃圾产生速度快于垃圾回收速度，便会触发Full GC

Rembered Set解决跨代引用

新生代引用老年代不用考虑这个问题，因为在后面的混合GC或者FullGC中，二者是一起的。
老年代引用老年代也需要记录。混合GC时，只会回收部分老年代，被回收的老年代需要正确的标记哪些对象存活。
而年轻代GC则不同，新生代回收的跨代引用问题（老年代引用新生代）：
一个对象被不同区域引用，一个Region不可能是孤立的，一个Region中的对象可能被另一个Region中的对象引用，判断对象存活时是否需要扫描整个堆才能保证准确？

解决方法：
无论在G1收集器还是其他分代收集器中，JVM都是采用Rembered Set来避免全局扫描
在这里插入图片描述
因此G1采用的是对老年代进行再细分（每一个是512k）,如果这个卡表里面的卡的老年代引用了新生代的对象，那么就把该卡标记为脏卡；

这样做的好处是：我们只需要去关注这个脏卡就行，这样就可以减少搜索的范围；

下面几张图是G1回收器的具体过程：

在这里插入图片描述

圆锥曲线丶

关注

1
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
JVM 垃圾回收详细学习笔记

给对象中添加一个引用计数器，每当有一个地方引用它，计数器就加 1；当引用失效，计数器就减 1；任何时候计数器为 0 的对象就是不可能再被使用的。这个方法实现简单，效率高，但是目前主流的虚拟机中并没有选择这个算法来管理内存，其最主要的原因是它很难解决对象之间相互循环引用的问题。如下面代码所示：除了对象 objA 和 objB 相互引用着对方之外，这两个对象之间再无任何引用。但是他们因为互相引用对方，导致它们的引用计数器都不为 0，于是引用计数算法无法通知 GC 回收器回收他们。这个算法的基本思想就是通过一系
复制链接

扫一扫