前面的垃圾收集算法是理论,垃圾收集器则是具体的实现。下图是HotSpot里的收集器,中间的横线表示分代,有连线表示可以组合使用。虚拟机所处的区域表示它是属于新生代收集器还是老年代收集器。
Serial 收集器
是一个单线程的收集器,只能使用一个CPU或一条线程去完成垃圾收集;在进行垃圾收集时,必须暂停所有其他工作线程,直到收集完成。Serial/Serial Old 收集器运行示意图:
缺点:Stop-The-World。
优势:简单。对于但CPU的情况,由于没有多线程交互开销,反而可以更高效。是Client模式下默认的新生代收集器。
ParNew 收集器
是Serial收集器的多线程版本。在许多运行在Server模式下首选的新生代垃圾收集器(除了Serial收集器外,唯一能够和CMS收集器配合工作).ParNew收集器也是使用-XX:+UseConcMarkSweepGC选项后默认的新生代收集器,也可以使用-XX:+UseParNewGC选项来强制制定它。同时可以通过使用-XX:ParallelGCThreads参数来限制垃圾收集器的线程数.ParNew/Serial Old 收集器运行示意图:
垃圾收集语境下的并发与并行概念
- 并行(Parallel):指多条垃圾收集线程并行工作,用户线程仍然处于等待状态。
- 并发(Concurrent):用户线程与垃圾收集线程同时执行。
Parallel Scavenge 收集器
新生代收集器,使用复制算法、并行的多线程收集器。Parallel Scavenge 收集器的目标是达到一个可控制的吞吐量(Throughput)。这里的吞吐量是指CPU用于运行用户代码的时间与CPU总消耗时间的比值。吞吐量=运行用户代码时间/(运行用户代码时间+GC时间)。主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge提供了两个参数用户精确控制吞吐量。-XX:MaxGCPauseMillis控制最大垃圾收集停顿时间,收集器将尽量保证内存回收时间不超过设定值。,把这个参数设置的设置的小降低GC停损时间缩短是以降低新生代空间为代价的,可能会造成垃圾收集的频率增加。。-XX:GCTimeRatio直接设置吞吐量大小,即垃圾收集时间占总时间的比率(总时间/垃圾收集时间=GCTimeRatio)。
Parallel Scavenge 收集器允许采用GC自适应的调节策略,也就是让虚拟机根据收集到的运行时数据自行决定各个分代的大小等与垃圾回收有关的配置,可以通过-XX:+UseAdaptiveSizePolicy。这种动态调整参数以提供合适的停顿时间或者最大吞吐量的方式呗成为GC自适应的调节策略。
Serial Old 收集器
用于老年代的Serial收集器,单线程,使用“标记-整理”算法。
主要在Client模式下使用。
Parallel Old 收集器
Parallel Scavenge的老年代版本,多线程,使用“标记-整理”算法。
CMS 收集器
CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。基于“标记-清除”算法。
运作过程分为4个阶段:
- 初始标记(CMS initial mark):值标记GC Roots能直接关联到的对象。
- 并发标记(CMS concurrent mark):进行GC RootsTracing的过程。
- 重新标记(CMS remark):修正并发标记期间因用户程序继续运行而导致标记发生改变的那一部分对象的标记。
- 并发清除(CMS concurrent sweep):
其中标记和重新标记两个阶段仍然需要Stop-The-World,整个过程中耗时最长的并发标记和并发清除过程中收集器都可以和用户线程一起工作。
CMS收集器对CPU资源非常敏感。
浮动垃圾(Floating Garbage):由于CMS并发清理阶段用户线程还在运行着,自然会有新的垃圾产生,而这些垃圾是在标记过程之后,CMS只能在下次GC时回收它们,这些垃圾就称为浮动垃圾。
CMS收集器无法处理浮动垃圾,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。
在垃圾收集阶段用户线程还在运行,因此需要预留足够的内存给用户线程使用。如果预留内存不能满足用户线程,会出现“Concurrent Mode Failure”,这时虚拟机将启动临时后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集。
由于CMS使用的是清除算法,会导致内存碎片问题,因此提供了参数用于控制是否在进行FullGC后进行内存整理,还提供了参数用于控制在多少次FullGC时才进行内存整理。内存整理是不能并发的,也就是要暂停所有用户线程。
G1 收集器
G1(Garbage First):是一款面向服务端应用的垃圾收集器,用于替换CMS收集器。
G1将整个Java堆划分为大小相等的独立区域(Region);新生代和老年代不再是物理隔离的,都由一组不连续的Region组成。
G1的特点:
- 并行与并发:充分利用多CPU缩短Stop-The-World停顿时间,在收集过程中用并发的方式让Java线程继续执行。
- 分代收集:仍然有分代的概念,不需要其他收集器配合,独立管理整个GC堆。
- 空间整合:从整体看,是基于“标记-整理”算法实现的,从局部(两个Region之间)看是基于“复制”算法的。在运行期间不会产生内存碎片。
- 可预测的停顿:G1跟踪各个Region里垃圾堆积值的价值大小,维护一个优先级队列,每次根据允许的时间,优先回收价值最大的Region。(这也是Garbage First的由来)
Region之间的对象引用以及其他收集器中的新生代与老年代之间的对象引用,虚拟机都是使用Remembered Set来避免全堆扫描的。
G1中每个Region都有一个与之对应的Remembered Set,虚拟机发现程序对引用类型的数据进行写操作时,会产生一个Write Barrier暂时中断写操作,检查引用的对象是否处于不同的Region中(在其他收集器中就是检查是否老年代中的对象引用了新生代中对象),如果是, 通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set中。进行内存回收时,在GC根节点的枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。
G1垃圾回收主要有4个阶段:
- 初始标记:只标记GC Roots能直接关联到的对象,并且修改TAMS(Next Top at Mark Start)值,让下一阶段用户程序并发运行时,能在正确可用的Region中创建新对象。此阶段需要暂停用户线程。
- 并发标记:从GC Roots开始对堆中对象进行可达性分析,找出存活对象;耗时较长,可与用户线程并发执行。
- 最终标记:修正在并发标记期间有变动的标记记录。
- 刷选回收:对各个Region的回收价值和成本进行排序,根据用户期望的GC停顿时间制定回收计划,进行垃圾回收。
内存分配与回收规则
内存分配与回收规则由垃圾回收器和内存有关参数决定,不是固定的。
两个概念:
- MinorGC,次收集:在新生代发生的垃圾收集,速度快,发生频繁。
- FullGC,MajorGC,主收集:发生在年老代的垃圾收集。一般伴随一次MinorGC。
一般的规则:
-
对象优先在Eden分配。当Eden没有足够的空间时,虚拟机将发起一次MinorGC。
-
大对象直接进入老年代。大对象是指需要连续内存空间的Java对象。目的是避免在Eden区及两个Survivor区之间大量的内存复制(新生代采用复制算法收集内存)。
-
长期存活对象将进入老年代。虚拟机给每个对象定义一个对象年龄计数器,如果对象在Eden出生并经过一次 Minor GC后仍然存活,并且能够被Survivor容纳,将被移动到Survivor空间,并且对象年龄设为1。对象在Survivor区中每“熬过”一次 MinorGC,年龄就加1,达到某个阀值就晋升到年老代。
-
空间分配担保。在发生Minor GC之前,虚拟机会先检查年老代最大可用的连续空间算法大于新生代所有对象总空间,如果是,那么Minor GC可以确保是安全的。如果否,虚拟机会查看HandlePromotionFailure设置是否允许担保失败。如果允许继续检查老年代最大可用的连续 空间是否大于历次晋升到老年代对象的平均大小,如果大于,将尝试进行一次Minor GC,这是有风险的(存活对象占用的内存大于平均大小,将导致HandlePromotionFailure失败,重新发起一次Full GC);如果小于或者HandlePromotionFailure设置不允许冒险,将改为Full GC。