CMS、G1垃圾收集器详解

CMS垃圾收集器

基本上只能用在老年代，很长一段时间是ParNew(新生代)搭配CMS(老年代)来使用的。

收集过程大概会分为如下4个过程：

1、初始标记：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快；会stop the world。

2、并发标记：同时开启GC和用户线程，将GcRoot根下面所有的引用对象找出来。因为用户线程可能会不断的更新引用域，所以GC线程无法保证可达性分析的实时性。所以这个算法里会跟踪记录这些发生引用更新的地方。不会STW (类似于将初始标记下面的所有可达的对象找出来，因为这个时间可能比较长，stw时间就比较长，为了用户体验所以这里没有stw)。

3、重新标记：重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短 STW (类似于将并发标记产生的可达对象重新标记) 底层采用三色标记算法扫描堆。

4、并发清理：开启用户线程，同时GC线程开始对未标记的区域做清扫。不会STW 如果并发清理过程中又出来垃圾三色标记为黑色变成浮动垃圾，下一次在清理。

5、并发重置: 将本次所有打标的对象标志去掉。

优点：并发收集、低停顿(stw时间短)。

缺点： 1. 因为是多线程会抢占CPU资源

2. 无法处理浮动垃圾(在并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

3. 它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection 可以让jvm在执行完标记清除后再做整理

4. 会出现如果本次full gc 还没有处理完后面线程产生的垃圾又触发full gc 此时，也就是"concurrent mode failure"(并发失败)，此时所有的并发部分直接会stop the world，用serial old垃圾收集器来回收(也就是单线程收集) (特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，)

CMS垃圾收集器参数可以调整不用每一次full gc都去做一次碎片整理可以设置5次full gc后在做一次碎片整理

CMS的相关参数: 可以解决4 并发失败的问题 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%都在remark阶段

对于碎片整理，因为都是1小时或几小时才做一次FullGC，是可以每做完一次就开始碎片整理。综上，只要年轻代参数设置合理，老年代CMS的参数设置基本都可以用默认值，如下所示： 1 ‐Xms3072M ‐Xmx3072M ‐Xmn2048M ‐Xss1M ‐XX:PermSize=256M ‐XX:MaxPermSize=256M ‐XX:SurvivorRatio=8 2 ‐XX:MaxTenuringThreshold=5 ‐XX:PretenureSizeThreshold=1M ‐XX:+UseParNewGC ‐XX:+UseConcMarkSweepGC 3 ‐XX:CMSInitiatingOccupancyFaction=92 ‐XX:+UseCMSCompactAtFullCollection ‐XX:CMSFullGCsBeforeCompaction=0

目前jdk8的版本-xx开头的参数可以用但是在jdk9里面-xx参数如果使用会报一个过时的警告但是还可以用 jdk9默认使用的是G1垃圾回收器。

G1垃圾收集器

其实G1垃圾收集器和CMS过程基本上很像

G1收集器一次GC的运作过程大致分为以下几个步骤：

初始标记（initial mark，STW）：暂停所有的其他线程，并记录下gc roots直接能引用的对象，速度很快；

并发标记（Concurrent Marking）：同CMS的并发标记

最终标记（Remark，STW）：同CMS的重新标记

筛选回收（Cleanup，STW）：筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间(可以用JVM参数 -XX:MaxGCPauseMillis指定)来制定回收计划，会stw。

只不过在G1里面会突出一个region的概念。

就是eden区和old区模糊化了，它将Java堆内存划分为多个大小相等的独立区域（Region），JVM最多可以有2048个Region,G1保留了年轻代和老年代的概念，但是只是逻辑上的概念了,但不再是物理隔阂了，它们都是（可以不连续）Region的集合。默认年轻代对堆内存的占比是5%，如果堆大小为4096M，那么年轻代占据200MB左右的内存，对应大概是100个Region，，在系统运行中，JVM会不停的给年轻代增加更多的Region，但是最多新生代的占比不会超过60%，一个Region可能之前是年轻代，如果Region进行了垃圾回收，之后可能又会变成老年代，也就是说Region的区域功能可能会动态变化。

假如JVM划分为1000个region 年轻代还是8:1:1

G1垃圾收集器对于对象什么时候会转移到老年代跟之前讲过的原则一样(jvm内存分配策略)，唯一不同的是对大对象的处理，G1有专门分配大对象的Region叫Humongous区，而不是让大对象直接进入老年代的 Region中。在G1中，大对象的判定规则就是一个大对象超过了一个Region大小的50%，比如按照上面算的，每个Region是2M，只要一个大对象超过了1M，就会被放入Humongous中，而且一个大对象如果太大，可能会横跨多个Region来存放。

G1还有一个特点就是用户在使用的过程中可以自定义stw的时间。

这边分析了一下可以自定义stw时间的好处：可停顿时间假如设置停顿时间为1s,但是1s只能回收80%的垃圾剩下的下次再回收,而且G1在底层还维护了一个优先表(内部事先计算好每一个region回收时间进行排序),比如一个region回收花费了200ms,另外一个region回收花费50ms,在回收情况有限的情况下,优先回收时间短的,主要就保证了在有限的时间内,回收的效率最高。

CMS和G1有什么相同点和不同点？

CMS和G1在初始标记并发标记 (重新标记CMS)最终标记(G1) 相同但是CMS最后是并发清里(标记-清理算法) 而G1筛选回收用户可以指定回收时间而且回收算法是复制算法

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

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

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

可预测的停顿：这是G1相对于CMS的另一个大优势，降低停顿时间是G1 和 CMS 共同的关注点，但G1 除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段(通过参数"-XX:MaxGCPauseMillis"指定)内完成垃圾收集。

通过对比我们知道CMS和G1都有各自的优势，那么在实际中我们应该怎么选择呢？下一篇文章我们将继续。