深入理解Java虚拟机-3.3 垃圾收集算法- 高飞网

3.3 垃圾收集算法

2016-03-01 09:49:19.0

垃圾收集算法

    由于垃圾收集算法的实现涉及大量的程序细节,而且各个平台的虚拟机操作内存的方法各不相同,,因此本节不打算过多地讨论算法的实现,只是介绍几种算法的思想及其发展过程。


标记-清除算法(Mark-Sweep)

    首选标记出所有需要回收的对象,在标记完成后统一回收所有被标记的对象。
    不足:1)效率问题:标记和清除两个过程的效率都不高;2)空间问题:标记清除之后会产生大量不连续的内存碎片,空间碎片太多可能会导致以后在程序运行过程中需要分配较大对象时,无法找到足够的连续内存而不得不提前触发另一次垃圾收集动作。


复制算法(Copying)

    复制算法将可用内存按容量划分为大小相等的两块,每次只使用其中的一块。当这块内存用完了,就将还存活着的对象复制到另外一块上面,然后再把已使用的内存空间一次清理掉。这样使得每次都是对整个半区进行内存回收,内存分配时也就不用考虑内存碎片等复杂情况,只要移动堆顶指针,按顺序分配内存即可。实现简单,运行高效。

    不足是将内存缩小原来的一半。


    现在商业虚拟机都采用这种收集算法来回收新生代。IBM公司的专门研究表明,新生代中的对象98%是“朝生夕死”的,所以并不需要按照1:1比较来划分内存空间,而是将内存分为一块较大的Eden空间和两块较小的Survivor空间,每次使用Eden和其中一块Survivor。当加收时,将Eden和Suvivor中还存活着的对象一次性地复制到另外一块Survivor空间上,最后清理掉Eden和刚才用过的Survivor空间。Hotspot虚拟机默认Eden和Survivor大小比例是8:1,也即每次新生代中可用内存空间为整个新生代容量的90%(80%+10%),只有10%的内存会被“浪费”。当前98%的对象可回收只是一般场景下的数据,没办法每次回收都只有不多于10%的对象存活,当Survivor空间不够用时,需要依赖其他内存(老年代)进行分配担保(Handle Promotion)。
    为什么会有两个survivor?为什么新生代有两个survivor? - Pandoras Box - 博客频道 - CSDN.NET


标记-整理算法(Mark-Compact)

    复制收集算法在对象存活率较高时就要进行较多的复制,效率会变低。而且它需要分配担保,因此老年代对象不直接先用这种算法。

    标记整理算法,过程仍然是先标记,而后让所有存活的对象都向一端,最后直接清理掉边界以外的内存。



分代收集算法(Generational Collection)

    根据对象存活周期的不同将内存划分为几块。一般是把Java堆分为新生代和老年代,这样就可以根据各个年代的特点采用适当的收集算法。在新生代中,每次垃圾收集时都发现有大批对象死去,只有少量存活,先用复制算法,哈哈需付出少量存活对象的复制成本就可以完成收集。而老年代中因为对象存活率高、没有额外空间对它进行分配担保,就必须使用“标记-清理”或“标记-整理”算法进行回收。


垃圾收集器

    如果说收集算法是内存回收的方法论,那么垃圾收集器就是内存回收的具体实现。下面基于JDK1.7 Update14之后的HotSpot虚拟机的垃圾收集器实现。

    上图中,两个收集器间的连线表示两个收集器可以配合使用,所在的区域表示它属于新生代收集器还是老年代收集器。


Serial收集器

    Serial收集器是最基本、发展历史最悠久的收集器,曾经是虚拟机新生代收集器的唯一选择。它是一个单线程收集器,不仅仅是它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。它使用Coping(复制)算法。

    到现在为止,Serial收集器依然是虚拟机运行在Client模式下的默认新生代收集器。优点是简单高效,对于限定单CPU的环境来说,Serial收集器由于没有线程交互开销,分配给虚拟机管理的内存一般来说不会很大,收集几十兆甚至一两百兆的新生代,停顿时间完全可以控制在几十毫秒最大一百多毫秒以内,只要不是频繁发生,是可以接受的。


