jvm 垃圾收集器

    垃圾收集器就是收集算法的具体实现，不同的虚拟机会提供不同的收集器。两个收集器之间存在连线的话就说明它们可搭配使用。 

  serial收集器：

单线程收集器，使用复制收集算法，收集时会暂停所有工作线程(stop the world)，虚拟机运行在Client模式时的默认新生代收集器。 优点是：简单高效 。 在单个CPU的环境来说，没有线程交互的开销,在client情况下的默认+首选

parNew收集器：

是serial的多线程版本，除了多条收集线程外，其余行为(控制参数、回收算法、对象分配、回首策略等)和serial收集器一样。目前是server模式下的虚拟机首选新生代收集器，目前只有parNew收集器能与cms配合使用。默认开启的收集线程与CPU数量相同

parallel Scavenge收集器：

  吞吐量：CPU用语运行用户代码的时间与CPU总消耗时间的比值。吞吐量＝运行用户代码时间／（运行用户代码时间＋垃圾收集时间）

也是使用复制算法的新生代并行多线程收集器，目标是达成一个可控制的吞吐量，因此也称为吞吐量优先收集器，更优先于任务完成速度而非用户交互。拥有空间最大垃圾收集停顿时间的-xx:MaxGCPauseMillis

参数和直接设置吞吐量大小的-XX:GCTimeRatio参数;与

parNew的区别在于GCTimeRatio参数(垃圾收集时间占总时间的比率，默认为99，大于0小于100); 可打开-xx:+UseAdaptiveSizePolicy参数来使得jvm自动调节吞吐量;

  serial old收集器：

是serial的老年代版本，也是单线程收集器，使用标记－整理算法。主要是client模式下的老年代收集器。

在jdk1.5及之前与parallel scavenge搭配使用;作为cms收集器的后备预案。在病发收集发生并发模式故障(concurrent mode failure)时使用

  parallel old收集器：

时parallel scavenge收集器的老年代版本，使用多线程和标记－整理算法。jdk1.6开始使用。以吞吐量设计的多线程收集器

cms收集器：

concurrent mark sweep；使用标记－清除算法。 目标是获取最短回收停顿时间，默认回收线程数是 (cpu+3)/4,理想应用场景时b/s架构服务器。整个回收过程只有重新标记需要暂停其他线程活动,其他过程可与用户线程一起执行;对cpu资源敏感，会因占用一部分CPU资源而导致应用程序变慢，降低吞吐量。无法处理浮动垃圾。 由于使用标记-清除算法 会产生大量磁盘碎片;

标记－清除算法步骤：

1.初始标记： 标记gc roots能直接关联到的对象

2.并发标记： 进行gc roots tracing的过程

3.重新标记：为了修正并发标记时用户继续运行而产生的标记变化，停顿时间比初始标记长，比并发标记短

4.并发清除

g1收集器：

  从整体来看基于标记－整理算法实现的收集器，不产生空间碎片，并且可以精确地控制停顿，在jdk1.7中正式投入使用.具有 并发性、分代收集、空间整合和可预测停顿的特点;可以实现在基本不牺牲吞吐量的前提下完成低停顿的回收。 将java堆划分成多个固定大小的独立区域，并且追踪垃圾堆积程度，优先回收垃圾最多的区域;