JAVA GC收集器

目录

垃圾回收器

Serial收集器

ParNew收集器

Parallel Scavenge收集器

Serial Old收集器

Parallel Old收集器

CMS收集器

G1收集器

---

垃圾回收器

在java程序的运行过程中会产生大量的垃圾，而这些垃圾需要相应的垃圾收集器在一定的条件下对其进行回收来保证程序的正常运行，垃圾回收器是十分重要的，关系着程序正常运行与否。收集器发展历程可以分为四个阶段：Serial收集器->Parallel收集器->CMS收集器（Concurrent Mark Sweep）->G1收集器（Garbage First）。

在进行垃圾回收时，会暂停所有的工作线程，直到垃圾回收完成，垃圾回收器的不断迭代是为了优化减少停顿时间

使用垃圾回收器，通过设置垃圾回收器参数

-XX:+UseSerialGC，虚拟机运行在Client模式下的默认值，Serial+Serial Old。

-XX:+UseParNewGC，ParNew+Serial Old，在JDK1.8被废弃，在JDK1.7还可以使用。

-XX:+UseConcMarkSweepGC，ParNew+CMS+Serial Old。

-XX:+UseParallelGC，虚拟机运行在Server模式下的默认值，Parallel Scavenge+Serial Old(PS Mark Sweep)。

-XX:+UseParallelOldGC，Parallel Scavenge+Parallel Old。

-XX:+UseG1GC，G1+G1。

Serial收集器

Serial收集器是单一线程收集器，运行在Client端,在JDK 1.3.1之前唯一的垃圾回收器。Serial收集器是最基本、历史最久的收集器，曾是新生代收集的唯一选择。他是单线程的，只会使用一个CPU或一条收集线程去完成垃圾收集工作，并且它在收集的时候，必须暂停其他所有的工作线程，直到它结束，即“Stop the World”。停掉所有的用户线程，对很多应用来说难以接受。但是它仍然是虚拟机运行在client模式下的默认新生代收集器：简单而高效（与其他收集器的单个线程相比，因为没有线程切换的开销等）。

优点：

简单高效，对于单个CPU的环境，Serial收集器由于没有线程交互的开销，

专心做垃圾回收可以获得最高的单线程收集效率

ParNew收集器

ParNew收集器是Serial收集器的多线程版本，运行在Server端

特点：

多线程进行垃圾回收、其余行为（控制参数、收集算法、stop the world、对象分配规则、回收策略）与Serial收集器完全一致，随着CPU的数量增加、对于GC时系统资源的有效利用还是很有好处的，默认开启的收集线程数与CPU的数量相同

控制参数：-XX:ParallelGCThreads 参数限制垃圾垃圾收集线程

优势：除了Serial收集器，只有他能与CMS收集器配合使用

Parallel Scavenge收集器

并行多线程收集器

新生代收集器，并行的多线程收集器。它的目标是达到一个可控的吞吐量（就是CPU运行用户代码的时间与CPU总消耗时间的比值，即 吞吐量=行用户代码的时间/[行用户代码的时间+垃圾收集时间]），这样可以高效率的利用CPU时间，尽快完成程序的运算任务，适合在后台运算而不需要太多交互的任务

特点：

达到一个可控制的吞吐量（其他线程的关注点尽可能的缩短用户线程的停顿时间），吞吐量就是CPU用于运行用户代码的时间与CPU的总消耗时间的比值，吞吐量=运行用户代码时间/( 运行用户代码时间+垃圾收集时间)

优点：

停顿时间越短，交互响应时间越快，用户体验越好

高吞吐量则是高效利用CPU时间，尽快完成程序运算任务，适合后台运算

控制参数：

-XX:MaxGCPauseMillis 控制垃圾回收最大停顿时间

-XX:GCTimeRatio 设置吞吐量大小（大于0小于100）

Serial Old收集器

Serial Old是Serial收集器的老年代版本，是一个单线程收集器、使用标记-整理算法，运行在Client端.另外还可以在Server模式下：JDK 1.5之前的版本中与Parallel Scavenge 收集器搭配使用，可以作为CMS的后备方案，在CMS发生Concurrent Mode Failure是使用

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，是一个多线程收集器、使用标记-整理算法，JDK 1.6中开始提供。Parallel Old收集器的出现，使“吞吐量优先”收集器终于有了名副其实的组合。在吞吐量和CPU敏感的场合，都可以使用Parallel Scavenge/Parallel Old组合

CMS收集器

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器，基于标记-清除算法实现。基于标记-清除算法，并发收集、低停顿，运作过程复杂，对垃圾的收集分为四步完成的，其步骤如下：

初始标记：仅仅标记GC Roots能直接关联到的对象，速度快，但是需要“Stop The World”

并发标记：就是进行追踪引用链的过程，可以和用户线程并发执行。

重新标记：修正并发标记阶段因用户线程继续运行而导致标记发生变化的那部分对象的标记记录，比初始标记时间长但远比并发标记时间短，需要“Stop The World”清除标记为可以回收对象，可以和用户线程并发执行由于整个过程耗时最长的并发标记和并发清除都可以和用户线程一起工作，所以总体上来看，CMS收集器的内存回收过程和用户线程是并发执行的。