ParNew收集器

    ParNew收集器是Serial收集器的多线程版本,是许多运行在Server模式下的虚拟机中首选的新生代收集器。其中一个与性能无关但很重要的原因是,除了Serial收集器外,目前只有它能与CMS收集器配合工作。在JDK1.5时期,HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器——CMS收集器(Concurrent Mark Sweep),这是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作。

    不幸的是,CMS作为老年代的收集器,却无法与JDK1.4.0中已经存在的新生代收集器Parallel Scavenger配合工作,所以在JDK1.5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器中的一个。ParNew收集器也是使用-XX:+UseConcMarkSweepGC选择后默认新生代收集器,也可以使用-XX:+UseParNewGC选项来强制指定它。

    PerNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果,甚至由于存在线程交互的开销,该收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百的保证可以超越Serial收集器。当然,随着可以使用的CPU的数量的增加,它对于GC时系统资源的有效利用还是很有好处的。它默认开启的收集线程数与CPU的数量相等,在CPU非常多的环境下,可以使用-XX:ParllelGCThreads参数来限制垃圾收集的线程数。

    从ParNew收集器开始,后面还会接触到几款并发和并行的收集器,并行与并发的不同是:
    并行(Parallel):指多条垃圾收集线程并行工作,但此时用户线程仍处于等待状态。
    并发(Concurrent):指用户线程与垃圾收集线程同时执行,用户程序在继续运行,而垃圾收集程序运行在另一个CPU上。

    与Serial收集器一样,采用(Coping)复制算法


Parallel Scavenge收集器

    Parallel Scavenge收集器是一个新生代收集器,也是使用复制算法的收集器,并行的多线程收集器。

    Parallel Scavenge收集器关注点与其他收集器不同,CMS等收集器关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge收集器的目标则是达到一个可控的吞吐量(Throughput)。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),虚拟机总共运行了100分钟,其中垃圾收集花掉1分钟,那吞吐量就是99%。

    停顿时间越短(CMS)就越适合需要与用户交互的程序,良好的响应速度能提升用户体验;而高吞吐量则可以高效率地利用CPU时间,尽快完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务

    Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPasueMillis参数,以及直接设置吞吐量大小的-XX:GCTimeRatio参数。

    由于与吞吐量关系密切,Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。除上两个参数外,它还有一个参数-XX:UseAdaptiveSizePolicy,这是个开头参数,打开以后,就不需要手工设置新生代大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenurSizeThreshold)等参数了,虚拟机会根据当前系统的运行情况收集监控信息,动态调整这些参数提供最合适的停顿或最大的吞吐量,这种调节称为GC自适应策略(GC Ergonomics)。这也是它与ParNew收集器一个重要的区别。


Serial Old收集器

    Serial Old收集器是Serial收集器的老年代版本,它同样是一个单线程收集器,使用“标记-整理”算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下,它还有两大用途:一种用途是在JDK1.5以及以前的版本中与Parallel Scavenge收集器搭配使用,另一种是作以CMS收集器的后备预案,在并发收集发生Concurrent Mode Failure时使用。

    ParNew收集器与Serial收集器使用的算法相同,即Coping(复制)算法。


Parallel Old收集器

    Parallel Old是Parallel Scavenge收集器的老年代版本,使用多线程和“标记-整理”算法



CMS收集器

    CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的响应速度,希望系统停顿时间最短,以给用户带来较好的体验。CMS收集器非常符合这类应用的需求。CMS收集器采用标记清除算法,收集过程大概是:
    a)初始标记(CMS initial mark) b)并发标记(CMS concurrent mark)
    c)重新标记(CMS remark)        d)并发清除(CMS concurrent sweep)

    其中,初始标记、重新标记这两个步骤仍然需要“Stop The Word”。初始标记仅仅是标记一下GC Roots能直接关联到的对象,速度很快,并发标记阶段就是进行GC Roots Tracing的过程,而重新标记阶段则是为了修正并发标记期间因用户程序继续动作而导致标记产生变动的那一部分对象的标记记录,这个阶段的停顿时间一般会比初始阶段稍长一些,但远比并发标记的时间短。

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

    优点:并发、低停顿。

    不足:
    a)CMS收集器对CPU资源非常敏感。在并发阶段,它虽然不会导致用户线程停顿,但是会因为(独)占用了一部分线程(或者说CPU资源)而导致应用程序变慢,总吞吐量降低。CMS默认启动的回收线程数是(CPU数量+3)/4。即4个以上时,线程不少于25%,4个以下时,CMS对用户程序影响较大。
    b)CMS收集器无法处理浮动垃圾(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”失败,这时虚拟机将启动后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集,这时停顿的时间就很长了。所以说参数-XX:CMSInitiatingOccupancyFraction设置太高很容易导致大量“Concurrent Mode Failure”失败,性能反而会降低。
    c)由于是一款“标记-清除”算法的垃圾收集器,因此清理后会留下大量的内存碎片。空间碎片太多引发的问题就是给大对象分配内存很麻烦,往往会出现老年代还有很大空间,却无法找到足够的连续空间来分配当前的对象,不得不提前触发一次Full GC。为了解决这个问题,CMS收集器提供了一个-XX:UseCMSCompactAtFullCollection开关参数(默认开启),用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程,内存整理过程是无法并发的,空间碎片降低了,停顿时间不得不变长。虚拟机还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction,这个参数胜地设置执行多少次不压缩的Full GC后,跟着来一次带压缩的(默认值是0,表示每次进入Full GC时都进行碎片整理)。


