//FIX
这里主要向大家介绍目前HostSpot虚拟机中有哪些垃圾收集器，各自的特点。并分析各个垃圾收集的使用场景。
目前还没有哪一种收集器是万能的，只能说哪种收集器更适用哪些场景。
1. Serial收集器
Serial（串行）收集器是最先出现的收集器。这是一个单线程的收集器，并且在收集的过程中会暂停其他工作线程，直到收集结束。这种在垃圾收集的时候暂停其他一切工作线程的情况叫做“Stop the World”，这种暂停一切工作线程对于很多应用是难以接受的，比如你使用一个应用，每用1小时就要暂停几分钟，这对于用户体验是非常糟糕的。所以我们要尽量减少出现这种“Stop the World”的情况。
对于“Stop the World”有一个很形象的比喻：程序在堆或者方法区中创建对象相当于你在屋子里制造垃圾，而垃圾收集器就相当于有一个保姆在给你打扫垃圾。在打扫垃圾的时候你还在往地上乱扔垃圾，这房间就很难打扫完。（一般懒的人会说我家在打扫屋子的时候就是一边打扫一边扔啊，这种后面会有讲到怎么让你一边扔垃圾一边打扫）
虽然这种比喻不是很准确，但“Stop the world”就是在让你不要在修改对象之间的引用了。
目前只有在Client模式下会默认是新生代收集器。虽然使用这种收集器会出现长时间的停顿，但相比于其他的收集器也有其优点，那就是可以专注于一件事情，没有切换线程的开销。在桌面应用程序的场景中，分配给虚拟机管理的内存通常来说不会很多。一般就几十兆或者说在多一点一两百兆的新生代。只要停顿时间可以控制在几十毫秒或者一百多毫秒以内的话，这点停顿是可以接受的。（在平时玩游戏的延迟都会在几十毫秒以内，这样对于玩家是完全可以接受的，同理对于几十毫秒的停顿对于用户来说也是一样）所以，Serial收集器对于在Client模式下的虚拟机来说是一个很好的选择。
2.ParNew收集器
简单来说ParNew收集器就是Serial收集器的多线程版本。
ParNew收集器没有什么创新之处，但它却是许多Server模式下的首选的新生代收集器，其中有一个很重要的原因就是目前还有他能和CMS收集器配合工作。（CMS收集器是一款具有跨时代意义的垃圾收集器，稍后会做介绍）目前CMS作为年老代的收集器，新生代只能选择Serial收集器或者是ParNew收集器。
由于ParNew收集器是多线程的，所以现在单CPU的服务器上是没有Serial收集器的效果好的，但是随着CPU数量的提升，ParNew收集器的优势就会体现出来了。ParNew收集器默认开启的收集线程数是和CPU的数量是相同的，我们也可用-XX:ParallelGCThreads这个参数来制定线程数。
3. Parallel Scavenge 收集器
也是一个新生代收集器，也是使用的复制算法，也是并行的多线程收集器。。。那么它有什么特别之处呢？
它的特点是它的关注点和其他收集器不同，其他的收集器都要尽量的缩短垃圾回收的停顿时间，而Parallel Scavenge收集器则是希望到达一个可以控制的吞吐量。在垃圾收集的过程中吞吐量是指：用户运行代码时间/（运行代码时间+垃圾收集时间）。
停顿时间短适合那些需要和用户交互的程序，然而吞吐量高的则是合适那些在后台运算不需要太多交互的程序。
Parallel Scavenge提供了两个参数来控制吞吐量，一个是最大垃圾回收停顿时间-XX：MaxGCPauseMillis和吞吐量大小-XX：GCTimeRatio参数。ParallelScavenge收集器会尽量满足你设置的这两个值。
Parallel Scavenge收集器有一个很重要的参数是：-XX:+UseAdaptiveSizePolicy。这是一个开关参数，如果打开之后，就不需要你自己配置新生代大小，Eden区大小和Survivor区大小和晋升老年代年龄等参数了。收集器会根据你虚拟机实际运行情况来自行调整，以找到适合的最大吞吐量或者是停顿时间。
4. Serial Old 收集器
就是Serial老年代版本，单线程，使用标记-整理算法。
5. Parallel Old 收集器
Parallel Old 是Parallel Scavenge收集器的老年代版本，使用的是标记整理算法，多线程。在JDK1.6中才开始提供的。在此之前如果年轻代用了Parallel Scavenge收集器，那么在老年代中只能使用Serial Old收集器。这样的组合在多核CPU上的吞吐量未必能有ParNew+CMS组合给力。
在Parallel Old收集器出现后，在吞吐量优先上就可以优先考虑Parallel组合的收集器了。
6. CMS收集器
CMS（Concurrent Mark Sweep）收集器是一种哦以获取最短回收停顿时间为目标的收集器。最使用的场景就是Java的B/S系统的服务器上。B/S架构的程序尤其要重视服务器的响应速度，相应速度越短则用户体验就越好。
CMS是基于标记-清除算法的，它的收集过程相对复杂一些，主要分四个步骤：
- 初始标记：仅仅是标记一下GC Roots能直接关联到的对象。速度很快。
- 并发标记：通过GC Roots来遍历对象的过程。这段期间是允许用户程序继续运行的。
- 重新标记：修正并发标记期间因用户程序运行而导致变动的那一部分标记记录。
- 并发清除：就是对没有被引用的对象进行清除。
首先，执行最长时间的是并发标记和并发清除这两个阶段，由于这两个阶段都是可以和用户程序一起执行的。虽然在初始标记和重新标记期间还是需要“Stop The World”。但这两个阶段都是很快的，总体来说CMS收集器是一个低停顿的收集器。
但CMS收集器也有它的缺点：
- 第一个缺点是CMS收集器很依赖CPU资源。CMS默认启动的回收线程数是（CPU数量+3）/ 4，那么在CPU在4个以上的时候需要占用四分之一以上的CPU资源，CPU越多占用的就越少。但如果CPU数量就两个的话就会占用一般的CPU资源，这是让人无法接受的。
- CMS收集器可能会出现“Concurrent Mode Failure”错误，而导致产生一次Full GC。这是由于在并发清理阶段用户程序还在运行，这时候产生的垃圾就无法被清除掉，只好留给下一次GC的时候在清除掉。如果是用户程序产生的垃圾速度要更快一些，导致要填满了老年代，那么用户的程序就因为没有内存而无法运行了。所以在CMS收集器中需要预留一部分空间来当做并发收集时程序所使用的。在JDK1.5的时候是当老年代使用超过了68%就会进行回收。在1.6中CMS收集器启动的阀值默认已经提升至92%了。如果预留的不够了就会出现“Concurrent Mode Failure”错误。这时候虚拟机就会启动预备方案，使用Serial Old收集器来进行老年代的回收。这样停顿的时间就变长了。
- 第三个缺点就是CMS是基于“标记-清除”来实现的。所以在清除的时候会产生大量的内存碎片，给分配大对象带来了很大的麻烦。如果无法分配一个大对象就不得不进行一次Full GC。为了这个缺点，设计者提供了一个参数，来设置执行多少次不压缩的Full GC后跟着来一次压缩的GC。
