G1和CMS处理器如何选择和各自的适用场景

G1和CMS如何选择

G1 
最小堆内存 6个G能稳定运行，因此对cpu的要求最少是4核8G
JDK8及更高版本同等环境下只要内存够大(最少8G)优先使用G1
CMS 
CMS追求停顿时间越短越好对cpu性能要求比较高同时对内存要求不算高(最少4G)
JDK8及更高版本同等环境下只要cpu性能比较好并且内存不算大 (最少4G)可以使用CMS
JDK7及更低版本同等环境下 可选择CMS (G1不完善)
注意:单核、双核cpu不适合并发类垃圾收集器，线程频繁来回切换也会比较耗时间，还不如串行垃圾收集器效率高。
 

G1处理器的适用场景

一 面向服务端应用，针对具有大内存、多处理器的机器。

在普通大小的堆里表现并不惊喜。

二 最主要的应用是需要低 GC 延迟，并具有大堆的应用程序提供解决方案。

如：在堆大小约 6GB 或更大时，可预测的暂停时间可以低于 0.5秒；（G1 通过每次只清理一部分而不是全部的 Region 的增量式清理来保证每次 GC 停顿时间不会过长）。

三 用来替换掉 JDK1.5 中的 CMS 收集器，在下面的情况时，使用 G1 可能比 CMS 好。

超过 50% 的 Java 堆被活动数据占用

对象分配频率或年代提升频率变化很大

GC停顿时间过长（长于0.5至1秒）

四 HotSpot 垃圾收集器里，除了 G1 以外，其他的垃圾收集器使用内置的 JVM 线程执行 GC 的多线程操作，而 G1 GC 可以采用应用线程承担后台运行的 GC 工作，即当 JVM 的 GC 线程处理速度慢时，系统会调用应用程序线程帮助加速垃圾回收过程。

CMS收集器的优劣势

优点：

并发收集，低停顿

理由：由于在整个过程和中最耗时的并发标记和 并发清除过程收集器程序都可以和用户线程一起工作，所以总体来说，Cms收集器的内存回收过程是与用户线程一起并发执行的。

缺点：

1、CMS收集器对CPU资源非常敏感

在并发阶段，虽然不会导致用户线程停顿，但是会因为占用了一部分线程使应用程序变慢，总吞吐量会降低，为了解决这种情况，虚拟机提供了一种“增量式并发收集器” 的CMS收集器变种， 就是在并发标记和并发清除的时候让GC线程和用户线程交替运行，尽量减少GC 线程独占资源的时间，这样整个垃圾收集的过程会变长，但是对用户程序的影响会减少。（效果不明显，不推荐）

2、 CMS处理器无法处理浮动垃圾

CMS在并发清理阶段线程还在运行， 伴随着程序的运行自然也会产生新的垃圾，这一部分垃圾产生在标记过程之后，CMS无法再当次过程中处理，所以只有等到下次gc时候在清理掉，这一部分垃圾就称作“浮动垃圾” 。

3、CMS是基于“标记--清除”算法实现的，所以在收集结束的时候会有大量的空间碎片产生。

空间碎片太多的时候，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间来分配当前对象的，只能提前触发 full gc。

为了解决这个问题，CMS提供了一个开关参数，用于在CMS顶不住要进行full gc的时候开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片没有了，但是停顿的时间变长了。