G1收集器

    G1(Garbage-First)收集器是一款服务端应用的垃圾收集器。优点是:
    a)并行与并发。
    b)分代收集。垃圾收集不需要和其他GC收集器配合,独立管理堆内存。
    c)空间整合:采用“标记-整理”算法。
    d)可预测的停顿。


理解GC日志

    阅读GC日志是处理Java虚拟机内存问题的基础技能。每一种收集器的日志形式都由他们自身的实现所决定,换而言之,每个收集器的日志格式都可以不一样。但虚拟设计者为了方便用户阅读,将各个收集器的日志都维持一定的共性,如下两段典型的GC日志:

0.065: [GC0.065: [DefNew: 343K->216K(4800K), 0.0019830 secs]0.067: [Tenured: 0K->214K(10624K), 0.0037740 secs] 343K->214K(15424K), [Perm : 2421K->2421K(21248K)], 0.0058310 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] 0.083: [Full GC0.083: [Tenured: 20694K->20695K(31108K), 0.0039400 secs] 20956K->20695K(35972K), [Perm : 2424K->2424K(21248K)], 0.0040510 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]

最前面的0.065 、0.083:代表了GC发生的时间,从Java虚拟机启动以来经过的秒数。

GC日志开头的“[GC”和“[Full GC”:说明了这次垃圾收集的停顿类型,而不是用来区分新生代GC还是老年代GC的。有Full说明GC是发生了Stop-The-World的。如果调用了System.gc()方法所触发的收集,则会显示“[Full GC(System)”

接下来的“[DefNew”、“[Tenured”、“[Perm”表示发生的区域,这里显示的区域名称与使用的GC收集器是密切相关的,如使用Serial收集器时,显示的是“[DefNew”即Default New Generation;如果使用ParNew收集器,显示的是“[ParNew”即“Parallel New Generation”。如果采用的是Parallel Scavenge收集器,显示的是“PSYoungGen”。

后面方括号内部的“343K->216K(4800K)”含义是GC前该内存区域已使用容量->GC后该内存区域已使用的容量(该内存区域总容量),而方括号外的“343K->214K(15424K)”表示含义是 GC前Java堆已使用容量->GC后java堆已使用容量(Java堆总容量)。

再往后,“0.0019830 secs”表示GC消耗时间,单位秒。有些收集器会给出更具体的数据“[Times: user=0.00 sys=0.00, real=0.01 secs]”,表示用户态消耗时间、内核态消耗CPU时间和操作从开始到结束所经过的墙钟时间。

总结

1. 各收集器关键点

名称算法/内存区域优点不足应用场景
Serial(Coping)复制/(Yong)新生代简单而高效Stop The WorldClient模式(首选),单线程环境下
Serial Old(Mark-Compact)标记-整理/(Tenured)老年代
Stop The World
Client模式,单线程环境
ParNew(Coping)复制/(Yong)新生代
CPU多时可以更好的利用资源单线程环境下不如SerialServer模式(首选),多线程
Parallel Scavenge(Coping)复制/(Yong)新生代
控制吞吐量、GC自适应策略(GC Ergonomics)
没有用户交互的后台任务,注重吞吐量及CPU敏感的场合
Parallel Old(Mark-Compact)标记-整理/(Tenured)老年代


(1.6 or later)
CMS(Mark-Sweep)标记-清除/(Tenured)老年代

1)垃圾收集时对CPU资源非常敏感;2)CMS无法处理浮动垃圾(Floating Garbage),可能出现“Concurrent Mode Failure”而导致另一次Full GC。3)产生内存碎片Server模式
G1整体是标记整理,局部是复制/整个堆不牺牲吞吐量的前提下完成低停顿的内存回收

2. 停顿时间与吞吐量

停顿时间:垃圾收集时用户线程的停顿时间。停顿时间越短就越适合需要与用户交互的程序,良好的响应速度能提升用户的体验;
吞吐量:CPU用于运行用户代码的时间与CPU总消耗时间的比值,即吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间),高吞吐量可以最高效率的利用CPU时间,尽快地完成程序的运算任务,主要适合在后台运算而不需要太多交互的任务。

追求最短停顿时间:Serial、ParNew、Serial Old、CMS
追求更高吞吐量:Parallel Scavenge 、Parallel Old

3. 收集器组合

a)Serial + Serial Old    开启方式
b)Serial + CMS
c)ParNew + CMS (+ Serial Old)
d)ParNew + Serial Old
e)Parallel Scavenge + Serial Old
f)Parallel Scavenge + Parallel Old(1.6 or later)
h)G1