垃圾收集器

声明：本文是学习笔记，主要学习自《深入理解Java虚拟机·JVM高级特性与最佳实践》周志明 著，并强烈推
            荐精读此书，且本文文字内容百分之九十五直接摘录自此书，如有不当欢迎指正！

---

目录

       各收集器汇总(图示)

       Serial收集器

       ParNew收集器

       Parallel Scavenge收集器

       Serial Old收集器

       Parallel Old收集器

       CMS(Concurrent Mark Sweep)收集器

       G1(Garbage First)收集器

---

如果说垃圾收集算法是内存回收的方法论，那么垃圾收集器就是内存回收的具体实现。

各收集器汇总(图示)：

说明：
       上图展示了7种作用于不同分代的收集器，如果两个收集器之间存在连线，就说明它们可以搭配使用。收集器所处的区域，则表示它是属于新生代收集器还是老年代收集器。

Serial收集器：

      Serial收集器是一个单线程的收集器。Serial收集器只会使用一个CPU、只会使用一个收集线程去完成垃圾收集和工作。Serial收集器在进行垃圾收集时，必须暂停其他所有的工作线程，直到它收集结束。

Serial收集器示意图：

ParNew收集器：

       ParNew收集器其实就是Serial收集器的多线程版本，除了使用多线程进行垃圾收集之外，其余行为包括Serial收集器可用的所有控制参数、收集算法、Stop The Word、对象分配规则、回售策略等都与Serial收集器完全一样，在实现上，这两种收集器也共用了相当多的代码。

       ParNew收集器在单CPU的环境中绝对不会有比Serial收集器更好的效果，甚至于存在线程交互的开销，还收集器在通过超线程技术实现的两个CPU的环境中都不能百分之百地保证可以超越Serial收集器。当然，随着可以使用的CPU的数量的增加，它对于GC时系统资源的有效利用还是很有好处的。它默认开启的手机线程数与CPU的数量相同，在CPU非常多的环境下，可以使用-XX:ParallelGCThreads参数来限制垃圾收集的线程数。

ParNew收集器示意图：

说明：
       PerNew收集器除了多线程收集之外，其他与Serial收集器相比并没有太多创新之处，但它却是许多运行在Server模式下的虚拟机中首选的新生代代码收集器，其中有一个与性能无关但很重要的原因是，除了Serial收集器外，目前只有它能与CMS收集器配合工作。

Parallel Scavenge收集器：

       Parallel Scavenge收集器是一个新生代收集器，他也是使用复制算法的收集器，又是并行的多线程收集器。

