CMS、G1收集器

目录

• CMS、G1收集器
  • 一、CMS收集器
    • 1.一、原理
    • 1.二、不足
  • 二、G1收集器
    • 2.一、特色
    • 2.二、执行过程

CMS、G1收集器

一、CMS收集器

CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。优势是并发收集、低停顿。目前很大一部分的Java 应用集中在互联网站或者B/S系统的服务端上，这类应用尤为重视服务的响应速度，但愿系统停顿时间最短，以给用户带来较好的体验。CMS收集器就很是符合这类应用的需求。

1.一、原理

CMS收集器基于“标记—清除”算法实现，整个过程分为四个步骤：

1. 初始标记（initial mark）
2. 并发标记（concurrent mark）
3. 从新标记（remark）
4. 并发清除（concurrent sweep）

其中，初始标记、从新标记这两个步骤仍然须要Stop-The-World。初始标记仅仅只是标记一下GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行Gc Roots Tracing的过程。而从新标记阶段则是为了修正并发标记期间因用户程序继续运做而致使标记产生变更的那一部分对象的标记记录。因为整个过程当中耗时最长的并发标记和并发清除过程收集器线程均可以与用户线程一块儿工做，因此，从整体上来讲，CMS 收集器的内存回收过程是与用户线程一块儿并发执行的。

1.二、不足

（1）对CPU 资源很是敏感。

其实， 面向并发设计的程序都对 CPU 资源比较敏感。在并发阶段，它虽然不会致使用户线程停顿， 可是会由于占用了一部分线程（或者说 CPU 资源）而致使应用程序变慢，总吞吐量会下降。CMS 默认启动的回收线程数是 (CPU 数量+3) /4, 也就是当 CPU 在 4 个以上时， 并发回收时垃圾收集线程很多于25% 的CPU资源，而且随着 CPU 数量的增长而降低。可是当 CPU 不足4个（好比 2 个）时，CMS 对用户程序的影响就可能变得很大，若是原本CPU负载就比较大，还分出一半的运算能力去执行收集器线程，就可能致使用户程序的执行速度突然下降了 50%，让人没法接受。

（2）没法处理浮动垃圾（Floating Garbage），可能出现“Concurrent Mode Failure”失败而致使另外一次Full GC的产生。

因为CMS并发清理阶段用户线程还在运行着，伴随程序运行天然就还会有新的垃圾不断产生，这一部分垃圾出如今标记过程以后，CMS没法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。也是因为在垃圾收集阶段用户线程还须要运行，那也就还须要预留有足够的内存空间给用户线程使用，所以CMS收集器不能像其余收集器那样等到老年代几乎彻底被填满了再进行收集，须要预留一部分空间提供并发收集时的程序运做使用。

在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，若是在应用中老年代增加不是太快， 能够适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提升触发百分比，以便下降内存回收次数从而获取更好的性能，在JDK1.6中，CMS收集器的启动阈值已经提高至92%。要是CMS运行期间预留的内存没法知足程序须要，就会出现一次 "Concurrent Mode Failure"失败，这时虚拟机将启动后备预案：临时启用SerialOld 收集器来从新进行老年代的垃圾收集，这样停顿时间就很长了。因此说参数-XX:CMSlnitiatingOccupancyFraction设置得过高很容易致使大量"Concurrent Mode Failure" 失败，性能反而下降。

（3）空间碎片的产生。

由于是采用”标记—清除”算法，意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，每每会出现老年代还有很大空间剩余，可是没法找到足够大的连续空间来分配当前对象，不得不提早触发一次Full GC。

为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理的过程是没法并发 的，空间碎片问题没有了，但停顿时间不得不变长。虚拟机设计者还提供了另一个参数-XX:CMSFullGCsBeforeCompaction,这个参数是用于设置执行多少次不压缩的 Full GC后，跟着来一次带压缩的（默认值为0，表示每次进人Full GC时都进行碎片整理）。

二、G1收集器

2.一、特色

G1（Garbage-Firsts，优先处理价值大的内存块）收集器是当今收集器技术发展的最前沿成果之一，而且还在不断发展、完善，与其余GC收集器相比G1具有以下特色：

• 并行与并发：G1能充分利用多CPU、多核环境下的硬件优点，使用多个CPU（CPU 或者CPU核心）来缩短Stop-The-World停顿的时问，部分其余收集器本来须要停顿 Java线程执行的GC动做，G1收集器仍然能够经过并发的方式让JAVA程序继续执行
• 分代收集：与其余收集器同样，分代概念在G1中依然得以保留。虽然G1能够不须要其余收集器配合就能独立管理整个GC堆，但它可以采用不一样的方式去处理新建立的对象和已经存活了一段时间、熬过屡次GC的旧对象以获取更好的收集效果。
• 空间整合：与CMS的“标记一清理”算法不一样，G1从总体来看是基于“标记—整理”算法实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，但不管如何，这两种算法都意味着G1运做期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会由于没法找到连续内存空间而提早触发下一次GC。
• 可预测的停顿：这是G1相对于CMS的另外一大优点，下降停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能创建可预测的停顿时间模型，能让使用者明确指定在一个长度为M亳秒的时间片断内，消耗在垃圾收集上的时间不得超过N亳秒，这几乎已是实时Java(RTSJ)的垃圾收集器的特征了。

在G1以前的其余收集器进行收集的范围都是整个新生代或者老年代，而G1再也不是这样。使用G1收集器时，Java堆的内存布局就与其余收集器有很大差异，它将整个Java堆划分为多个大小相等的独立区域(Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代再也不是物理隔离的了，它们都是一部分Region(不须要连续）的集合。

G1收集器之因此能创建可预测的停顿时间模型，是由于它能够有计划地避免在整个Java堆中进行全区域的垃圾收集。G1 跟踪各个Region里面的垃圾堆积的价值大小（回收所得到的空间大小以及回收所需时间的经验值），在后台维护一个优先列表，每次根据容许的收集时间，优先回收价值最大的Region (这也就是 Garbage-First 名称的来由）。这种使用Region划份内存空间以及有优先级的区域回收方式，使得G1收集器在有限的时间内能够获取尽量高的收集效率。

2.二、执行过程

G1收集器的运做大体可划分为如下几个步骤：

• 初始标记 (Initial Marking)
• 并发标记 (Concurrent Marking)
• 最终标记 (Final Marking)
• 筛选回收 (Live Data Counting and Evacuation)

初始标记阶段仅仅只是标记一下GC Roots能直接关联到的对象，而且修改NTAMS（Next Top at Mark Start）的值，让下一阶段用户程序并发运行时，能在正确可用的Region中建立新对象，这一阶段须要停顿线程，但耗时很短。并发标记阶段是从GC Roots开始对堆中的对象进行可达性分析，找出存活的对象，这一阶段耗时较长，但可与用户程序并发执行。而最终标记阶段是为了修正在并发标记期间因用户程序继续运行而致使标记产生变更的那一部分标记记录，这一阶段须要停顿线程，可是可并行执行。最后在筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据用户所指望的GC停顿时间来制定回收计划。

---

若是有学到东西，请点赞给予鼓励，谢谢。