JVM（HotSpot）7种垃圾收集器

JVM（HotSpot）7种垃圾收集器

7种垃圾收集器作用于不同的分代，如果两个收集器之间存在连续，就说明他们可以搭配使用。

从JDK1.3到现在，从Serial收集器-》Parallel收集器-》CMS-》G1，用户线程停顿时间不断缩短，但仍然无法完全消除。

1、Serial收集器（串行收集器）

　　　

　　Serial收集器是最基本、发展历史最悠久的收集器，曾是（JDK1.3.1之前）虚拟机新生代收集的唯一选择。

　　Serial收集器是一个单线程的收集器。“单线程”的意义不仅仅是它只会使用一个CPU或一条收集器线程去完成垃圾收集工作，更重要的是它在垃圾收集的时候，必须暂停其他所有工作的线程，直到它收集结束。

　　Serial收集器是HotSpot虚拟机运行在Client模式下的默认新生代收集器。

　　Serial收集器具有简单而高效，由于没有线程交互的开销，可以获得最高的单线程收集效率（在单个CPU环境中）。

　　"-XX:+UseSerialGC"：添加该参数来显式的使用Serial垃圾收集器。

2、ParNew收集器

　　ParNew收集器是Serial收集器的多线程版本，除了使用多条线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Word、对象分配规则、回收策略等都与Serial收集器一样。

　　ParNew收集器是许多运行在Server模式下的虚拟机首选的新生代收集器，其中一个原因是，除了Serial收集器之外，目前只有ParNew收集器能与CMS收集器配合工作。　

　　"-XX:+UseConcMarkSweepGC"：指定使用CMS后，会默认使用ParNew作为新生代收集器。

"-XX:+UseParNewGC"：强制指定使用ParNew。

"-XX:ParallelGCThreads"：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同。

　　并行（Parallel）：指多条垃圾收集线程并行工作，但此时用户线程仍然处于等待状态。

　　并发（Concurrent）：指用户线程与垃圾收集线程同时执行（但不一定是并行，可能是交替执行），用户线程继续工作，而垃圾收集程序运行在另一个CPU上。

3、Parallel Scavenge收集器

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

　　Parallel Scavenge收集器关注点是达到一个可控制的吞吐量（吞吐量 = 运行用户代码时间 / （运行用户代码时间 + 垃圾收集时间）），而其他收集器关注点在尽可能的缩短垃圾收集时用户线程的停顿时间。

　　Parallel Scavenge收集器提供了两个参数来用于精确控制吞吐量，一是控制最大垃圾收集停顿时间的 -XX：MaxGCPauseMillis参数，二是控制吞吐量大小的 -XX：GCTimeRatio参数；

　　“ -XX：MaxGCPauseMillis” 参数允许的值是一个大于0的毫秒数，收集器将尽可能的保证内存垃圾回收花费的时间不超过设定的值（但是，并不是越小越好，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的，如果设置的值太小，将会导致频繁GC，这样虽然GC停顿时间下来了，但是吞吐量也下来了）。

　　“ -XX：GCTimeRatio”参数的值是一个大于0且小于100的整数，也就是垃圾收集时间占总时间的比率，默认值是99，就是允许最大1%（即1/（1+99））的垃圾收集时间。

　　“-XX：UseAdaptiveSizePolicy”参数是一个开发，如果这个参数打开之后，虚拟机会根据当前系统运行情况收集监控信息，动态调整新生代的比例、老年大大小等细节参数，以提供最合适的停顿时间或最大的吞吐量，这种调节方式称为GC自适应的调节策略。

4、Serial Old收集器

　　Serial Old收集器是Seria收集器的老年代版本，他同样是一个单线程收集器，使用" 标记-整理" 算法。

　　Serial Old收集器主要用于Client模式下的虚拟机使用。

　　Server模式下的两大用途：一、在JDK1.5及之前的版本与Parallel Scavenge收集器搭配使用；二、作为CMS收集器的后备方案，在并发收集发生Conturrent Mode Failure时使用。

