JVM_7 之 GC基础_2

zheaven
153 阅读6分钟

这是我参与8月更文挑战的第2天，活动详情查看：8月更文挑战

Garbage Collectors

常见的垃圾回收器

1628755815.jpg

  1. 垃圾回收器的发展路线，是随着内存越来越大的过程而演进

    从分代算法演化到不分代算法

    Serial算法 几十兆

    Parallel算法 几个G

    CMS 几十个G - 承上启下，开始并发回收

    .- 三色标记 -

  2. JDK诞生 Serial追随 提高效率，诞生了PS，为了配合CMS，诞生了PN，CMS是1.4版本后期引入，CMS是里程碑式的GC，它开启了并发回收的过程，但是CMS毛病较多，因此目前任何一个JDK版本默认是CMS

    并发垃圾回收是因为无法忍受STW

  3. Serial 年轻代 串行回收

1628756551.jpg

  1. PS 年轻代 并行回收

1628756849.jpg

  1. ParNew 年轻代 配合CMS的并行回收

1628757077.jpg

  1. SerialOld

1628756742.jpg

  1. ParallelOld

1628756988.jpg

  1. ConcurrentMarkSweep 老年代 并发的， 垃圾回收和应用程序同时运行，降低STW的时间(200ms)

    CMS问题比较多，所以现在没有一个版本默认是CMS，只能手工指定

    CMS既然是MarkSweep，就一定会有碎片化的问题，碎片到达一定程度，CMS的老年代分配对象分配不下的时候，使用SerialOld 进行老年代回收 想象一下：

    PS + PO -> 加内存 换垃圾回收器 -> PN + CMS + SerialOld（几个小时 - 几天的STW）

    几十个G的内存，单线程回收 -> G1 + FGC 几十个G -> 上T内存的服务器 ZGC

    算法：三色标记 + Incremental Update

  2. G1(200ms - 10ms)

    算法：三色标记 + SATB

  3. ZGC (10ms - 1ms) PK C++

    算法：ColoredPointers + LoadBarrier

  4. Shenandoah

    算法：ColoredPointers + WriteBarrier

  5. Eplison(jdk11开始debug使用)

  6. PS 和 PN区别的延伸阅读：ParNew 响应时间优先，配合CMS；PS吞吐量优先

  7. 垃圾收集器跟内存大小的关系

    1. Serial 几十兆
    2. PS 上百兆 - 几个G
    3. CMS - 20G
    4. G1 - 上百G (jdk1.8存在，1.9默认)
    5. ZGC - 4T - 16T（JDK13）

jdk 1.8 默认的垃圾回收：PS + ParallelOld

CMS

  • concurrent mark sweep
  • a mostly concurrent, low-pause collector
  • 4 phases
    • initial mark
    • concurrent mark
    • remark
    • concurrent sweep

1628757822.jpg

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体 验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程 （基本上）同时工作。 从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。

整个过程分为四个步骤：

  • 初始标记： 暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。
  • 并发标记： 并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程， 这个过程耗时较长但 是不需要停顿用户线程， 可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。
  • 重新标记： 重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对 象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三 色标记里的增量更新算法(见下面详解)做重新标记。
  • 并发清理： 开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑 色不做任何处理(见下面三色标记算法详解)。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。

但是它有下面几个明显的缺点：

  • 对CPU资源敏感（会和服务抢资源）；
  • 无法处理浮动垃圾(在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；
  • 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数- XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理
  • 执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是**"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收**
  • PromotionFailed：老年代没有空间装下新的大对象

如何减少CMS出现问题的概率

解决方案：降低触发CMS的阈值，保持老年代有足够的空间

-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比） 降低该值，提高Promotion的空间，增加浮动垃圾可利用空间，让回收垃圾的同时能有对象可以进入老年代，避免老年代空间不足

CMS的相关核心参数

  1. -XX:+UseConcMarkSweepGC：启用cms
  2. -XX:ConcGCThreads：并发的GC线程数
  3. -XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）
  4. -XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一 次
  5. -XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）
  6. -XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设 定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整
  7. -XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引 用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段
  8. -XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW
  9. -XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

常见垃圾回收器组合参数设定：(1.8)

  • -XX:+UseSerialGC = Serial New (DefNew) + Serial Old
    • 小型程序。默认情况下不会是这种选项，HotSpot会根据计算及配置和JDK版本自动选择收集器
  • -XX:+UseParNewGC = ParNew + SerialOld
  • -XX:+UseConc(urrent)MarkSweepGC = ParNew + CMS + Serial Old
  • -XX:+UseParallelGC = Parallel Scavenge + Parallel Old (1.8默认) 【PS + SerialOld】
  • -XX:+UseParallelOldGC = Parallel Scavenge + Parallel Old
  • -XX:+UseG1GC = G1
  • Linux中没找到默认GC的查看方法，而windows中会打印UseParallelGC
    • java +XX:+PrintCommandLineFlags -version
    • 通过GC的日志来分辨
  • Linux下1.8版本默认的垃圾回收器到底是什么？
    • 1.8.0_181 默认（看不出来）Copy MarkCompact
    • 1.8.0_222 默认 PS + PO
avatar
文章
阅读
粉丝