垃圾收集器

1.Serial收集器：
Serial收集器是最基本，发展历史最久的收集器，这个收集器是单线程的收集器，但是他的单线程的意义并不仅仅说明他只会使用一个CPU或一条收集线程去完成垃圾收集工作，更重要的是他进行垃圾收集时，必须暂停所有的工作线程，直到他收集结束，“stop the world”就是这个意思，他是由虚拟机在后台自动发起并自动完成的，在用户不可见的情况下，把用户的全部线程停掉，这对很多应用来说都是不可接受的，很多用户觉得Serial是一个无用的收集器，但是实际上到现在为止，他依旧是虚拟机运行在client模式下的默认的新生代收集器，他有优于其他收集器的地方，如简单而高效，对于限定单个CPU的环境来说，Serial收集器因为没有线程交互的开销，专心做垃圾收集自然能够获得最高的单线程收集效率，在用户的桌面的应用中，分配给虚拟机的管理的内存不会很大， 收集几十兆或者一两百的新生代数据，停顿时间是完全可以接受的，所以，Serial收集器是client模式下的一个很好的选择。

2.PerNew收集器：
PerNew收集器是Serial收集器的多线程版本，除了使用多线程外，其他的包括所有的Serial收集器的控制参数（-XX:SurvivorRatio, -XX:PretenureSizeThreshold, -XX:HandlePromotionFailure等）收集算法，对象分配的原则，回收的策略等都和Serial收集器完全一样，在实现上，这两者收集也共用了相当多的代码。
ParNew收集器除了多线程收集之外，并没有什么创新之处，但是他确是运行在Server模式下的首选的新生代的收集器，其中有一个和性能无关的最重要的原因是：除了Serial收集器之外，目前只有他能和CMS（老生代收集器）收集器配合工作，所以用CMS来收集老生代的时候，只能用Serial或者ParNew收集器。ParNew收集器在单CPU环境中绝对不会有比Serial更好的收集的性能，因为他存在与其他线程的交互的开销，该收集器通过超线程技术也没有保证超越Serial收集器，他默认开启的收集线程数是CPU线程数相同，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

3.CMS收集器：
CMS收集器是一种以最短的回收停顿时间为目标的收集器，目前很大一部分都运行在都集中在互联网站和B/S架构的服务端上.
CMS收集器是基于“标记-清除”的算法实现的，他的运作过程分为4个步骤：
1：初始标记
2：并发标记
3：重新标记
4：并发清除
其中，初始标记和重新标记还是需要暂停所有线程，初始标记只是标记一下GC-Roots能够直接关联的对象，速度很快，并发标记是GC RootsTracing的过程，而重新标记只是为了修正并发标记过程中因用户程序继续运行而导致标记产生变动的一部分标记记录，这个阶段的停顿时间会比初始阶段的时间稍微长一点，但比并发标记的时间要短一些。
由于整个过程耗时最长的并发标记和并发清除，收集器线程和用户的线程是一起工作的，所以，从整体上讲，CMS和用户的线程是并发执行的。CMS是一款优秀的收集器，他主要体现在并发和低停顿。但是他也有很明显的缺点，
a:CMS对CPU非常敏感，CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU是4个以上的时候，影响还好，但是当CPU不足4个的时候，CMS对用户的程序影响就会很大，因为他要分出一一半的运算能力去执行收集的线程，就导致用户的程序下降了50%.
b:CMS无法回收浮动垃圾，从而导致一次Full GC，由于CMS收集的时候，用户的线程还在运行，就自然会产生垃圾，这与部分垃圾出现在标记过程之后，这样CMS就无法在当次处理掉他们，只好留到下一次GC再清理，这一部分垃圾叫做浮动垃圾。
c:CMS是一款基于标记-清除的算法实现，这意味这会有很多的碎片产生，空间碎片太多，将会给分配大内存的对象产生麻烦，因为无法找到足够大的空间，CMS不得不提前触发一次Full GC。