5、Paraller Old收集器

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

　　在JDK1.6中才出现。

6、CMS（Conturrent Mark Sweep）收集器

　　

　　CMS收集器是一种以获取最短回收停顿时间为目标的收集器。

　　目前很大一部分的Java应用集中在互联网或者B/S系统的服务端上。

　　CMS收集器是基于“标记-清除”算法实现，它的整个运行过程可以分为：初始登记（标记一下GC Roots能直接关联到的对象，这个过程速度很快）、并发标记（进行GCRoots Tracing的过程）、重新标记（修正并发标记期间因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，速度稍慢）、并发清除（清除死亡的对象）4个步骤；其中，初始标记和重新标记仍然需要“Stop The World”。

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

　　优点：并发收集、低停顿。

　　缺点：

　　　　一：CMS收集器对CPU资源非常敏感。虽然在两个并发阶段不会导致用户线程停顿，但是会因为占用了一部分线程而导致应用程序变慢，总吞吐量下降。CMS默认启动的回收线程数是（CPU数量+3）/4。

　　　　二：CMS收集器无法处理浮动垃圾，可能出现“Conturrent Mode Failure”失败而导致另一次Full GC产生。由于CMS并发清除阶段用户线程还在运行，伴随着程序还在产生新的垃圾，这一部分垃圾出现在标记之后，CMS无法在当次收集中处理掉它们，只能留到下次再清理，这一部分垃圾称为“浮动垃圾”。也正是由于在垃圾收集阶段用户线程还在运行，那么也就需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等待老年代填满之后再进行收集，需要预留一部分空间给并发收集时用户程序使用。可以通过“-XX：CMSInitiatingOccupancyFraction”参数设置老年代内存使用达到多少时启动收集。

　　　　三：由于CMS收集器是一个基于“标记-清除”算法的收集器，那么意味着收集结束会产生大量碎片，有时候往往还有很多内存未使用，可是没有一块连续的空间来分配一个对象，导致不得不提前触发一次Full GC。CMS收集器提供了一个“-XX：UseCMSCompactAtFullCollection”参数（默认是开启的）用于在CMS收集器顶不住要FullGC时开启内存碎片整理（内存碎片整理意味着无法并发执行不得不停顿用户线程）。参数“-XX：CMSFullGCsBeforeCompaction”来设置执行多少次不压缩的Full GC后，跟着来一次带压缩的（默认值是0，意味着每次进入Full GC时都进行碎片整理）。

　　

7、G1（Garbage-First）收集器

　　

　　G1收集器是当今收集器技术发展的最前沿成果之一；

　　相比其它收集器，具有如下特点：

　　　　1、并行与并发：G1能够重发利用多CPU、多核环境下的优势，使用多个CPU来缩短Stop-The-World停顿时间。

　　　　2、分代收集：与其他收集器一样，分代概念在G1中依然存在。

　　　　3、空间整合：与CMS的“标记-清理”算法不同，G1从整体来看是基于“标记-整理”来实现的收集器，从局部（两个Region之间）上来看是基于“复制”算法实现的，这两种算法都意味着G1运作期间不会产生内存空间碎片，收集后能够提供整体的可用内存。

　　　　4、可预测停顿：G1除了追求低停顿之外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不得超过N毫秒。

　　使用G1收集器时，Java堆的内存布局与其他收集器有很大的区别，它将整个Java堆划分为多个大小相等的独立区域（Region），虽然还保留着新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，他们都是一部分Region（不需要连续）的集合。

　　G1收集器之所以能够建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java对中进行全区域的垃圾收集。G1跟踪各个Region里面垃圾堆积的价值大小（回收所获得的空间大小以及回收所需要时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（这也是Garbage-First名称的由来）。

　　G1收集器的运作大致可分为：

　　　　1、初始标记：需要停顿，耗时短；

　　　　2、并发标记：

　　　　3、最终标记：需要停顿，可并发执行；

　　　　4、筛选标记：