深入JVM-垃圾收集算法与垃圾收集器

1.垃圾收集算法

1.1.标记-清除算法

此算法分为“标记”和“清除”两个阶段，首先标记出所有要回收的对象，标记完成后统一回收掉所有被标记的对象（标记过程参考《深入JVM-垃圾收集器之内存回收》），它是最基础的收集算法，其缺点主要有两个：

1. 效率问题，标记和清除过程效率不高
2. 空间问题，标记清除之后会产生大量不连续的内存碎片，空间碎片太多可能会导致，程序在以后运行过程中需要分配大对象时找不到足够的连续内存而不得不提前触发另一次垃圾收集动作。
   标记-清除算法执行过程如下：
   

1.2.复制算法

此算法相对于“标记-清除算法”解决了效率问题，它将可用内存按容量划分为大小相等的两块，每次只使用其中一块，当这一块内存用完了，就将还存活的对象复制到另外一块上，然后把已使用过的内存块一次清理掉。这样每次都是对其中一块进行内存回收，内存分配时就不用考虑内存碎片等复杂情况，只要一动对顶指针按顺序分配内存即可，实现简单，运行高效。
此算法缺点是将内存每次只能使用一半，代价太高。
复制算法执行过程如下：

1.3.标记-整理算法

标记-整理算法的标记过程和“标记-清除算法”一样，但是后续步骤不是直接回收对象，而是让所有存活的对象都想一端移动，然后直接清理掉端边界以外的内存。
标记-整理算法执行过程如下：

1.4.总结

当前商业虚拟机的垃圾收集都是使用“分代收集”算法，其实就是根据对象的存活周期不同将内存划分为为几块。一般java堆分为新生代和老年代。

• 新生代
          新生代中的对象生命周期短并且对象的存活率低，故一般都是使用复制算法来回收新生代，新生代中内存分为一个Eden空间和两个Survivor空间，Eden空间和Survivor比例为8:1:1，每次只使用Eden空间和一个Survivor空间，当回收时，将Eden空间和Survivor空间中还存活的对象一次性拷贝到另外一个Survivor空间中，如果这个Survivor没有足够的内存空间，则会通过分配担保进入到老年代，然后清理掉Eden和刚才使用过的Survivor空间。故新生代中可用内存容量为整个新生代内存的90%（80%+10%）。
• 老年代
          老年代中对象存活率相对较高，也没有额外空间对它进行分配担保，因此使用标记-整理算法来进行内存回收。

2.垃圾收集器

并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。
并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行的，可能会交替执行），用户程序继续执行，而垃圾收集程序运行与另一个CPU上。

2.1.Serial收集器

Serial收集器是一个单线程的收集器，工作只能使用一个CPU或者一个收集线程去完成垃圾收集，还有就是在进行垃圾收集时，必须暂停其他所有的工作线程（Stop The World），直到收集结束。
特点：

• 单线程环境下，与其他收集器相比简单而高效。
• 没有线程间的交互，一般作为虚拟机在Client模式下的默认的新生代收集器。

2.2.ParNew收集器

ParNew收集器其实是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为（JVM控制参数、收集算法、Stop The World、对象分配规则、回收策略）都与Serial收集器完全一样。
特点：

• 新生代中一般选择ParNew收集器或者Serial收集器中的一个。
• 单线程环境下效率不如Serial收集器。
• 多线程环境下对于GC时系统资源利用较好，默认开启的线程数与CPU数量相同。

2.3.Parallel Scavenge收集器

Parallel Scavenge收集器也是新生代收集器，也是使用复制算法，而且是并行多线程收集器。它的关注点与其他收集器不同，其他收集器关注点是尽可能的缩短垃圾收集时用户线程停顿时间，而Parallel Scavenge收集器的目的是达到一个可控制的吞吐量。吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。
        停顿时间越短越适合需要与用户交互的程序，良好的响应速度能提升用户体验；而高吞吐量则可以最高效率的利用CPU时间，尽快地完成程序的运算任务，主要适合在后台运算而不需要太多交互的任务。