缺点：

1、并发消耗CPU资源：并发收集虽然不会暂停用户线程，但因为占用一部分CPU资源，还是会导致应用程序变慢，总吞吐量降低。CMS的默认收集线程数量是=(CPU数量+3)/4；当CPU数量多于4个，收集线程占用的CPU资源多于25%，对用户程序影响可能较大；不足4个时，影响更大，可能无法接受。

2、无法处理浮动垃圾：并发清理阶段，工作线程和垃圾回收线程并发工作的时候，此时工作线程会不断产生新的垃圾，但是垃圾回收线程并不会去处理这些新生成的垃圾对象，需要等到下次垃圾回收的时候才会去处理，这些垃圾对象称之为：浮动垃圾 。因为有这些浮动垃圾的存在，所以老年代不能在100%使用的时候才去进行垃圾回收，否则就放不下这些浮动垃圾了。有一个参数是“-XX:CMSInitiatingOccupancyFraction”，这个参数在jdk1.6里面默认是92%，意思是老年代使用了92%的空间就会执行垃圾回收了。（在并发清除时，用户线程新产生的垃圾叫浮动垃圾）,可能出现"Concurrent Mode Failure"失败。

3、产生大量内存碎片：CMS基于"标记-清除"算法，清除后不进行压缩操作产生大量不连续的内存碎片，这样会导致分配大内存对象时，无法找到足够的连续内存，从而需要提前触发另一次Full GC动作。

G1收集器

收集器发展最前沿成果之一，可以运行与服务端和客户端

特征：

并行与并发：能充分利用多CPU、多核环境的硬件优势，缩短停顿时间；能和用户线程并发执行。

分代收集：G1可以不需要其他GC收集器的配合就能独立管理整个堆，采用不同的方式处理新生对象和已经存活一段时间的对象。

空间整合：整体上看采用标记整理算法，局部看采用复制算法（两个Region之间），不会有内存碎片，不会因为大对象找不到足够的连续空间而提前触发GC，这点优于CMS收集器。

可预测的停顿：除了追求低停顿还能建立可以预测的停顿时间模型，能让使用者明确指定在一个长度为M毫秒的时间片段内，消耗在垃圾收集上的时间不超N毫秒，这点优于CMS收集器。

它为什么能做到可预测的停顿？

是因为可以有计划的避免在整个Java堆中进行全区域的垃圾收集。G1收集器将内存分大小相等的独立区域（Region），新生代和老年代概念保留，但是已经不再物理隔离。G1跟踪各个Region获得其收集价值大小在后台维护一个优先列表，每次根据允许的收集时间，优先回收价值最大的Region（名称Garbage-First的由来）；这就保证了在有限的时间内可以获取尽可能高的收集效率。

对象被其他Region的对象引用了怎么办？

判断对象存活时，是否需要扫描整个Java堆才能保证准确？在其他的分代收集器，也存在这样的问题（而G1更突出）：新生代回收的时候不得不扫描老年代？无论G1还是其他分代收集器，JVM都是使用Remembered Set来避免全局扫描：每个Region都有一个对应Remembered Set；每次Reference类型数据写操作时，都会产生一个Write Barrier 暂时中断操作；然后检查将要写入的引用指向的对象是否和该Reference类型数据在不同的 Region（其他收集器：检查老年代对象是否引用了新生代对象）；如果不同，通过CardTable把相关引用信息记录到引用指向对象的所在Region对应的Remembered Set中；进行垃圾收集时，在GC根节点的枚举范围加入 Remembered Set ，就可以保证不进行全局扫描，也不会有遗漏。

回收过程步骤（与CMS较为相似）：

初始标记：仅仅标记GC Roots能直接关联到的对象，并修改TAMS(Next Top at Mark Start)的值，让下一阶段用户程序并发运行时能在正确可用的Region中创建新对象，需要“Stop The World”

并发标记：从GC Roots开始进行可达性分析，找出存活对象，耗时长，可与用户线程并发执行

最终标记：修正并发标记阶段因用户线程继续运行而导致标记发生变化的那部分对象的标记记录。并发标记时虚拟机将对象变化记录在线程Remember Set Logs里面，最终标记阶段将Remember Set Logs整合到Remember Set中，比初始标记时间长但远比并发标记时间短，需要“Stop The World”

筛选回收：首先对各个Region的回收价值和成本进行排序，然后根据用户期望的GC停顿时间来定制回收计划，最后按计划回收一些价值高的Region中垃圾对象。回收时采用复制算法，从一个或多个Region复制存活对象到堆上的另一个空的Region，并且在此过程中压缩和释放内存；可以并发进行，降低停顿时间，并增加吞吐量。

以上各种垃圾回收器的比较

由图可知在堆中对于不同的的年代会采取不同的垃圾收集器进行回收垃圾，这也是充分利用了每个垃圾收集器的优点。