概述
Java虚拟机规范中对垃圾收集器应该如何实现并没有任何规定。不同厂商、不同版本的虚拟机所提供的垃圾收集器都可能会有很大差别。
没有最好的收集器,更没有万能的收集器,所以我们选择的只是对具体应用最合适的收集器。
本节内容将介绍以下7种垃圾收集器,其中有3种是新生代的垃圾收集器,有3种是老年代的垃圾收集器,有1种对新生代和老年代都可以进行垃圾收集。
- Young generation: ①Serial(/ˈsɪriəl/) ②ParNew(Parallel New /ˈpærəlel/) ③Parallel Scavenge(/ˈpærəlel/ /ˈskævɪndʒ/)
- Tenured generation: ①CMS(Concurrent Mark Sweep) ②Serial Old ③Parallel Old
- Young & Tenured generation: ①G1(Garbage First /ˈɡɑːrbɪdʒ/)
Serial 收集器
Serial 收集器是最基本、发展历史最悠久的收集器。这是一个单线程的收集器,但它的“单线程”的意义并不仅仅说明它只会使用一个CPU或一条收集线程去完成垃圾收集工作,更重要的是在它进行垃圾收集时,必须暂停其他所有的工作线程,直到它收集结束。是Client模式下的默认新生代收集器。
ParNew 收集器
ParNew 收集器其实就是Serial收集器的多线程版本,除了使用多线程进行垃圾收集之外,其余行为包括Serial收集器可用的所有控制参数(如:-XX:SurvivorRatio、-XX:PretenureSizeThreshod、-XXHandlePromotionFailure等)、收集算法、Stop The World、对象的分配规则、回收策略等都与Serial 收集器完全一样。
Parallel Scavenge 收集器
Parallel Scavenge 收集器是一个新生代收集器。它的特点是它的关注点与其他收集器不同,CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间,而Parallel Scavenge 收集器的目标则是达到一个可控制的吞吐量(Throughput)。吞吐量 = 运行用户代码时间 / (运行用户代码时间 + 垃圾收集时间)。
Parallel Scavenge 收集器提供了两个参数用于精确控制吞吐量,分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMills参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。
①MaxGCPauseMills 参数允许的值是一个大于0的毫秒数,收集器将尽可能地保证内存回收花费的时间不超过设定值。GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的。
②GCTimeRatio 参数的值应当时一个大于0且小于100的整数,默认值是99。
③-XX:+UseAdaptiveSizePolicy 这是一个开关参数,当打开参数之后,就不需要手工指定新生代的大小(-Xmn)、Eden与Survivor区的比例(-XX:SurvivorRatio)、晋升老年代对象大小(-XX:PretenureSizeThreshold)等细节参数了,虚拟机会根据当前系统的运行情况收集性能监控信息,动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量,这种调节方式称为GC自适应的调节策略(GC Ergonomics)。
Serial Old 收集器
Serial Old 是 Serial 收集器的来年代版本,同样是一个单线程收集器,使用"标记-整理"算法。也是在于给Client模式下的虚拟机使用。如果在Server模式下,它还有两大用途:一种用途是在JDK1.5以及之前的版本中与 Parallel Scavenge 收集器搭配使用,另一种用途就是作为CMS收集器的后备预案,在并发收集发生Concurrent Mode Failture时使用。
运行示意图见Serial 收集器的介绍。
Parallel Old 收集器
Parallel Old 是 Parallel Scavenge 收集器的老年代版本,使用多线程和"标记-整理"算法。在JDK1.6提供,当新生代为采用 Parallel Scavenge 收集器时,老年代由 Serial Old 被替换为 Parallel Scavenge 收集器。直到 Parallel Scavenge 收集器出现后,"吞吐量优先"收集器终于有了比较名副其实的应用组合,在注重吞吐量以及CPU资源敏感的场合,都可以优先考虑 Parallel Scavenge 加 Parallel Old 收集器。CMS 收集器
CMS(Concurrent Mark Sweep) 收集器是一种以获取最短回收停顿时间为目标的收集器。目前很大一部分的Java应用集中在互联网站或者B/S系统的服务端上,这类应用尤其重视服务的相应速度。希望系统停顿时间最短,以给用户带来较好的体验。CMS 收集器就非常符合这类应用的需求。CMS 整个收集过程分为4个步骤:
①初始标记(CMS initial mark)
②并发标记(CMS concurrent mark)
③重新标记(CMS mark)
④并发清除(CMS concurrent sweep)
优点:并发收集、低停顿 (Concurrent Low Pause Collector)
缺点:CMS还远达不到完美的程度,它有以下3个明显的缺点
①CMS 收集器对CPU资源非常敏感。CMS默认启动的回收线程数是(CPU数量 + 3) / 4
②CMS 收集器无法处理浮动垃圾(Floating Garbage),可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生。
浮动垃圾:CMS在并发清理时,用户线程产生的新垃圾。
Concurrent Mode Failure:由于在垃圾收集阶段用户线程还需要运行,那也就需要预留足够的内存空间给用户线程使用,因此CMS 收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,需要预留一部分空间提供并发收集时程序运作使用。当CMS 运行期间预留的内存无法满足程序需要,就会出现一次"Concurrent Mode Failure"失败,这时将启动后备预案,临时用Serial Old收集器来重新进行老年代的垃圾收集。
-XX:CMSInitiatingOccupancyFraction (老年代触发CMS垃圾回收的内存大小)
③CMS基于"标记-清除"算法实现,收集结束产生大量空间碎片。
为了解决这个问题,CMS收集器提供例如一个 -XX:+UseCMSCompactAtFullCollection开关参数(默认是开启的),在CMS 收集器顶不住要进行Full GC时开启内存碎片的合并整理,这个过程是无法并发的,空捡碎片问题可以解决,但是停顿时间会变长。
-XX:CMSFullGCsBeforeCompaction这个参数适用于设置执行多少次不压缩的Full GC后,跟着来一次带压缩的(默认值是0,表示每次进入Full GC时都进行碎片整理)。
G1 收集器
G1 (Garbage-First) 收集器是当今收集器技术发展的最前沿成果之一,JDK1.7被正式使用。它的使命是在未来替换掉JDK1.5发布的CMS 收集器。
特点:
①并行与并发:G1能充分利用多CPU、多核环境下的硬件优势,使用多核CPU来缩短 Stop The World停顿的时间
②分代收集:G1可以不需要其他收集器配合就能独立管理整个GC堆,但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的手机效果。
③空间整合:与CMS的"标记-清理"算法不同,G1从整体来看是基于"标记-整理"算法实现的收集器,从局部(两个Region之间)上来看是基于"复制"算法实现的。G1不会产生内存空间碎片,手机后能提供规整的可用内存。
④可预测的停顿:这是G1相对于CMS的另一大优势,G1除了追求低停顿外,还能建立可预测的停顿时间模型,能让使用者明确指定在一个长度为M毫秒的时间片段内,消耗在垃圾收集上的时间不得超过N毫秒。这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。
G1之前的其他收集器进行收集的范围都是整个新生代或者老年代,而G1不再是这样。使用G1时,Java堆内存布局就与其他收集器有很大差别,它将整个Java堆划分为多个大小相等的独立区域(Region),新生代和老年代不再是物理隔离的。都是一部分Region(不需要连续)的集合。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小以及回收所需时间的经验值),在后台维护一个优先列表,每次根据允许的收集时间,优先回收价值最大的Region(这也就是Garbage-First名称的来由)。
G1把内存"化整为零"的思路,理解起来很容易,但是实现起来非常困难。
以一个细节为例:把Java堆分为多个Region后,垃圾收集是否就真的能以Region为单位进行了?
Region不可能是孤立的,一个对象分配在某个Region中,它并非只能被本Region中的其他对象引用,而是可以与整个Java堆任意的对象发生引用关系。
可达性判定是否需要扫描整个Java堆才能保证准确性?
Remembered Set
G1收集器的运作大致可划分为以下4个步骤:
①初始标记(Initial Marking)
②并发标记(Concurrent Marking)
③最终标记(Final Marking)
④筛选回收(Live Data Counting and Evacuation)
小结:其实说了这么多,垃圾收集器的发展也是有目共睹。垃圾收集器的组合很多,使用的场景也各有不同。如client模式下的单线程垃圾收集器Serial + Serial Old是尽可能不占资源,简单高效的组合;Serial的多线程版本ParNew并行收集器 + CMS + Serial Old的组合是追求尽可能的缩短每次stop the world 的时间;Parallel Scavenge + Serial Old是jdk1.5之前server模式下默认的组合,直到jdk1.6Parallel Old的出现,完美的替代了Serial Old,并且诠释了什么叫做真正的高吞吐量,这正是server模式下服务所需要的;G1是jdk1.7开始正式使用的垃圾收集器,打破了新生代与老年代物理隔离的限制,将内存"化整为零"分为多个Region,靠每块Region的回收价值去驱动进行垃圾收集,这可以说是垃圾收集器的一个大的突破。