Serial收集器：最开始的垃圾收集器是Serial收集器，在jdk1.3.1之前是唯一的选择，他是一个单线程的收集器。当进行垃圾收集的时候会暂停其他所有的工作线程，直到收集结束。但是它仍然是虚拟机运行在Client模式下默认的新生代收集器因为它简单而高效，对于限定单个CPU的环境来说，serial收集器由于没有线程教务的开销，所以可以获得最高的单线程收集效率。而在桌面应用环境中，分配给虚拟机管理的内存一般来说不会很大，停顿时间完全可以控制在几十毫秒到一百多毫秒以内。是可以接受的。
ParNew收集器：它是Serial收集器的多线程版本他和Serial收集器相比之下，没有多少创新之处，但是它是运行在Server模式下的虚拟机中首选的新生代收集器，其中一个与性能无关的原因是除了Serial收集器以外，目前只有它和CMS收集器配合工作。他在单CPU的时候绝对不会比Serial收集器好，并且由于线程交互开销，该收集器在通过超线程技术实现两个CPU环境都不能百分百地保证可以超过Serial收集器。当然，随着CPU的增加，它对GC时系统资源的有效利用还是很有好处的。
Parallel Scavenge收集器：它是一个新生代收集器，它也是使用复制算法，也是并行的，好像跟ParNew一样。特别之处在于进行GC关注点不一样。其他收集器旨在缩短用户线程的停顿时间。而Parallel Scavenger目标是达到一个可控制的吞吐量。这里所谓的吞吐量就是CPU运行用户代码的时间与CPU的总运行时间的比值。他有两个重要参数可以设置：最大垃圾收集时间-XX：MaxGCPauseMillis参数，用于设计内存的回收时间尽可能不超过设定值，设置低了会频繁发生GC，-XX:GCTimeRatio是一个大于0小于100的值，是垃圾收集时间占总运行时间的比率。其中还有一个参数是UseAdaptiveSizePolicy，它是一个开关参数，可以根据当前系统运行情况收集性能监控信息去动态调整最合适的停顿时间。
Serial Old收集器：顾名思义，它是Serial收集器的老年版本。使用的是标记整理算法。主要意义也是给Client模式下的虚拟机使用的。不过在Server模式下，它还能有两个用途：1：在1.5版本jdk之前及1.5与Parallel Scavenge收集器搭配使用。2：作为CMS收集器的后备预案在并发发生Mode Failure时使用。
Parallel old收集器：同理它和Parallel不同的是它使用的是“标记整理”算法，它是在jdk1.6开始提供，在那之前，Parallel Scavenge收集器只能与Serial old收集器别无选择。效果不好。因为Serial old在Server性能不好，而Parallel old的出现让吞吐量优先的应用组合名副其实。
CMS收集器：是一种以获得最短回收停顿时间为目标的收集器，服务器很多都使用，因为希望停顿时间短。它是标记-清除算法，整个过程四个步骤：1：初始标记。2：并发标记。3：重新标记。4：并发清除。初始标记和并发标记需要STW,初始标记是标记一下GCRoots能直接关联的对象，速度很快，并发标记是进行GC RootTracing的过程，重新标记则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变化的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍微长一些，但远比并发标记的时间短。看起来很好，但是它还是有三个缺点：
CMS收集器对CPU资源非常敏感。默认情况下，CMS的收集线程数=(CPU数目+3)/4，当CPU个数大于4的时候，CMS的收集线程不会超过整个CPU占用率的25%。但是在CPU个数比较小的情况下，CPU占用就会突然增大，这样对于初始标记和并发标记这样”Stop The World”的过程来说，用户就会明显感觉到停顿。虽然有了解决方法，但已经废除了，就不多说了。
CMS收集器无法处理浮动垃圾，可能出现”Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就称为“浮动垃圾”。CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，它需要预留一部分空间提供并发收集时的线程使用。在JDK1.5默认设置下，CMS收集器在老年代使用了68%的空间会被激活，这是一个偏保守的设置。如果在应用中，老年代增长不是太快，可以适当调高这个参数-XX:CMSInitiatingOccupancyFraction。要是CMS运行期间预留的内存无法满足程序的需要，就会出现”Concurrent Mode Failure”失败，这时候JVM会启动后备方案：临时启动Serial Old收集器来重新进行老年代的垃圾收集，因为是单线程，停顿时间就会更长了。所以如果大量出现”Concurrent Mode Failure”，就可以将这个值调低
CMS是基于标记-清除算法实现的收集器，所以会产生内存碎片。空间碎片过多时，将会给大对象分配带来很大的麻烦：老年代还有空间但是没有连续的足够大的空间，于是不得不触发一次Full GC。为了解决这个问题，有一个开关叫做-XX:+UseCMSCompactAtFullCollection，用于在Full GC时开启内存碎片的合并整理过程。当然，这个内存整理没法并发，只有”Stop The World”了。另外，虚拟机还设计了一个参数-XX:CMSFullGCsBeforeCompaction,用于指定在多少次不压缩的Full GC后，跟着来一次带压缩的。
G1收集器：G1 GC是Jdk7的新特性之一、Jdk7+版本都可以自主配置G1作为JVM GC选项；作为JVM GC算法的一次重大升级、JDK7后G1已相对稳定、且未来计划替代CMS、所以有必要深入了解下：
不同于其他的分代回收算法、G1将堆空间划分成了互相独立的区块。每块区域既有可能属于O区、也有可能是Y区，且每类区域空间可以是不连续的（对比CMS的O区和Y区都必须是连续的）。这种将O区划分成多块的理念源于：当并发后台线程寻找可回收的对象时、有些区块包含可回收的对象要比其他区块多很多。虽然在清理这些区块时G1仍然需要暂停应用线程、但可以用相对较少的时间优先回收包含垃圾最多区块。这也是为什么G1命名为Garbage First的原因：第一时间处理垃圾最多的区块。
平时工作中大多数系统都使用CMS、即使静默升级到JDK7默认仍然采用CMS、那么G1相对于CMS的区别在：
1.G1在压缩空间方面有优势
2.G1通过将内存空间分成区域（Region）的方式避免内存碎片问题
3.Eden, Survivor, Old区不再固定、在内存使用效率上来说更灵活
4.G1可以通过设置预期停顿时间（Pause Time）来控制垃圾收集时间避免应用雪崩现象
5.G1在回收内存后会马上同时做合并空闲内存的工作、而CMS默认是在STW（stop the world）的时候做
6.G1会在Young GC中使用、而CMS只能在O区使用
就目前而言、CMS还是默认首选的GC策略、可能在以下场景下G1更适合：
1.服务端多核CPU、JVM内存占用较大的应用（至少大于4G）
2.应用在运行过程中会产生大量内存碎片、需要经常压缩空间
3.想要更可控、可预期的GC停顿周期；防止高并发下应用雪崩现象
一次完整G1GC的详细过程：
G1在运行过程中主要包含如下4种操作方式：
YGC（不同于CMS）
并发阶段
混合模式
full GC （一般是G1出现问题时发生）
YGC：
下面是一次YGC前后内存区域是示意图：
图中每个小区块都代表G1的一个区域（Region），区块里面的字母代表不同的分代内存空间类型（如[E]Eden,[O]Old,[S]Survivor）空白的区块不属于任何一个分区；G1可以在需要的时候任意指定这个区域属于Eden或是O区之类的。
G1 YoungGC在Eden充满时触发，在回收之后所有之前属于Eden的区块全变成空白。然后至少有一个区块是属于S区的（如图半满的那个区域），同时可能有一些数据移到了O区。
目前淘系的应用大都使用PrintGCDetails参数打出GC日志、这个参数对G1同样有效、但日志内容颇为不同；下面是一个Young GC的例子：
23.430: [GC pause (young), 0.23094400 secs]
...
[Eden: 1286M(1286M)->0B(1212M)
Survivors: 78M->152M Heap: 1454M(4096M)->242M(4096M)]
[Times: user=0.85 sys=0.05, real=0.23 secs]
上面日志的内容解析：Young GC实际占用230毫秒、其中GC线程占用850毫秒的CPU时间
E：内存占用从1286MB变成0、都被移出
S：从78M增长到了152M、说明从Eden移过来74M
Heap:占用从1454变成242M、说明这次Young GC一共释放了1212M内存空间
很多情况下，S区的对象会有部分晋升到Old区，另外如果S区已满、Eden存活的对象会直接晋升到Old区，这种情况下Old的空间就会涨
并发阶段：
一个并发G1回收周期前后内存占用情况如下图所示：
从上面的图表可以看出以下几点：
1、Young区发生了变化、这意味着在G1并发阶段内至少发生了一次YGC（这点和CMS就有区别），Eden在标记之前已经被完全清空，因为在并发阶段应用线程同时在工作、所以可以看到Eden又有新的占用
2、一些区域被X标记，这些区域属于O区，此时仍然有数据存放、不同之处在G1已标记出这些区域包含的垃圾最多、也就是回收收益最高的区域
3、在并发阶段完成之后实际上O区的容量变得更大了（O+X的方块）。这时因为这个过程中发生了YGC有新的对象进入所致。此外，这个阶段在O区没有回收任何对象：它的作用主要是标记出垃圾最多的区块出来。对象实际上是在后面的阶段真正开始被回收
G1并发标记周期可以分成几个阶段、其中有些需要暂停应用线程。第一个阶段是初始标记阶段。这个阶段会暂停所有应用线程-部分原因是这个过程会执行一次YGC、下面是一个日志示例：
50.541: [GC pause (young) (initial-mark), 0.27767100 secs]
[Eden: 1220M(1220M)->0B(1220M)
Survivors: 144M->144M Heap: 3242M(4096M)->2093M(4096M)]
[Times: user=1.02 sys=0.04, real=0.28 secs]
上面的日志表明发生了YGC、应用线程为此暂停了280毫秒，Eden区被清空（71MB从Young区移到了O区）。
日志里面initial-mark的字样表明后台的并发GC阶段开始了。因为初始标记阶段本身也是要暂停应用线程的，
G1正好在YGC的过程中把这个事情也一起干了。为此带来的额外开销不是很大、增加了20%的CPU，暂停时间相应的略微变长了些。
接下来，G1开始扫描根区域、日志示例：
50.819: [GC concurrent-root-region-scan-start]
51.408: [GC concurrent-root-region-scan-end, 0.5890230]
一共花了580毫秒，这个过程没有暂停应用线程；是后台线程并行处理的。这个阶段不能被YGC所打断、因此后台线程有足够的CPU时间很关键。如果Young区空间恰好在Root扫描的时候
满了、YGC必须等待root扫描之后才能进行。带来的影响是YGC暂停时间会相应的增加。这时的GC日志是这样的：
350.994: [GC pause (young)
351.093: [GC concurrent-root-region-scan-end, 0.6100090]
351.093: [GC concurrent-mark-start],0.37559600 secs]
GC暂停这里可以看出在root扫描结束之前就发生了，表明YGC发生了等待，等待时间大概是100毫秒。
在root扫描完成后，G1进入了一个并发标记阶段。这个阶段也是完全后台进行的；GC日志里面下面的信息代表这个阶段的开始和结束：
111.382: [GC concurrent-mark-start]
....
120.905: [GC concurrent-mark-end, 9.5225160 sec]
并发标记阶段是可以被打断的，比如这个过程中发生了YGC就会。这个阶段之后会有一个二次标记阶段和清理阶段：
120.910: [GC remark 120.959:
[GC ref-PRC, 0.0000890 secs], 0.0718990 secs]
[Times: user=0.23 sys=0.01, real=0.08 secs]
120.985: [GC cleanup 3510M->3434M(4096M), 0.0111040 secs]
[Times: user=0.04 sys=0.00, real=0.01 secs]
这两个阶段同样会暂停应用线程，但时间很短。接下来还有额外的一次并发清理阶段：
120.996: [GC concurrent-cleanup-start]
120.996: [GC concurrent-cleanup-end, 0.0004520]
到此为止，正常的一个G1周期已完成–这个周期主要做的是发现哪些区域包含可回收的垃圾最多（标记为X），实际空间释放较少。
混合GC：
接下来G1执行一系列的混合GC。这个时期因为会同时进行YGC和清理上面已标记为X的区域，所以称之为混合阶段，下面是一个混合GC执行的前后示意图：
像普通的YGC那样、G1完全清空掉Eden同时调整survivor区。另外，两个标记也被回收了，他们有个共同的特点是包含最多可回收的对象，因此这两个区域绝大部分空间都被释放了。这两个区域任何存活的对象都被移到了其他区域（和YGC存活对象晋升到O区类似）。这就是为什么G1的堆比CMS内存碎片要少很多的原因–移动这些对象的同时也就是在压缩对内存。下面是一个混合GC的日志：
79.826: [GC pause (mixed), 0.26161600 secs]
....
[Eden: 1222M(1222M)->0B(1220M)
Survivors: 142M->144M Heap: 3200M(4096M)->1964M(4096M)]
[Times: user=1.01 sys=0.00, real=0.26 secs]
上面的日志可以注意到Eden释放了1222MB、但整个堆的空间释放内存要大于这个数目。数量相差看起来比较少、只有16MB，但是要考虑同时有survivor区的对象晋升到O区；另外，每次混合GC只是清理一部分的O区内存，整个GC会一直持续到几乎所有的标记区域垃圾对象都被回收，这个阶段完了之后G1会重新回到正常的YGC阶段。周期性的，当O区内存占用达到一定数量之后G1又会开启一次新的并行GC阶段.
其他收集器：来自《深入理解Java虚拟机-jvm高级特性与最佳实践》
关于G1收集器：转载自并发编程网 – ifeve.com本文链接地址:深入理解G1垃圾收集器