Parallel Scavenge收集器示意图：

       Parallel Scavenge收集器的特点是它的关注点与其他收集器不同，CMS等收集器的关注点是尽可能第缩短收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量。所谓吞吐量就是CPU用于运行用户代码的时间与CPU总消耗时间的比值(即：吞吐量 = 运行用户代码时间/(运行用户代码时间 + 垃圾收集时间))。如：虚拟机总共运行了100分钟，其中垃圾收集花掉1分钟，那吞吐量就是99%。

       Parallel Scavenge收集器提供了两个参数用于精确控制吞吐量，分别是控制最大垃圾收集停顿时间的-XX:MaxGCPauseMillis参数以及直接设置吞吐量大小的-XX:GCTimeRatio参数。

       MaxGCPauseMillis参数允许的值是一个大于0的毫秒数，收集器将尽可能地保证内存回收花费的时间不超过设定值。不过大家不要认为如果把这个参数的值设置得稍小一点就能使得系统的垃圾收集速度变得更快，GC停顿时间缩短是以牺牲吞吐量和新生代空间来换取的:系统把新生代调小一些，收集300MB新生代肯定比收集500MB快吧，这也直接导致垃圾收集发生得更频繁一些，原来10秒收集一次、每次停顿100毫秒，吞吐量为(10000ms/10100ms≈)99.01%;现在变成5秒收集一次、每次停顿70毫秒吞吐量为(5000ms/5070ms≈)98.62%。停顿时间的确在下降，但吞吐量也降下来了。

       GCTimeRatio参数的值应当是一个大于0且小于100的整数，也就是设置运行用户代码时间与垃圾收集时间的(最大)比率(即:通过设置GCTimeRatio的值来控制运行用户代码时间 / 垃圾收集时间的最大值)。如过把此参数的值设置为19，那么允许的最大GC时间就咱总时间的5%((即:1/(19 + 1))；设置此参数的值为99，就是允许最大1%(即:1/(99+1))的垃圾收集时间。

       由于与吞吐量关系密切，Parallel Scavenge收集器也经常称为吞吐量优先收集器。Parallel Scavenge收集器还有一个参数-XX:+UseAdaptiveSizePolicy，这是一个开关参数，当这个参数打开之后，就不需要手工指定新生代的大小(-Xmx)、Eden与Surivor区的比例(-XX:SurvivorRatio)、晋升老年代对象年龄(-XX:PretenureSizeThreshold)等细节参数了，虚拟机会根据当前系统的运行情况收集性能监控信息，动态调整这些参数以提供最合适的停顿时间或者最大的吞吐量，这种调节方式称为GC自适应的调整策略。自行应调节策略也是Parallel Scavenge收集器与PerNew收集器的一个重要区别。

Serial Old收集器：

       Serial Old是Serial收集器的老年代版本，它同样是一个单线程收集器，使用标记-压缩算法。这个收集器的主要意义也是在于给Client模式下的虚拟机使用。如果在Server模式下，那么它主要还有两大用途:一种用途是在JDK1.5以及之前的版本中与Parallel Scavenge收集器搭配使用，另一种用途就是作为CMS收集器的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Serial Old收集器示意图：

Parallel Old收集器：

       Parallel Old是Parallel Scavenge收集器的老年代版本，使用多线程和标记-压缩算法。在注重吞吐量以及CPU资源敏感的场合，可以优先考虑Parallel Scavenge加Parrallel Old收集器。

Parallel Old收集器示意图：

CMS(Concurrent Mark Sweep)收集器：

    CMS收集器是一种以获取最短回收停段时间为目标的收集器。CMS收集器是基于标记-清除算法实现的，整个CMS过程分为六个步骤：

1. 初始标记(CMS initial mark)：虚拟机暂停所有用户线程,只运行GC线程，由根对象扫描出所有的相关联队
                                                    形，并做出标记。此过程只会导致用户线程短暂的暂停，速度很快。

2. 并发标记(CMS concurrent mark)：恢复所有暂停的用户线程，用户线程与GC线程并发执行，GC线程对
                                                             之前标记过的对象进行扫描，进一步取得所有与标记对象有关联的对象。

3. 并发预清理(CMS concurrent Precleaning)：用户线程与GC线程并发执行，GC线程会查找所有在并发标记
                                                                            阶段新进入老年代的对象(一些对象可能从新生代晋升到老年代，
                                                                            或者有一些对象被分配到老年代)，通过重新扫描，减少下一阶
                                                                            段的工作。

4. 重新标记(CMS remark)：虚拟机暂停所有用户线程,只运行GC线程，GC线程对“并发标记”阶段被改变引用或
                                             新创建的对象进行标记。

5. 并发清除(CMS concurrent sweep)：用户线程与GC线程并发执行，GC线程对所有未标记的垃圾对象进行
                                                               清理，并且会尽量将已回收的对象的空间重新拼凑为一个整体。

6. 并发重置(CMS concurrent Reset)：重置CMS收集器的数据结构，等待下一次垃圾回收。

其中，初始标记、重新标记这两个步骤任然需要Stop The World(其余阶段收集器线程都可以与用户线程一起工作)。整个过程中耗时最长的是并发标记和并发清除过程。

CMS收集器示意图：

注：在并发阶段时，CMS默认启动的回收线程数是(CPU数量+3)/4个。

CMS收集器的优点：

       并发收集、低停顿。

CMS收集器的缺点：

• 在GC线程与用户线程并发时，虽然不会导致用户线程停顿，但是GC线程会占用一部分线程(或者说占用一部分CPU资源)而导致用户程序变慢，吞吐量降低。
  注：在并发阶段时，CMS默认启动的回收线程数是(CPU数量+3)/4个，当CPU在4个以上时，并发回收时垃圾收集
         线程占用 不少于25%的CPU资源，并且随着CPU数量的增加而减少(当CPU数量无限多时，GC线程数无限趋
         近于CPU数量的四分之一)。但是当CPU不足4个(譬如2个)时，CMS对用户程序的影响就可能变得很大，如果
         本来CPU负载就比较大，还分出一半的运算能力去只收收集器线程，就可能导致用户程序的执行舒服忽然降
         低了50%。

• CMS收集器无法处理浮动垃圾(Floating Garbage),可能出现Concurrent Mode Failure失败而导致另一次Full GC的产生。
  注：由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就会有新的垃圾不断产生，这一部分垃圾出现
          在标记过程之后，CMS无法再当次收集中处理掉它们，只好留待下一次GC时在清理掉。

 

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

G1(Garbage First)收集器：

       G1收集器是当今收集器技术发展的最前沿成果之一。G1收集器是一款面向服务端应用的垃圾收集器。HotSpot开发团队赋予它的使命是未来可以替代掉CMS收集器。

G1收集器的特点：

• 并发与并行
          G1能充分利用多CPU、多核环境下的硬性优势，使用多个CPU(CPU或CPU核心)来缩短Stop-The-World停顿的时间，部分其他收集器原本需要停顿Java线程执行的GC动作，G1收集器仍然可以通过并发的方式让Java程序继续执行。

• 分代收集
         与其他收集器一样，分代概念在G1中仍然得以保留。虽然G1可以不需要其它收集器配合就能独立管理整个GC堆，但它能够采用不同的方式去处理新创建的对象和已经存活了一段时间、熬过多次GC的旧对象以获取更好的收集效果。

• 空间整合
         与CMS的标记-清除算法不同，G1从整体来看是基于标记-压缩算法实现的收集器。从局部(两个Region之间)来看是基于复制算法实现的。这两种算法都意味着G1运行期间不会产生内存空间碎片，收集后能提供规整的可用内存。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前触发下一次GC。

• 可预测的停顿
         这是G1相对于CMS的另一大优势，降低停顿时间是G1和CMS共同的关注点，但G1除了追求低停顿外，还能建立可预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集器上的时间不得超过N毫秒，这几乎已经是实时Java(RTSJ)的垃圾收集器的特征了。

G1收集器收集时的部分相关原理：

       在G1之前的其它收集器进行收集的范围都是整个新生代或整个老年代，而G1不再是这样。在使用G1收集器时，Java堆的内存布局与其它收集器有很大的其差别，它将整个Java堆划分为多个大小相等的独立区域(Region)，虽然还保留有新生代和老年代的概念，但新生代和老年代不再是物理隔离的了，它们都是一部分Region(注:Region不必一定连续)的集合。

       G1收集器之所以能建立可预测的停顿时间模型，是因为它可以有计划地避免在整个Java对中进行全局区域的垃圾收集。G1跟踪各个Region里面的垃圾堆积的价值大小(回收所获得的空间大小及回收所需时间的经验值综合得出价值大小)，在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region。这种使用Region划分内存空间以及有优先级的区域回收方式，保证了G1收集器在优先的时间内可以获取尽可能高的收集效率。

Region之间对象引用问题：

       G1把内存化整为零的思路，理解起来似乎很容易，但其中的细节却远远没有想象中那么简单。如:Region不可能时孤立的。一个对象分配在某个Region中，它并非只能被本Region中的其他对象引用，而是可以与整个Java堆任意的对象发生引用关系。那么在做可达性判定确定对象存活的时候，岂不是还得扫描整个Java堆才能保证准确性？不需要，因为在G1收集器中，Region之间的对象引用以及其他收集器中新生代与老年代之间的对象引用，虚拟机都是使用Remembered Set来避免全堆扫描的。G1中每个Region都有一个与之对应的Remembered Set，虚拟机发现程序在对Reference类型的数据进行写操作时，会产生一个Write Barrier暂时中断写操作，检查Reference引用的对象是否处于不同的Region之间(在分代的例子中就是检查是否老年代中的对象引用了新生代中的对象)，如果是，变通过CardTable把相关引用信息记录到被引用对象所属的Region的Remembered Set之中。当进行内存回收时，在GC根节点枚举范围中加入Remembered Set即可保证不对全堆扫描也不会有遗漏。

G1收集器的运作步骤(不计算维护Remembered Set的操作的话)：

1. 初始标记(Initial Marking)
          仅仅只是标记一下GC Root能直接关联到的对象，并且修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发运行时，能在正确可用的Region中创建新对象，这阶段需要停顿线程，但耗时很短。

2. 并发标记(ConcurrentMarking)
          并发标记阶段时从GC Root开始对堆中对象进行可达性分析，找出存活的对象，这阶段耗时较长，但可与用户程序并发执行。

3. 最终标记(Final Marking)
          最终标记阶段则是为了修正在并发标记期间因用户程序继续运作而导致标记产生变动的那一部分标记记录，虚拟机将这段时间对象变化记录在线程Remembered Set Logs里面，最终标记阶段需要把Remembered Set Logs的数据合并到Remembered Set中，这阶段需要停顿用户线程，但是可并行GC线程，

4. 筛选回收(Live Data Counting and Evacuation)
          筛选回收阶段首先对各个Region的回收价值和成本进行排序，根据会用所期望的GC停顿时间来制定回收计划，这个阶段其实也可以做到与用户程序一起并发执行，但是因为只回收一部分Region，时间是用户控制的，而且停顿用户线程将大幅提高收集效率，所以筛选回收阶段选择了暂停用户线程。

G1收集器示意图：

 

 

声明：本文是学习笔记，主要学习自以下书籍。

声明：由于本人是对下述资料的摘录整理，所以文章类型设置为翻译。

^_^ 如有不当之处，欢迎指正

^_^ 学习书籍(本文内容百分之九十五直接摘录自此书籍、强烈推荐阅读此书)
             《深入理解Java虚拟机·JVM高级特性与最佳实践》 周志明 著

^_^ 学习视频(本文内容百分之四出自此视频)
             51CTO学院 李兴华 JVM相关课程

^_^ 本文已经被收录进《程序员成长笔记(四)》，笔者JustryDeng