Parallel Scavenge收集器提供两个参数控制吞吐量：

• -XX:MaxGCPauseMillis 控制最大垃圾收集停顿时间
          MaxGCPauseMillis是一个大于0的毫秒数，收集器将尽力保证内存回收花费的时间不超过设定值。但是不能认为这个参数越小就会使系统的垃圾收集越快，因为GC停顿时间是以牺牲吞吐量和新生代空间换取的。例如把系统新生代调小点，收集300MB肯定比收集500MB快，但是也导致收集更频繁，原来10秒收集一次、每次停顿100毫秒，现在变成每5秒收集一次、每次停顿70毫秒。停顿时间是降低了，但是吞吐量也降下来了。
• -XX:GCTimeRatio 直接设置吞吐量大小
          GCTimeRatio是一个大于0小于100的整数。如果此数为n，那么系统所允许的最大GC时间就是1/(1+n)。

Parallel Scavenge收集器GC自适应调节策略：
        此收集器有个参数-XX:UseAdaptiveSizePolicy，这个参数打开之后，就不需要手工指定新生代的大小（-Xmn）、Eden与Survivor区的比例（-XX:SurvivorRatio）、晋升到老年代的年龄（-XX:PretenureSizeThreshold）等细节参数，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或最大的吞吐量。
        如果对收集器原理不太了解，或者手工优化存在困难时候，使用此策略是个很不错的选择，只需要把内存数据设置好，然后使用MaxGCPauseMillis参数或GCTimeRatio参数给虚拟机设立一个优化目标，具体细节参数的调节工作就由虚拟机完成了。

2.4.Serial Old收集器

Serial Old收集器是Serial收集器的老年代版本，它也是一个单线程收集器，使用“标记-整理”算法，主要也是被Client模式下的虚拟机使用。但是在Server模式下也有两个用途：
一个是在JDK1.5及之前的版本中与Parallel Scavenge收集器搭配使用；另一个就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure的时候使用。

2.5.Parallel Old收集器

Parallel Old收集器是Parallel Scavenge收集器的老年代版本，使用多线程和“标记-整理”算法。这个收集器是JDK1.6出现，在此之前，如果新生代选择了Parallel Scavenge收集器，老年代除了Serial Old收集器别无选择，但是由于Serial Old收集器是单线程无法充分利用多服务器多CPU的处理能力，即使使用了Parallel Scavenge收集器也未必能在整体应用上获得吞吐量最大化的效果。直到Parallel Old收集器出现后，使用Parallel Scavenge收集器搭配Parallel Old收集器，在注重吞吐量及CPU资源敏感的场合，是一种比较好的选择。

2.6.CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。常用于比较重视服务的响应速度，希望系统停顿时间短的B/S服务器上，以给用户带来较好的体验。
CMS收集器基于“标记-清除”算法，运行过程分为四个步骤：

1. 初始标记（CMS inital mark）
2. 并发标记（CMS concurrent mark）
3. 重新标记（CMS remark）
4. 并发清除（CMS concurrent sweep）

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

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

CMS收集器还有三个缺点：

• CMS收集器堆CPU资源非常敏感
          面向并发设计的程序都对CPU资源比较敏感，在并发阶段，它虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或CPU资源）而导致应用程序变慢，总吞吐量降低。CMS默认启动的回收线程数是（CPU数量+3）/4，当CPU大于4个时，并发回收时垃圾收集线程最多占用不超过25%的CPU资源，CPU小于4个时，那么CMS对用户程序的影响就可能变的很大。
• CMS收集器无法处理浮动垃圾（Floating Garbage）
          CMS并发清理阶段用户线程还在运行着，伴随着程序的运行还会有新的垃圾产生，由于这部分垃圾出现在标记过程后，CMS无法在本次收集中处理掉它们，只好留待下一次GC时将其清理掉，这部分垃圾被称为“浮动垃圾”。
          由于垃圾收集阶段用户线程还需要运行，即还需要留出足够内存给用户线程使用，因此CMS收集器不能像其他收集器一样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用，默认设置为老年代使用68%后悔激活CMS收集。
