Java 垃圾回收机制

目录

垃圾回收是一种在堆内存中找出哪些对象在被使用，还有哪些对象没被使用，并且将后者回收掉的机制。

所谓使用中的对象，指的是程序中还有引用的对象；而未使用中的对象，指的是程序中已经没有引用的对象，该对象占用的内存也可以被回收掉。

垃圾回收的基础知识

Java 的自动内存管理主要是针对对象内存的回收和对象内存的分配。

堆空间的基本结构

Java 自动内存管理最核心的功能是堆内存中对象的分配与回收。堆是垃圾收集器管理的主要区域，因此也被称作 GC 堆（Garbage Collected Heap）。

从垃圾回收的角度来说，由于现在收集器基本都采用分代垃圾收集算法，所以 Java 堆被划分为了几个不同的区域，这样我们就可以根据各个区域的特点选择合适的垃圾收集算法。

在 JDK 8 版本之前，堆内存被通常分为下面三部分：

  • 新生代内存(Young Generation)

  • 老生代(Old Generation)

  • 永久代(Permanent Generation)

image

内存分配和回收原则

对象优先在 Eden 区分配

大多数情况下，对象在新生代中 Eden 区分配。当 Eden 区没有足够空间进行分配时，虚拟机将发起一次 Minor GC。

大对象直接进入老年代

大对象就是需要大量连续内存空间的对象（比如：字符串、数组）。

大对象直接进入老年代的行为是由虚拟机动态决定的，它与具体使用的垃圾回收器和相关参数有关。大对象直接进入老年代是一种优化策略，旨在避免将大对象放入新生代，从而减少新生代的垃圾回收频率和成本。

  • G1 垃圾回收器会根据参数设置的阈值，来决定哪些对象会直接进入老年代。

    -XX:G1HeapRegionSize
-XX:G1MixedGCLiveThresholdPercent

  • Parallel Scavenge 垃圾回收器中，默认情况下，并没有一个固定的阈值来决定何时直接在老年代分配大对象。而是由虚拟机根据当前的堆内存情况和历史数据动态决定。

长期存活的对象将进入老年代

大部分情况，对象都会首先在 Eden 区域分配。如果对象在 Eden 出生并经过第一次 Minor GC 后仍然能够存活，并且能被 Survivor 容纳的话，将被移动到 Survivor 空间（s0 或者 s1）中，并将对象年龄设为 1(Eden 区->Survivor 区后对象的初始年龄变为 1)。

对象在 Survivor 中每熬过一次 MinorGC,年龄就增加 1 岁，当它的年龄增加到一定程度（默认为 15 岁），就会被晋升到老年代中。

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

GC 分类

针对 HotSpot VM 的实现，它里面的 GC 其实准确分类只有两大种：

  • 部分收集 (Partial GC)：

    • 新生代收集（Minor GC / Young GC）：只对新生代进行垃圾收集；

    • 老年代收集（Major GC / Old GC）：只对老年代进行垃圾收集。需要注意的是 Major GC 在有的语境中也用于指代整堆收集；

    • 混合收集（Mixed GC）：对整个新生代和部分老年代进行垃圾收集。

  • 整堆收集 (Full GC)：收集整个 Java 堆和方法区。

对象是否可被回收

引用计数算法

原理：给对象添加一个引用计数器，当对象增加一个引用时计数器加 1，引用失效时计数器减 1。引用计数为 0 的对象可被回收。

缺点：两个对象出现循环引用的情况下，此时引用计数器永远不为 0，导致无法对它们进行回收。

可达性分析算法

原理：通过 GC Roots 作为起始点进行搜索，能够到达到的对象都是存活的，不可达的对象可被回收。

image

Java 虚拟机使用可达性分析算法，来判断对象是否可被回收，在 Java 中 GC Root 一般包含以下内容:

  • Java 虚拟机栈中引用的对象

    Java 虚拟栈的栈帧中的局部变量表，例如，各个线程被调用的方法中使用到的参数、局部变量等。

  • 本地方法栈中 JNI 引用的对象

    本地方法栈的栈帧中 JNI（Java Native Interface）引用的对象。

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

    例如，Java 类的引用类型静态变量

  • 方法区中常量引用的对象

    例如，字符串常量池（String Table） 里的引用

  • 所有被同步锁 synchronized 持有的对象

  • Java虚拟机内部的引用

    基本数据类型对应的 Class 对象、一些常驻的异常对象，如：NullPointerException、OutOfMemoryError，系统类加载器。

  • 反映 java 虚拟机内部情况的 JMXBean、JVMTI 中注册的回调、本地代码缓存等

  • 根据用户所选用的垃圾收集器，以及当前回收的内存区域不同，还可能有其他对象“临时性”地加入，共同构成完整 GC Roots 集合。

    例如，分代收集、局部回收（Partial GC）

