Java虚拟机垃圾回收

垃圾收集器概述

垃圾收集器是垃圾回收算法（标记-清除算法、复制算法、标记-整理算法）的具体实现，不同商家、不同版本的JVM所提供的垃圾收集器可能会有很在差别，本文主要介绍HotSpot虚拟机中的垃圾收集器。

各款经典收集器之间的关系

如果两个收集器之间存在连线，就说明它们可以搭配使用，图中收集器所处的区域，则表示它是属于新生代收集器抑或是老年代收集器。

新生代收集器：Serial、ParNew、Parallel Scavenge；

老年代收集器：Serial Old、Parallel Old、CMS；

整堆收集器：G1；

Serial收集器

特点：

单线程工作

针对新生代

采用复制算法

它进行垃圾收集时，必须暂停其他所有工作线程，直到它收集结束

 

依然是HotSpot在Client模式下默认的新生代收集器；

优于其他收集器的地方

简单高效（与其他收集器的单线程相比）；

对于单核处理器或处理器核心数较少的环境来说，Serial收集器由于没有线程交互的开销，专心做垃圾收集自然可以 获得最高的单线程收集效率。

在用户的桌面应用场景中，可用内存一般不大（几十M至一两百M），可以在较短时间内完成垃圾收集（几十MS至一百多MS）,只要不频繁发生，这是可以接受的

3、设置参数

      "-XX:+UseSerialGC"：添加该参数来显式的使用串行垃圾收集器；

ParNew收集器

ParNew垃圾收集器是Serial收集器的多线程版本。

特点

除了同时使用多条线程进行垃圾收集之 外，其余的行为包括Serial收集器可用的所有控制参数（例如：-XX：SurvivorRatio、-XX： PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、对象分配规则、回收策略等都与Serial收集器完全一致

第一次实现了让垃圾收集线程与用户线程（基本上）同时工作；

 

设置参数

"-XX:+UseConcMarkSweepGC"：指定使用CMS后，会默认使用ParNew作为新生代收集器；

"-XX:+UseParNewGC"：强制指定使用ParNew；    

"-XX:ParallelGCThreads"：指定垃圾收集的线程数量，ParNew默认开启的收集线程与CPU的数量相同；

Parallel Scavenge收集器

特点：

基于标记-复制算法实现

并行收集的多线程收集器

CMS等收集器的关注点是尽可能地缩短垃圾收集时用户线程的停顿时间，而Parallel Scavenge收集器的目标是达到一个可控制的吞吐量（吞吐量就是处理器用于运行用户代码的时间与处理器总消耗时间的比值）

高吞吐量为目标，即减少垃圾收集时间，让用户代码获得更长的运行时间；

Serial Old收集器

Serial Old是Serial收集器的老年代版本

特点：

针对老年代

单线程收集器

标记-整理算法

应用

这个收集器的主要意义也是供客户端模式下的HotSpot虚拟机使用。

如果在服务端模式下，它也可能有两种用途：

一种是在JDK5以及之前的版本中与Parallel Scavenge收集器搭配使用

另外一种就是作为CMS 收集器发生失败时的后备预案，在并发收集发生Concurrent Mode Failure时使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本

特点：

针对老年代

支持多线程并发收集

基于标记-整理算法实现

 直到Parallel Old收集器出现后，“吞吐量优先”收集器终于有了比较名副其实的搭配组合，在注重 吞吐量或者处理器资源较为稀缺的场合，都可以优先考虑Parallel Scavenge加Parallel Old收集器这个组合

CMS收集器***

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。

特点

      针对老年代

      基于"标记-清除"算法(不进行压缩操作，产生内存碎片)；           

      以获取最短回收停顿时间为目标

      并发收集、低停顿

      需要更多的内存

 执行过程分为四个步骤：

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”

1）初始标记（CMS initial mark）

初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；

2）并发标记（CMS concurrent mark）

并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；

3）重新标记（CMS remark）

重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一 些，但也远比并发标记阶段的时间短

4）并发清除（CMS concurrent sweep）

最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的

由于在整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一 起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的

 缺点：

