垃圾收集器

收集器概览

　　上面一个区域是新生代收集器，下面一个区域是老年代收集器。如果两个收集器之间存在连线，就说明它们可以搭配使用。

Serial收集器

　　采用复制算法，单线程，在垃圾收集时必须暂停其他所有的工作线程，直到收集结束。适用于小型client应用，如桌面应用。下图为Serial和Serial Old收集器搭配使用。
　　

ParNew收集器

　　采用复制算法，是Serial收集器的多线程版本。适用于Server应用，除了Serial收集器之外，它是唯一可以与CMS收集器搭配使用的收集器。下图为ParNew和Serial Old搭配使用。

Parallel Scavenge收集器

　　采用复制算法，多线程。其他收集器的关注点是尽可能地缩短垃圾收集时用户的停顿时间，而Paralleal Scavenge收集器的目标则是达到一个可控的吞吐量（Throughout，吞吐量=CPU运行用户代码时间/(运行用户代码时间+垃圾收集时间)。Parallel Scavenge收集器提供了两个参数精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数及直接设置吞吐量大小的 -XX:GCTimeRatio参数。
　　MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。不过大家不要异想天开地认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的：系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，现在变成5秒收集一次、每次停顿70毫秒。停顿时间的确在下降，但吞吐量也降下来了。
　　GCTimeRatio参数的值应当是一个大于0小于100的整数，也就是垃圾收集时间占总时间的比率，相当于是吞吐量的倒数。如果把此参数设置为19，那允许的最大GC时间就占总时间的5%（即1 /（1+19）），默认值为99，就是允许最大1%（即1 /（1+99））的垃圾收集时间。
　　由于与吞吐量关系密切，Parallel Scavenge收集器也经常被称为“吞吐量优先”收集器。除上述两个参数之外，Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy值得关注。这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升老年代对象年龄（-XX:PretenureSizeThreshold）等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略（GC Ergonomics）。如果读者对于收集器运作原理不太了解，手工优化存在困难的时候，使用Parallel Scavenge收集器配合自适应调节策略，把内存管理的调优任务交给虚拟机去完成将是一个很不错的选择。只需要把基本的内存数据设置好（如-Xmx设置最大堆），然后使用MaxGCPauseMillis参数（更关注最大停顿时间）或GCTimeRatio参数（更关注吞吐量）给虚拟机设立一个优化目标，那具体细节参数的调节工作就由虚拟机完成了。自适应调节策略也是Parallel Scavenge收集器与ParNew收集器的一个重要区别。
　　

Serial Old收集器

　　使用“标记-整理算法”，是Serial的老年代版本。适用于client模式的小型应用虚拟机。

Parallel Old收集器

　　采用“标记整理算法”，是Parallel Scavenge的老年代版本。在注重吞吐量以及CPU资源敏感的场合，可以优先考虑Parallel Scavenge+Parallel Old收集器组合。
　　

CMS收集器

使用“标记-清除算法”以获取最短回收停顿时间为目标，适用于B/S系统。
回收步骤：

1. 初始标记：停止所有线程，标记GC Roots能直接关联到的对象
2. 并发标记：GC Roots Tracing
3. 重新标记：停止所有线程，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录
4. 并发清除

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

缺点：
1、在并发阶段，CMS默认启动的回收线程是(CPU数量+3)/4，虽然不会导致用户停顿，但是会因为占用了一部分CPU资源导致应用程序边慢
2、由于CMS并发清理阶段用户线程还在运行着，伴随着程序运行自然就会有新的垃圾不断产生，这部分垃圾出现的标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC中再清理。这些垃圾就是“浮动垃圾”。
3、由于CMS并发清理阶段用户线程还在运行着，所以需要预留有足够的内存空间给用户线程使用，所以不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间供用户线程使用。在JDK1.5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，在JDK1.6是92%，如果在应用中老年代增长不是很快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提高触发百分比。如果预留的内存无法满足用户线程需要，虚拟机会启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集（称为Concurrent Mode Failure）
4、采用“标记-清除”算法，会产生大量空间碎片。当空间碎片过多，将会给大对象分配带来很大的麻烦，往往会出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前触发一次Full GC。为了解决这个问题，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认开启），用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程（停顿时间会变长）。

G1收集器

　　G1回收期将整个Java堆划分为多个大小相等的独立区域（Region），新生代和老年代都是一部分Region（不一定连续）的集合。
　　降低停顿时间是G1和CMS的共同关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。
　　G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java堆中进行全区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小，在后台维护一个有限列表，每次根据允许的收集时间，优先回收价值最大的Region（G1全程是Garbage-First）
回收步骤：
1、初始标记：跟CMS一样
2、并发标记：跟CMS一样
3、最终标记：停止所有线程，修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录
４、筛选回收：对Region的回收价值和成本进行排序，根据用户所期望的GC停顿时间来制定回收计划，可与用户线程并发执行