JVM学习之:GC的算法的具体实现(垃圾收集器)

在 JVM学习之:GC的算法简述 这篇博客中提到了各种各样的垃圾算法,由于java屏蔽掉了程序员对内存的管理,其根据这些算法的特点实现了很多的的垃圾收集器,每个垃圾收集器都有自己的优点,使用场合,当然也有各自的缺点,所以在实际的应用中往往会更具应用的特点选择不同的垃圾收集器来组合使用,目前还没有一款"万能通"的收集器能应用在所有的场合,为了能够更好的熟悉这些收集器,对常用的垃圾收集器做一下总结,如下图

如果两个收集器之间有实线链接表明两个收集器可以一起使用,每个收集器的特点从https://blogs.oracle.com/jonthecollector/entry/our_collectors可以找到介绍,本人添加了一些中文的描述

"Serial" is a stop-the-world, copying collector which uses a single GC thread.
特点:虽然说他是stop the word,而且是单线程的,但是到目前为止,它任然是虚拟机运行在client模式下的默认年轻代的收集器
优点:由于单线程而简单高效,对于单处理器的情况下是个不错的选择

"ParNew" is a stop-the-world, copying collector which uses multiple GC threads. It differsfrom "Parallel Scavenge" in that it has enhancements that make it usable with CMS. For example, "ParNew" does the synchronization needed so that it can run during the concurrent phases of CMS.
特点:(1)运行在server模式下虚拟机的首选年轻代收集器
(2)对于单处理器的环境下,由于多个收集器线程之间的切换也会带来一定的开销,所以该收集器的效率不一定会比Serial效率高
(3)默认的情况下,开启的线程数和处理器的数量相等
参数: 可以通过-XX:ParalleLGCThreads来限制垃圾收集器线程的数量

"Parallel Scavenge" is a stop-the-world, copying collector which uses multiple GC threads.
特点:(1)其他收集器关注点是尽可能的缩短因为收集线程的运行而导致用户线程的停顿时间,而该收集器的参考指标是吞吐量(吞吐量=用户代码运行时间/用户代码运行时间+GC时间)
(2)收集器的高吞吐量表明对CPU的利用率比较高,尽快的完成程序的运算任务,适用于ＣＰＵ密集型的操作，不适合有太多交互的操作
(3)
参数:－XX:MaxGCPauseMills　最大垃圾收集停顿时间,
--XX:GCTimerRatio 吞吐量的倒数
-XX:+UseadaptivesizePolicy 开启虚拟机的自适应调整策略,该参数为Parallel Scavenge收集器特有

"Serial Old" is a stop-the-world,mark-sweep-compact collector that uses a single GC thread.
特点:(1)主要用在虚拟机的Client模式下
(2) 如果用在虚拟机的Server模式下主要用来和Parallel Scavenge搭配使用,以及作为CMS的backup

"Parallel Old" is a compacting collector that uses multiple GC threads.
特点:(1)从jdk1.6才开始被使用,在此之前由于Parallel Scavenge与CMS有这不同的实现结构,所以只能和Serial Old搭配使用,但是由于Serial Old是单线程的,如果在Server模式下的话,会导致Old Generation区的回收效率问题,所以Effective(Parallel Scavenge+Serial Old)<Effective(parNew+CMS),所以在此之前Parallel Scavenge的处境比较尴尬
(2)在注重吞吐量以及Cpu利用率的场合可以优先考虑使用Parallel Scavenge+Parallel Old
说的

"CMS(Concurrent mark Sweep)" is a mostly concurrent, low-pause collector.
特点:(1)对Old Generation的并发收集
(2)非常重视交互的响应性,例如互联网的网站等B/S系统服务器
(3)该收集器对比与前面的几种收集器更为复杂,其工作的过程大概分为四个阶段 一:初始标记 二:并发标记 三:重新标记 四:并发清楚,其中步骤一和三会要求Stop the world,而步骤二和四可以和用户线程一起工作.消耗时间的大小顺序为 一<三<二<四
缺点:(1)对于CPU资源非常敏感,CMS默认启动的收集器线程数是(CPU数量+3)/4,当CPU大于4时,垃圾收集线程最多占用不超过25%的cpu资源,但是当CPU数小于4时,那么CPU的可能就要有一半的资源在垃圾收集上,为了解决这种问题提供了一种i-CMS的解决方案
(2)无法处理浮动垃圾,可能出现"Concurrent Mode Failure"而导致另外一次Full GC的产生.在默认的情况下当老年区使用了６８％以上时就会触发ＧＭＳ垃圾回收，这个参数可以通过－ＸＸ:CMSInitiatingOccupancyFraction来设置这个触发的值,这个参数设的过低会导致频繁的发生垃圾回收造成资源的浪费,如果设的太高,那么浮动垃圾占用了大量old generation,而导致用户程序没有足够的内存空间去运行,于是就出现了Concurrent Mode Failure,出现Concurrent Mode Failure时,虚拟机会使用ＣＭＳ的backupSerial Old作为old generation的回收器
(3)由于用的Mark-Sweep算法,所以运行期间会有大量的内存碎片产生.为了解决这个问题可以通过使用-XX:+UseCMSCompactAtFullCollection来让虚拟机在昨晚FUll Gc后做一次碎片整理工作(STOP the world),碎片的整理需要时间,所以设置这个参数后会导致停顿时间的加长,为此Sun又提供了一个参数(-XX:ＣＭＳＦｕｌｌＧＣsＣｏｍｐａｃｔｉｏｎ)用来设置当执行完多次的非压缩Full GC后,做一个带压缩的FUll GC

G1:will be supported in jdk 7.0

下面提供了一些虚拟机参数用来设置虚拟机使用那些收集器:

Using the -XX flags for our collectors for jdk6,

UseSerialGC is "Serial" + "Serial Old"

UseParNewGC is "ParNew" + "Serial Old"

UseConcMarkSweepGC is "ParNew" + "CMS" + "Serial Old". "CMS" is used most of the time to collect the tenured generation. "Serial Old" is used when a concurrent mode failure occurs.

UseParallelGC is "Parallel Scavenge" + "Serial Old"

UseParallelOldGC is "Parallel Scavenge" + "Parallel Old"

还有一些关于收集器的FAQ请参见:https://blogs.oracle.com/jonthecollector/entry/our_collectors