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的时候开启内存碎片的合并整理过程,内存整理的过程是无法并发的,空间碎片没有了,但是停顿的时间变长了。