引用类型

无论是通过引用计算算法判断对象的引用数量，还是通过可达性分析算法判断对象是否可达，判定对象是否可被回收都与引用有关。

Java 具有四种强度不同的引用类型：强引用、软引用、弱引用、虚引用四种（引用强度逐渐减弱）

强引用（StrongReference）

被强引用关联的对象不会被回收。

示例：

Object obj = new Object();

软引用（SoftReference）

被软引用关联的对象只有在内存不够的情况下才会被回收。

示例：

Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);
obj = null;  // 使对象只被软引用关联

弱引用（WeakReference）

被弱引用关联的对象一定会被回收，也就是说它只能存活到下一次垃圾回收发生之前。

示例：

Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);
obj = null;

虚引用（PhantomReference）

又称为幽灵引用或者幻影引用。一个对象是否有虚引用的存在，完全不会对其生存时间构成影响，也无法通过虚引用取得一个对象。

为一个对象设置虚引用关联的唯一目的就是能在这个对象被回收时收到一个系统通知。

示例：

Object obj = new Object();
PhantomReference<Object> pf = new PhantomReference<Object>(obj);
obj = null;

垃圾回收算法

标记-清除算法

将存活的对象进行标记，然后清理掉未被标记的对象。

image

缺点：

  • 标记和清除过程效率都不高；

  • 会产生大量不连续的内存碎片，导致无法给大对象分配内存。

复制

将内存划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了就将还存活的对象复制到另一块上面，然后再把使用过的内存空间进行一次清理。

image

主要不足是只使用了内存的一半。

缺点：

  • 可用内存变小：可用内存缩小为原来的一半。

  • 不适合老年代：如果存活对象数量比较大，复制性能会变得很差。

标记-整理

让所有存活的对象都向一端移动，然后直接清理掉端边界以外的内存。

image

缺点：

  • 由于多了整理这一步，因此效率也不高，适合老年代这种垃圾回收频率不是很高的场景。

分代收集

现在的商业虚拟机采用分代收集算法，它根据对象存活周期将内存划分为几块，不同块采用适当的收集算法。

一般将堆分为新生代和老年代。

  • 新生代使用：复制算法

  • 老年代使用：“标记-清除” 或者“标记-整理”算法

垃圾收集器

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

虽然我们对各个收集器进行比较，但并非要挑选出一个最好的收集器。因为直到现在为止还没有最好的垃圾收集器出现，更加没有万能的垃圾收集器，我们能做的就是根据具体应用场景选择适合自己的垃圾收集器。

Serial 收集器

它是单线程的收集器，只会使用一个线程，以串行的方式进行垃圾收集工作。它在进行垃圾收集工作的时候，必须暂停其他所有的工作线程（ "Stop The World" ）。

Serial 收集器：新生代采用标记-复制算法，老年代采用标记-整理算法。

image

优缺点

  • 优点：由于没有线程交互的开销，因而简单而高效。

  • 缺点：适合内存较小的场景（100ms@10MB~100MB），内存较大时，GC时间会变长。

应用场景

如，分配给虚拟机内存较小的的桌面级应用（Client 模式默认的收集器）

ParNew 收集器

ParNew 收集器其实就是 Serial 收集器的多线程版本，除了使用多线程进行垃圾收集外，其余行为（控制参数、收集算法、回收策略等等）和 Serial 收集器完全一样。

ParNew 收集器：新生代采用标记-复制算法，老年代采用标记-整理算法。

image

Parallel Scavenge 收集器

Parallel Scavenge 收集器也是使用标记-复制算法的多线程收集器。

吞吐量：指 CPU 用于运行用户代码的时间占总时间的比值。

其它收集器关注点是尽可能缩短垃圾收集时用户线程的停顿时间，而 Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量，它被称为 “吞吐量优先” 收集器。

高吞吐量可以高效率地利用 CPU 时间，尽快完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。

Parallel Scavenge 收集器：新生代采用标记-复制算法，老年代采用标记-整理算法。

image

Serial Old 收集器

image

