垃圾收集器

垃圾收集器概述：

       垃圾收集器是垃圾收集算法的具体实现，垃圾收集算法主要有：标记-清理、复制算法、标记-整理种算法其中，标记清理算法是最基础的算法，其他两种算法都在它的基础上优化得到的。
       HotSpot虚拟机的垃圾收集器主要有以下几种（JDK1.7 Update 14之后）：连线之间的收集器表示他们可以配合使用。

1. Serial收集器（复制算法）：

       serial收集器是一个单线程收集器，单线程不仅仅指的是通过一个CPU或一个线程去完成垃圾的收集工作。而且垃圾收集器在工作的时候必须暂停所有的应用线程，知道垃圾收集完成。这就是臭名昭著的“stop the world”。由于Serial是单线程的，没有线程带来的开销，专心做垃圾回收，因此它简单高效，在桌面应用中，分配给虚拟机的内存一般不会很大，停顿时间一般在几十毫秒以内。只要回收不频繁，就不影响用户体验。因此采用Serial收集器是一个不错的选择，它是虚拟机在Client模式下的默认新生代收集器。

2. ParNew收集器（复制算法）：

       ParNew收集器其实是Serial收集器收集器的多线程版本，它是Server模式下的虚拟机首选的新生代收集器。其中一个与性能无关的原因是除了Serial收集器，只有它能够与CMS收集器配合使用。
       ParNew收集器在单CPU的情况下，它的效率并不比Serial收集器的效率高，甚至由于线程的开销，ParNew收集器在两个CPU的环境中的效率也不一定比Serial收集器的高。但是随着CPU核数的增加，ParNew能够重复利用系统的资源，回收效率也随之提高。

3. Parallel Scavenge收集器（复制算法）

       Parallel Scavenge收集器也是多线程收集器，但是它的关注点和ParNew等多线程收集器是不一样的，ParNew关注的是垃圾回收时，用户线程的停顿时间，即需要将对用户线程的影响降到最低。而Parallel Scavenge收集器关注点是吞吐量参数。吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)。Parallel Scavenge收集器主要目的是将吞吐量最大化，实现CPU资源的最大化利用。不关注体验效果，适合于处理后台的数据。

4. Serial Old收集器（标记-整理算法）

       Serial Old是Serial的老年代收集算法，他也是采用单线程进行垃圾收集的，适用于Client模式下的虚拟机进行垃圾回收。在Server模式下，Serial Old主要有两种用途：1. 在JDK 1.5以及之前的版本中与Parallel Scavenge配合工作。 2. 作为CMS的后备预案，当CMS在收集器发生Concurrent Mode Failure时使用。示意图参考Serial收集器示意图。

5. Parallel Old收集器（标记-整理算法）

       Parallel Old是Parallel Scavenge收集器的老年代收集器，这个是JDK1.6 出的收集器，在此之前Parallel Scavenge收集器在工作的时候，老年代收集器只能选择Serial Old。由于老年代收集器Serial Old在服务器应用性能上的”拖累“，使用Parallel Scavenge收集器也未必能实现吞吐量最大化的效果，由于单线程的老年代收集中无法充分利用服务器多CPU的处理能力，在老年代很大且硬件比较高级的环境中，这种组合不一定比对上ParNew和CMS的组合。
直到Parallel Old收集器的出现，在CPU敏感的场合，优先考虑使用Parallel Scanvenge收集器和Parallel Old收集器配套工作。

6. CMS（Concurrent Mark Sweep）收集器（标记-清理算法）

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

       CMS收集器是以获取最短回收停顿时间为目标的收集器。目前很大一部分java应用集中在互联网站或B/S系统的服务器上，这类应用重视响应速度，希望系统停顿时间最短，给用户带来最好的体验的服务器而言，CMS非常符合这类应用的需求。

CMS的运行过程分为以下4个步骤：

• 初始标记（STW）（CMS initial mark）：只是标记一下GC Roots能直接关联到的对象，速度很快
• 并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程
• 重新标记（STW）（CMS remark）：为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对像的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但是远比并发标记的时间短。
• 并发清除（CMS concurrent sweep）：清理可回收的内存
  由于整个过程耗时最长的并发标记和并发清理过程都是和用户线程一起并发执行的，所以总体上而言，CMS的整个收集过程是和用户一起并发执行的。

CMS优点：并发收集、低停顿
CMS缺点：

• CMS收集器对CPU资源非常敏感。CMS默认启动的回收线程数是（CPU数量+3）/4
• CMS收集器无法处理浮动垃圾（Floating Garbage）。由于CMS并发清理阶段，用户线程还在运行，运行期间产生的垃圾由于并没有标记，因此无法回收，只能等到下一次垃圾收集的时候进行回收，称之为“浮动垃圾”。因此在进行CMS回收的时候需要预留一部分内存满足程序的需要，如果这部分内存无法满足程序的需要，那就会出现Concurrent Mode Failure失败，此时虚拟机将会启动后备与预案，采用Serial Old收集器回收老年代，这样会导致更长时间的停顿。
• CMS采用“标记-清除”算法，在垃圾收集清理结束之后会产生大量的内存碎片，如果在分配大对象的时，无法找到连续的内存空间分配给大对象，此时不得不重新触发一次Full GC