3.垃圾收集

阿-牛

已于 2022-05-23 23:50:12 修改

阅读量298

点赞数

分类专栏： JVM 文章标签： java 开发语言

于 2022-05-23 23:35:17 首次发布

本文链接：https://blog.csdn.net/u012267926/article/details/124920333

版权

JVM 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

垃圾收集算法-方法论

我们常用的垃圾收集器都是有方法论作为基础的，具体包含如下：复制算法、标记清除、标记整理、分代收集理论。

复制算法

将一块空间平均分成两份，处理东西的只是在其中一块区域，当垃圾回收时，存活的对象移动到另一块区域，并清空当前区域。

弊端：

空间会损失一半，毕竟只有一半空间可用。

标记清除

弊端：

效率问题（如果需要标记的对象太多，效率不高）
空间问题（导致空间不连续）

标记整理

大体上与标记清除差不多，只是最后存活的对象会对齐到一边，剩下的空间均是连续的可用空间。

分代收集理论

该理论只要是针对年轻代与老年代特色，来分别使用不同的收集算法。例如：年轻代的对象大都朝生夕死所以采用复制算法，因为存活的对象很少，复制成本比较低。而老年代对象存活时间长，只适合用标记清除或标记整理算法（该两中算法比复制算法慢10倍以上）。

垃圾收集器-实现

串性收集器-Serial

顾名思义：只有一条线程进行垃圾回收（STW），且回收过程中，任何用户应用线程无法执行。

配置参数如下：

-XX:+UseSerialGC

Enables the use of the serial garbage collector. This is generally the best choice for small and simple applications that do not require any special functionality from garbage collection. By default, this option is disabled and the collector is chosen automatically based on the configuration of the machine and type of the JVM.

备注：-XX:+UseSerialOldGC老年代串行收集器在jdk1.5及之前可与Parallel Scavenge收集器使用，或作为CMS收集器的候选方案（目前官网中已经没有该参数设置了）

并发收集器-Parallel

该收集器主要特色是垃圾回收时是多线程运行，与串行收集器相比更加注重吞吐量（高效利用cpu：cpu中用于运行用户代码的时间与cpu总消耗的时间比值)，默认收集线程数与cpu核数相同

配置参数：

-XX:ParallelGCThreads=线程

设置年轻代和老年代用于并行垃圾回收的线程数。默认值取决于 JVM 可用的 CPU 数量。

例如，要将并行 GC 的线程数设置为 2，请指定以下选项：

-XX:ParallelGCThreads=2

-XX:+UseParallelGC

允许使用并行清除垃圾收集器（也称为吞吐量收集器），通过利用多个处理器来提高应用程序的性能。

默认情况下，禁用此选项，并根据机器的配置和 JVM 的类型自动选择收集器。如果已启用，则该-XX:+UseParallelOldGC选项将自动启用，除非您明确禁用它。

-XX:+UseParallelOldGC

为完整 GC 启用并行垃圾收集器。默认情况下，此选项被禁用。启用它会自动启用该-XX:+UseParallelGC选项。

ParNew收集器

与Parallel收集器类似，区别是他能搭配CMS收集器。新生代采用复制算法，老年代采用标记整理算法。

参数如下：

-XX:+UseParNewGC

启用在年轻代中使用并行线程进行收集。默认情况下，此选项被禁用。-XX:+UseConcMarkSweepGC当您设置该选项时，它会自动启用。在 JDK 8 中不推荐使用不带选项的-XX:+UseParNewGC选项。-XX:+UseConcMarkSweepGC

并发标记清除收集器-CMS

Concurent Mark Sweep:主要目标是缩短停顿时间，提升用户体验。让用户线程与垃圾手机线程同时工作。

初始标记：仅记录下GC root的一级引用，其后的触达对象不统计（单线程收集，STW,但是速度很快）。
并发标记：统计GC root一级引用关联的其它触达对象（用户线程与垃圾回收线程同时运行，会导致标记的对象状态可能发生变化）
重新标记：STW,仅垃圾回收线程运行。对并发标记的状态进行修正。主要用到三色标记里的增量更新算法。
并发清理：用户线程与垃圾回收线程同时运行。此阶段有新增对象不会被清理。（三色标记理论）
并发重置：重置本次GC过程中标记的数据