CMS收集器对处理器资源非常敏感

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

CMS收集器无法处理“浮动垃圾”（Floating Garbage）

在并发清除时，用户线程新产生的垃圾，称为浮动垃圾；

由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待 到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。

要是CMS运行期间预留的内存无法满 足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），此时冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集， 但这样停顿时间就很长了

所以参数-XX：CMSInitiatingOccupancyFraction设置得太高将会很容易导致 大量的并发失败产生，性能反而降低

大量空间碎片

 由于CMS基于"标记-清除"算法，清除后不进行压缩操作；

空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况

Garbage First收集器（G1）

特点

并行与并发

      能充分利用多CPU、多核环境下的硬件优势

      可以并行来缩短"Stop The World"停顿时间

      也可以并发让垃圾收集与用户程序同时进行

分代收集，收集范围包括新生代和老年代    

      能独立管理整个GC堆（新生代和老年代），而不需要与其他收集器搭配

      能够采用不同方式处理不同时期的对象

      新生代和老年代不再是物理隔离，它们都是一部分Region（不需要连续）的集合

结合多种垃圾收集算法，空间整合，不产生碎片

      从整体看，是基于标记-整理算法

      从局部（两个Region间）看，是基于复制算法

      这是一种类似火车算法的实现

可预测的停顿：低停顿的同时实现高吞吐量

      G1除了追求低停顿处，还能建立可预测的停顿时间模型

      可以明确指定M毫秒时间片内，垃圾收集消耗的时间不超过N毫秒

应用场景： 

主要面向服务端应用的垃圾收集器，针对具有大内存、多处理器的机器；

最主要的应用是为需要低GC延迟，并具有大堆的应用程序提供解决方案；

在下面的情况时，使用G1可能比CMS好：

超过50％的Java堆被活动数据占用

对象分配频率或年代提升频率变化很大

GC停顿时间过长（长于0.5至1秒）

每个Region都维护有自己的记忆集，这些记忆集会记录下别的Region 指向自己的指针，并标记这些指针分别在哪些卡页的范围之内。G1的记忆集在存储结构的本质上是一 种哈希表，Key是别的Region的起始地址，Value是一个集合，里面存储的元素是卡表的索引号

由于Region数量比传统收集器的分代数量明显要多得多，因此G1收集器要比其他的传统垃 圾收集器有着更高的内存占用负担，G1至少要耗费大约相当于Java堆容量10%至20%的额 外内存来维持收集器工作。

并发标记阶段如何保证收集线程与用户线程互不干扰地运行？这里首先要解决的是用户
线程改变对象引用关系时，必须保证其不能打破原本的对象图结构，导致标记结果出现错误。

CMS收集器采用增量更新算法实现，而G1 收集器则是通过原始快照（SATB）算法来实现的。

 运行过程

初始标记

仅仅只是标记一下GC Roots能直接关联到的对象，并且修改TAMS 指针的值，让下一阶段用户线程并发运行时，能正确地在可用的Region中分配新对象。这个阶段需要 停顿线程，但耗时很短，而且是借用进行Minor GC的时候同步完成的，所以G1收集器在这个阶段实际 并没有额外的停顿。

 并发标记

从GC Root开始对堆中对象进行可达性分析，递归扫描整个堆 里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以 后，还要重新处理SATB记录下的在并发时有引用变动的对象。

最终标记

 对用户线程做另一个短暂的暂停，用于处理并发阶段结束后仍遗留 下来的最后那少量的SATB记录。

筛选回收

负责更新Region的统计数据，对各个Region的回 收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个Region 构成回收集，然后把决定回收的那一部分Region的存活对象复制到空的Region中，再清理掉整个旧Region的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

从上述阶段的描述可以看出，G1收集器除了并发标记外，其余阶段也是要完全暂停用户线程的， 换言之，它并非纯粹地追求低延迟，官方给它设定的目标是在延迟可控的情况下获得尽可能高的吞吐量

G1不是仅仅面向低延迟，停顿用户线程能够最大幅度提高垃圾收集效率，为了保证吞吐量所以才选择了完全暂停用户线程的实现方案