笔记--垃圾收集器

1 Serial收集器

（1）最基本、发展历史最悠久的收集器

（2）单线程收集器，只会用一条收集线程去完成垃圾收集工作，同时它在进行垃圾收集的时候有，其它所有的工作线程必须暂停

优点：简单高效，对于单CPU的环境，没有线程交互的开销

应用场景：桌面程序，因桌面程序新生代空间小，虽收集需要停顿，但收集速度相当快

Serial/Serial Old收集器的运行过程

2 PerNew收集器

（1）本质上时多线程版本的Serial

（2）除了Serial收集器外，只有它能和CMS搭配工作

应用场景：Server模式下的虚拟机中首选的新生代收集器，除了与性能相关的原因外，还有就是（2）中提到的作用

PerNew/Serial Old工作示意图

3 Parallel Scavenger收集器

（1）新生代收集器，使用复制算法，并行的多线程收集器

（2）该收集器的目标是达到一个可控制的吞吐量(Throughput)。吞吐量=运行用户代码的时间/（运行用户代码的时间+垃圾收集的时间）

（3）可设置吞吐量以及GC停顿时间

（4）GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的

4 Serial Old收集器

（1）Serial收集器的老年代版本，单线程收集器，使用标记整理算法

应用场景：

Client模式下使用

在Server模式下应用一种用途时在.JDK1.5以及之前的版本中与Parallel Scavenger收集器搭配使用；另一种用途是作为CMS的后备预案，在并发收集发生Concurrent Mode Failure 时使用。

5 Parallel Old收集器

（1）Parallel Scavenger的老年代版本，使用多线程和“标记-整理”算法

应用场景：

在注重吞吐量以及CPU资源敏感的场合，都可以优先考虑Parallel Scavenger和Parallel Old收集器。

Parallel Scavenger和Parallel Old收集器工作过程如下

6 CMS收集器

（1）是一种以获取最短回收停顿时间为目标的收集器

（2）基于“标记-清除算法实现”，整个过程分为四步实现：

          初始标记(CMS initial mark)：仅仅只是标记一下GC Roots能直接关联到的对象，很快
          并发标记(CMS concurrent mark)：进行GC Roots Tracting的过程
          重新标记(CMS remark)：修正并发标记期间因应用程序继续运作而导致标记产生变动的那一部分对象的标记记录，时间比初始标记阶段稍长些，但远比并发标记时间短
          并发清除(CMS concurrent sweep)

（3）CMS收集器对CPU资源非常敏感（其实，面向并发设计的程序都对CPU资源比较敏感），在并发阶段，它虽然不会导致用户线程停顿，但是会占用一部分线程（或者说是CPU资源）而导致程序变慢，总吞吐量会降低。CMS默认启动的回收线程是（CPU+3）/4，所以当CPU在4个以上时。并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是在CPU不足四个时，CMS对用户程序的影响就可能变得很大。

（4）可以启用“增量式并发收集器”，但该选项已经被声明为“Deprecated”

（5）无法处理“浮动垃圾”，CMS收集器当老年代使用了68%（JDK1.6前，在之后该值已经被设置为92%，可调节）的空间后就会被激活，以保证浮动垃圾不会填满老年代，如果CMS运行期间预留的内存无法满足程序需要，就会出现一次“Concurrent Mode Failure”失败，这时虚拟机就会启动后备预案：临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样就会导致停顿时间变长。

（6）由于CMS是使用”标记-清除“算法，这样就会导致大量空间碎片产生，这时就会再次启动一次Full GC。为了解决这个问题,CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数(默认就是开启的),用于在CMS收集器顶不住要进行FullGC时开启内存碎片的合并整理过程,内存整理的过程是无法并发的,空间碎片问题没有了,但停顿时间不得不变长。虚拟机设计者还提供了另外一个参数-XX:CMSFullGCsBeforeCompaction,这个参数是用于设置执行多少次不压缩的Full GC后,跟着来一次带压缩的(默认值为0,表示每次进入FullGC时都进行碎片整理)。

应用场景：

集中在互联网网站或者B/S系统的服务端上的Java应用，因为这类应用尤其注重服务的响应速度

7 G1收集器

（）面向服务端应用的收集器

（）利用多个CPU缩短“Stop The World”的时间，其它收集器原本需要停顿Java线程执行GC操作，G1收集器仍然可以通过并发的方式让Java程序继续执行

（）G1不需要采用其它收集器配合就可以独立管理整个GC堆，但它仍然可以采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的对象，即仍保留分代收集的方式

（）空间整合：和CMS的“标记--整理”算法不同，从整体看G1是基于该算法实现，但从局部上看来时基于复制算法实现，并且不会产生空间碎片

（）具有可预测停顿性。G1除了像CMS那样追去低停顿，当与此同时还能建立可预测的停顿时间模型，能让使用者明确制定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超过N毫秒

（）Java堆的内存布局和其它收集器有较大差别，它将整个Java堆划分成多个大小相等的独立区域（Region），虽然仍有老年代新生代的概念，但新生代老年代不再是物理隔离的，而是一部分Region的集合。

（）G1跟踪各个Region里面的垃圾堆积的价值大小（回收所获得的空间大小以及回收所需要时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region，因此就实现了可预测的停顿时间模型

（）一个对象分配在某个Region并非只能被本Region中的其它对象使用，而是可以与整个Java堆任意的对象发生引用关系。

（）虚拟机使用Remember Set来避免在对一个Region进行回收的时候进行全堆扫描，G1中的每个Region都有一个与之相对应的Remember Set。当程序在对Reference类型的数据进行写操作的时候，虚拟机会产生一个Writer Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之中，如果是，便通过CardTable把相关的引用信息记录到被引用的对象所属的Region的Remember Set之中，当进行内存回收时，就在GC根节点的枚举范围加入Remember Set即可保证不对全堆进行扫描也不会有遗漏。

G1收集器的运作可以分为以下几个步骤（不计算维护Remember Set的操作）：

初始标记(Initial Marking)
并发标记(Concurrent Marking)
最终标记(Final Marking)
筛选回收(Live Data Counting and Evacuation)