是 Serial 收集器的老年代版本，也是给 Client 模式下的虚拟机使用。

如果用在 Server 模式下，它有两大用途:

  • 在 JDK 1.5 以及之前版本(Parallel Old 诞生以前)中与 Parallel Scavenge 收集器搭配使用。

  • 作为 CMS 收集器的后备预案，在并发收集发生 Concurrent Mode Failure 时使用。

Parallel Old 收集器

image

Parallel Scavenge 收集器的老年代版本。使用多线程和“标记-整理”算法。在注重吞吐量以及 CPU 资源的场合，都可以优先考虑 Parallel Scavenge 收集器和 Parallel Old 收集器。

CMS 收集器

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

CMS 收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

CMS 收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。

image

整个过程分为四个步骤：

  • 初始标记： 暂停所有的其他线程，并记录下直接与 root 相连的对象，速度很快 ；

  • 并发标记： 同时开启 GC 和用户线程，用一个闭包结构去记录可达对象。但在这个阶段结束，这个闭包结构并不能保证包含当前所有的可达对象。因为用户线程可能会不断的更新引用域，所以 GC 线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。

  • 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短

  • 并发清除： 开启用户线程，同时 GC 线程开始对未标记的区域做清扫。

优缺点

  • 优点：

    • 并发收集、低停顿

  • 缺点：

    • 对 CPU 资源敏感；

    • 无法处理浮动垃圾；

    • 它使用的回收算法“标记-清除”算法，会导致收集结束时，会有大量内存碎片产生。

G1 收集器

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

HotSpot 开发团队赋予 G1 收集器的使命是未来可以替换掉 CMS 收集器。从 JDK9 开始，G1 垃圾收集器成为了默认的垃圾收集器。

它具备以下特点：

  • 并行与并发：G1 能充分利用 CPU、多核环境下的硬件优势，使用多个 CPU（CPU 或者 CPU 核心）来缩短 Stop-The-World 停顿时间。部分其他收集器原本需要停顿 Java 线程执行的 GC 动作，G1 收集器仍然可以通过并发的方式让 java 程序继续执行。

  • 分代收集：虽然 G1 可以不需要其他收集器配合就能独立管理整个 GC 堆，但是还是保留了分代的概念。

  • 空间整合：与 CMS 的“标记-清除”算法不同，G1 从整体来看是基于“标记-整理”算法实现的收集器；从局部上来看是基于“标记-复制”算法实现的。

  • 可预测的停顿：这是 G1 相对于 CMS 的另一个大优势，降低停顿时间是 G1 和 CMS 共同的关注点，但 G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为 M 毫秒的时间片段内，消耗在垃圾收集上的时间不得超过 N 毫秒。

G1 收集器的运作大致分为以下几个步骤：

  • 初始标记

  • 并发标记

  • 最终标记

  • 筛选回收

image

G1 收集器在后台维护了一个优先列表，每次根据允许的收集时间，优先选择回收价值最大的 Region(这也就是它的名字 Garbage-First 的由来) 。这种使用 Region 划分内存空间以及有优先级的区域回收方式，保证了 G1 收集器在有限时间内可以尽可能高的收集效率（把内存化整为零）。

ZGC 收集器

ZGC（The Z Garbage Collector）是 JDK 11 中推出的一款低延迟垃圾回收器，它的设计目标包括：

  • 停顿时间不超过 10ms；

  • 停顿时间不会随着堆的大小，或者活跃对象的大小而增加；

  • 支持 8MB~4TB 级别的堆（未来支持 16TB）。

垃圾收集器对比

以前，无论是使用 SerialGC，ParallelGC，还是 CMS，堆的年轻代和老年代都是连续的，且堆结构图都是如下所示：

image

默认的情况下，新生代 ( Young ) 与老年代 ( Old ) 的比例的值为 1:2，其中，Eden : from : to = 8 : 1 : 1

image

JVM 每次只会使用 Eden 和其中的一块 Survivor 区域来为对象服务，所以无论什么时候，总是有一块 Survivor 区域是空闲着的。因此，新生代实际可用的内存空间为 9/10 ( 即90% )的新生代空间。

而G1的堆是基于Region设计的，事实上，这些Region本质上就是Eden、Survivor和Old，而且同类型的Region可以不连续。如下图所示：

image

参考：

posted @ 2023-10-28 10:15  LARRY1024  阅读(87)  评论(0)  编辑  收藏  举报