JVM 垃圾收集器ParNew&CMS

最新推荐文章于 2024-01-10 23:10:49 发布

不爱学习的cyy

最新推荐文章于 2024-01-10 23:10:49 发布

阅读量512

点赞数

分类专栏： JVM 文章标签： jvm java

本文链接：https://blog.csdn.net/cyy15280752410/article/details/128280150

版权

JVM 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

一、垃圾收集算法

分代收集理论

分代收集算法将内存分为新生代和老年代，新生代又分为：Eden区（占80%）和两块Survivor区(各占10%)，刚刚创建的对象存放在新生代的Eden区。

因为绝大多数的对象（98%）都是朝生夕死的，当Eden区没有足够的空间的时候JVM会发起一次Minor Gc，存活对象会进入其中的一块Suvivor区，Eden区被清空，如果Suvivor区内存不够则直接进入老年代。下一次Minor Gc会将Eden和该Suvivor区的存活对象复制到另一块Suvivor区，并将Eden区和该Suvivor区清空。

为什么需要Survivor区？

如果没有Survior区，每次进行Minor Gc，存活的对象直接进入老年代，老年代内存被占满会发生Major Gc, Full Gc执行的速度比Minor Gc慢十倍以上，当有了Survivor区，存活的对象在两块Survior区中倒腾，在新生代存活了一定次数的对象（通过参数可以配置），才会被放入老年代。这样就减少了Full Gc发生的频率。

为什么需要两块Survivor区？

为了避免内存碎片化的问题，想想复制算法是如何解决标记清除算法的内存碎片化问题的，将内存分为大小相等的两块，将存活的对象复制到另一块内存，这里也是一样的道理。

老年代的对象存活几率是比较高的，而且没有额外的空间对它进行分配担保，所以我们必须选择“标记-清除”或“标记-整理”算法进行垃圾收集。

注意，“标记-清除”或“标记-整理”算法会比复制算法慢10倍以上。

标记-复制算法

将内存分为大小相同的两块，每次使用其中的一块。当这一块的内存使用完后，就将还存活的对象复制到另一块去，然后再把使用的空间一次清理掉。这样就使每次的内存回收都是对内存区间的一半进行回收

标记-清除算法

分为“标记”和“清除”阶段：标记存活的对象，统一回收所有未被标记的对象(一般选择这种)；也可以标记出所有需要回收的对象，在标记完成后统一回收所有被标记的对象

存在的问题：

1. 效率问题 (如果需要标记的对象太多，效率不高)
2. 空间问题（标记清除后会产生大量不连续的碎片）

标记-整理算法

根据老年代的特点出的一种标记算法，标记过程与“标记-清除”算法一样，但不直接对可回收对象回收，而是让所有存活的对象向一端移动，然后直接清理掉边界以外的内存。

二、垃圾收集器

1、Serial收集器

年轻代：-XX:+UserSerialGC

老年代：-XX:+UserSerialOldGC

Serial（串行）收集器是一个单线程收集器，它在进行垃圾收集工作的时候必须暂停其他所有的工作线程（ "Stop The World" ），直到它收集结束

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

Serial Old收集器是Serial收集器的老年代版本，也是一个单线程收集器。

它主要有两大用途：

1. 一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用，
2. 一种用途是作为CMS收集器的后备方案

2、Parallel Scavenge收集器

年轻代：-XX:+UseParallelGC

老年代：-XX:+UserParalleOldGC

Parallel收集器是Serial收集器的多线程版本，默认的收集线程数跟cpu核数相同，也可以用参数(-XX:ParallelGCThreads)指定收集线程数，一般不推荐修改。

Parallel Scavenge收集器关注点是吞吐量（高效率的利用CPU）。

CMS等垃圾收集器的关注点更多的是用户线程的停顿时间（提高用户体验）。

所谓吞吐量就是CPU中用于运行用户代码的时间与CPU总消耗时间的比值。

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

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

3、ParNew收集器

-XX:+UserParNewGC

ParNew收集器跟Parallel收集器很类似，主要区别在于它可以和CMS收集器配合使用。

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

4、CMS收集器

-XX:+UserConcMarkSweepGC

老年代使用CMS收集器，年轻代搭配ParNew收集器

CMS（Concurrent Mark Sweep）是一种 “标记-清除”算法实现的

CMS运作过程

初始标记

暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快。

并发标记

并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。由于用户线程继续运行，可能会有导致已经标记过的对象状态发生改变

重新标记

修正并发标记期间因为用户线程继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，但比并发标记阶段时间短。主要用到三色标记里的增量更新算法做重新标记。

并发清理

开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理

并发重置

重置本次GC过程中的标记数据

在一次gc，STW的时间并没有缩短，但是分很多次间隔的执行。STW被拆分多次，用户体验比较好。

浮动垃圾：例如并发清理阶段，清理某个区域的对象时，又在另一个区域中new 对象，只能等下一次gc。应用程序和垃圾回收同时执行就会产生浮动垃圾

优点：并发收集、低停顿

缺点：

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

CMS的相关核心参数

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

三、三色标记

在并发标记的过程中，因为标记期间用户线程还在继续运行，对象间的引用可能发生变化，多标和漏标的情况就有可能发生

黑色：表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。
灰色：表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。
白色：表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

多标-浮动垃圾

在并发标记过程中，由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过(被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

漏标-读写屏障

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案： 增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

增量更新

是当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为， 黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。

原始快照

当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。