缺点：

争抢资源，垃圾收集与用户线程互相争夺
产生浮动垃圾，并发标记与并发清理阶段如果产生垃圾，只能下次垃圾回收时才能清理
使用标记-清除算法，会导致空间碎片化产生，可通过参数：-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理。（TODO:该参数jdk中已经不存在）
可能出现垃圾回收失败的情况，例如并发阶段，再次产生对象，空间不足进行垃圾回收。会发生“concurrent mode failure”，此时会STW,用serial old垃圾收集器来回收

参数配置：

-XX:+UseConcMarkSweepGC

为老年代启用 CMS 垃圾收集器。-XX:+UseParallelGC当吞吐量 ( ) 垃圾收集器无法满足应用程序延迟要求时，Oracle 建议您使用 CMS 垃圾收集器。G1 垃圾收集器 ( -XX:+UseG1GC) 是另一种选择。

默认情况下，禁用此选项，并根据机器的配置和 JVM 的类型自动选择收集器。启用此选项后，该-XX:+UseParNewGC选项会自动设置，您不应禁用它，因为以下选项组合在 JDK 8 中已被弃用：-XX:+UseConcMarkSweepGC -XX:-UseParNewGC.

-XX:ConcGCThreads: 设置用于并发 GC 的线程数。默认值取决于 JVM 可用的 CPU 数量。

注：jdk8中已经摒弃掉标记清除后在整理的过程了（猜测是目前内存越来越大，老年代又是不容易被回收的地方，所以复制移动的成本太大了）

-XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection

Java HotSpot(TM) 64-Bit Server VM warning: UseCMSCompactAtFullCollection is deprecated and will likely be removed in a future release.


/*

java version "1.8.0_291"
Java(TM) SE Runtime Environment (build 1.8.0_291-b10)
Java HotSpot(TM) 64-Bit Server VM (build 25.291-b10, mixed mode)

*/

三色标记

增量更新：假如A节点已经是黑色，但是突然A又新增了一个引用到M,那么该引用会被记录下来，待重新标记阶段，从新扫描这些被记录的引用。既重新扫描A.

原始快照：假如B删除了对应D的引用，那么该操作会被记录下来，待并发标记之后就会重新扫描这些记录。此时从B下面能扫到D,此时D被标记为黑色，代表此轮不清理。（可能产生浮动垃圾）

G1

特点：该收集器将堆内存划分成等大小的小格子，这些小格子代表了Eden、Survivor、Old、Humongous(存放临时大对象)、未使用等五种区域，且每个小格子所代表的“角色”区域会发生替换。或许此刻是年轻代，但是在垃圾回收后，下一次就变成了老年代。

JVM最多有2048个Region(区域)，则每个区域的大小为堆总大小/2048; 但是每个区域大小不能超过32M，且是2的倍数。
-XX:MaxGCPauseMillis=时间(毫秒)来控制垃圾收集的停顿时间
筛选回收垃圾阶段，收集器会根据用户设定的停顿时间，来预判成本。即扫描那些region,以及回收那个region的效益高。例如：region总大小为10M,其中一个区域放了5M,N个放了1M,回收M个1M的效益肯定高于一个5M的。（即G1维护的优先列表）
采用复制的方式，进行垃圾回收。
建议堆内存6G+,停顿时间在0.5秒内的机器
采用快照模式（三色标记），可能由于如果使用增量更新，那么会重新扫描标记的节点，这个对于内存大，region多的情况，效率可能比较低。

如何查看JDK默认收集器

1.添加参数：-XX:+PrintCommandLineFlags

阿-牛

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
3.垃圾收集

垃圾收集算法-方法论我们常用的垃圾收集器都是有方法论作为基础的，具体包含如下：复制算法、标记清除、标记整理、分代收集理论。复制算法将一块空间平均分成两份，处理东西的只是在其中一块区域，当垃圾回收时，存活的对象移动到另一块区域，并清空当前区域标记清除标记整理分代收集理论垃圾收集器-实现串性收集器-Serial并发收集器-Parallel并发标记清除收集器-CMSG1ZGC...
复制链接

扫一扫