CMS、G1收集器
CMS、G1收集器
1、CMS收集器
CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。优点是并发收集、低停顿。目前很大一部分的Java 应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验。CMS收集器就非常符合这类应用的需求。
1.1、原理
CMS收集器基于“标记—清除”算法实现，整个过程分为四个步骤：
- 初始标记（initial mark）
- 并发标记（concurrent mark）
- 重新标记（remark）
- 并发清除（concurrent sweep）
其中，初始标记、重新标记这两个步骤仍然需要Stop-The-World。初始标记仅仅只是标记一下GC Roots 能直接关联到的对象，速度很快，并发标记阶段就是进行Gc Roots Tracing的过程。而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，所以，从总体上来说，CMS 收集器的内存回收过程是与用户线程一起并发执行的。
1.2、不足
（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时都进行碎片整理）。
2、G1收集器
2.1、特点
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.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停顿时间来制定回收计划。
如果有学到东西，请点赞给予鼓励，谢谢。