• CMS收集器是基于“标记-清除”算法，收集结束会产生大量空间碎片
          CMS是基于“标记-清除”算法实现，即在收集结束后会产生大量空间碎片，空间碎片过多时，会造成大对象没有足够的内存分配，而不得不提前触发一次Full GC。而CMS提供了一个参数-XX:UseCMSCompactAtFullCollection在Full GC之后提供一次碎片整理过程，而内存整理过程是无法并发的，即停顿时间又会变长。而虚拟机还有另一个参数-XX:CMSFullGCsBeforeCompaction用来设置在执行多少次不压缩的Full GC后，再执行一次压缩的操作。

2.7.G1收集器

G1收集器相对于CMS收集器有两个改进：

• 一是基于“标记-整理”算法实现的 收集器，即它不会产生空间碎片。
• 二是它可以非常精准的控制停顿，即它能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

G1收集器可以实现在基本不牺牲吞吐量的前提下完成低停顿的内存回收，因为它能够激励的避免全区域的垃圾收集，之前的收集器收集的范围都是整个新生代或者老年代，而G1收集器将整个Java堆（新生代和老年代）划分为了多个大小固定的独立区域Region，并且跟踪这个区域里面的垃圾堆积程度，在后台维护一个有限列表，每次根据允许的收集时间，优先回收垃圾最多的区域。区域划分及有优先级的区域回收，保证了G1收集器在优先时间内可以获得最高的手机效率。

2.8.垃圾收集器参数总结

参数	描述
UseSerialGC	虚拟机运行在Client模式下的默认值，打开此开关后，使用Serial+Serial Old的收集器组合进行内存回收
UseParNewGC	打开此开关后，使用ParNew+Serial Old的收集器组合进行内存回收
UseConcMarkSweepGC	打开此开关后，使用ParNew+CMS+Serial Old的收集器组合进行内存回收。Serial Old收集器将作为CMS收集器出现Concurrent Mode Failure失败后的后备收集器使用
UseParallelGC	虚拟机运行在Server模式下的默认值，打开此开关后，使用Parallel Scavenge+Serial Old（PS MarkSweep）的收集器组合进行内存回收
UseParallelOldGC	打开此开关后，使用Parallel Scavenge+Parallel Old的收集器组合进行内存回收
SurvivorRatio	新生代中Eden区域与Survivor区域的容量比值，默认为8，代表Eden:Survivor=8:1
PretenureSizeThreshold	直接晋升到老年代的对象大小，设置这个参数后，大于这个参数的对象将直接老年代分配
MaxTenuringThreshold	晋升到老年代的对象年龄。每个对象在坚持过一次Minor GC之后，年龄就+1，当超过这个参数值时就进入老年代
UseAdaptiveSizePolicy	动态调整java堆中各个区域的大小及进入老年代的年龄
HandlePromotionFailure	是否允许分配担保失败，即老年代的剩余空间不足以应付新生代的整个Eden和Survivor区的所有对象都存活的极端情况
ParallelGCThreads	设置并行GC时进行内存回收的线程数
GCTimeRatio	GC时间占总时间的比率，默认值为99，即允许1%的GC时间。仅在使用Parallel Scavenge收集器时生效
MaxGCPauseMillis	设置GC的最大停顿时间。仅在使用Parallel Scavenge收集器时生效
CMSInitiatingOccupancyFraction	设置CMS收集器在老年代空间被使用多少后触发垃圾收集。默认值为68%，仅在使用CMS收集器时生效
UseCMSCompactAtFullCollection	设置CMS收集器在完成垃圾收集后是否要进行一次内存碎片整理。仅在使用CMS收集器时生效
CMSFullGCsBeforeCompaction	设置CMS收集器在进行若干次垃圾收集后在启动一次内存碎片整理。仅在使用CMS收集器时生效

---

参考资料：
《深入理解JAVA虚拟机》