1.6分代垃圾收集器

1. 1. 分代垃圾收集器

新生代收集器使用的收集器：Serial、PraNew、Parallel Scavenge

老年代收集器使用的收集器：Serial Old、Parallel Old、CMS

 

 

1. 1. 1. 串行收集器（Serial）

Serial收集器是Hotspot运行在Client模式下的默认新生代收集器, 它的特色是：只用一个CPU（计算核心）/一条收集线程去完成GC工做, 且在进行垃圾收集时必须暂停其余全部的工做线程(“Stop The World” -后面简称STW)。可使用-XX:+UseSerialGC打开。

虽然是单线程收集, 但它却简单而高效, 在VM管理内存不大的状况下(收集几十M~一两百M的新生代), 停顿时间彻底能够控制在几十毫秒~一百多毫秒内。

1. 1. 1. 并行收集器（ParNew）

ParNew收集器实际上是前面Serial的多线程版本, 除使用多条线程进行GC外, 包括Serial可用的全部控制参数、收集算法、STW、对象分配规则、回收策略等都与Serial彻底同样(也是VM启用CMS收集器-XX: +UseConcMarkSweepGC的默认新生代收集器)。

因为存在线程切换的开销, ParNew在单CPU的环境中比不上Serial, 且在经过超线程技术实现的两个CPU的环境中也不能100%保证能超越Serial. 但随着可用的CPU数量的增长, 收集效率确定也会大大增长(ParNew收集线程数与CPU的数量相同, 所以在CPU数量过大的环境中, 可用-XX:ParallelGCThreads=<N>参数控制GC线程数)。

1. 1. 1. Parallel Scavenge收集器

与ParNew相似, Parallel Scavenge也是使用复制算法, 也是并行多线程收集器. 但与其余收集器关注尽量缩短垃圾收集时间不一样, Parallel Scavenge更关注系统吞吐量:

系统吞吐量=运行用户代码时间/(运行用户代码时间+垃圾收集时间)

停顿时间越短就越适用于用户交互的程序-良好的响应速度能提高用户的体验;而高吞吐量则适用于后台运算而不须要太多交互的任务-能够最高效率地利用CPU时间,尽快地完成程序的运算任务. Parallel Scavenge提供了以下参数设置系统吞吐量:

Parallel Scavenge参数	描述
-XX:MaxGCPauseMillis	(毫秒数) 收集器将尽力保证内存回收花费的时间不超过设定值, 但若是过小将会致使GC的频率增长.
-XX:GCTimeRatio	(整数:0 < GCTimeRatio < 100) 是垃圾收集时间占总时间的比率
XX:+UseAdaptiveSizePolicy	启用GC自适应的调节策略: 再也不须要手工指定-Xmn、-XX:SurvivorRatio、-XX:PretenureSizeThreshold等细节参数, VM会根据当前系统的运行状况收集性能监控信息, 动态调整这些参数以提供最合适的停顿时间或最大的吞吐量

适合后台应用等对交互相应要求不高的场景。

1. 1. 1. Serial Old收集器

Serial Old是Serial收集器的老年代版本, 一样是单线程收集器,使用“标记-整理”算法

1. 1. 1. Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本, 使用多线程和“标记－整理”算法, 吞吐量优先, 主要与Parallel Scavenge配合在注重吞吐量及CPU资源敏感系统内使用；

1. 1. 1. CMS收集器（Concurrent Mark Sweep）

CMS(Concurrent Mark Sweep)收集器是一款具备划时代意义的收集器, 一款真正意义上的并发收集器, 虽然如今已经有了理论意义上表现更好的G1收集器, 但如今主流互联网企业线上选用的还是CMS(如Taobao、微店).

CMS是一种以获取最短回收停顿时间为目标的收集器(CMS又称多并发低暂停的收集器), 基于”标记-清除”算法实现, 整个GC过程分为如下4个步骤:

1. 初始标记(CMS initial mark)

2. 并发标记(CMS concurrent mark: GC Roots Tracing过程)

3. 从新标记(CMS remark)

4. 并发清除(CMS concurrent sweep: 已死对象将会就地释放, 注意:此处没有压缩)

其中1，3两个步骤(初始标记、从新标记)仍需STW. 但初始标记仅只标记一下GC Roots能直接关联到的对象, 速度很快; 而从新标记则是为了修正并发标记期间因用户程序继续运行而致使标记产生变更的那一部分对象的标记记录, 虽然通常比初始标记阶段稍长, 但要远小于并发标记时间.

CMS特色：

1. CMS默认启动的回收线程数=(CPU数目+3)4

当CPU数>4时, GC线程通常占用不超过25%的CPU资源, 可是当CPU数<=4时, GC线程可能就会过多的占用用户CPU资源, 从而致使应用程序变慢, 总吞吐量下降.

 

2.没法处理浮动垃圾, 可能出现Promotion Failure、Concurrent Mode Failure而致使另外一次Full GC的产生: 浮动垃圾是指在CMS并发清理阶段用户线程运行而产生的新垃圾. 因为在GC阶段用户线程还需运行, 所以还须要预留足够的内存空间给用户线程使用, 致使CMS不能像其余收集器那样等到老年代几乎填满了再进行收集. 所以CMS提供了-XX:CMSInitiatingOccupancyFraction参数来设置GC的触发百分比(以及-XX:+UseCMSInitiatingOccupancyOnly来启用该触发百分比), 当老年代的使用空间超过该比例后CMS就会被触发(JDK 1.6以后默认92%). 但当CMS运行期间预留的内存没法知足程序须要, 就会出现上述Promotion Failure等失败, 这时VM将启动后备预案: 临时启用Serial Old收集器来从新执行Full GC(CMS一般配合大内存使用, 一旦大内存转入串行的Serial GC, 那停顿的时间就是你们都不肯看到的了).

 

3.最后, 因为CMS采用”标记-清除”算法实现, 可能会产生大量内存碎片. 内存碎片过多可能会致使没法分配大对象而提早触发Full GC. 所以CMS提供了-XX:+UseCMSCompactAtFullCollection开关参数, 用于在Full GC后再执行一个碎片整理过程. 但内存整理是没法并发的, 内存碎片问题虽然没有了, 但停顿时间也所以变长了, 所以CMS还提供了另一个参数-XX:CMSFullGCsBeforeCompaction用于设置在执行N次不进行内存整理的Full GC后, 跟着来一次带整理的(默认为0: 每次进入Full GC时都进行碎片整理).

高并发、低停顿，追求最短GC回收停顿时间，cpu占用比较高，响应时间快，停顿时间短，多核cpu 追求高响应时间的选择

1. 1. 1. 分区收集- G1收集器

G1(Garbage-First)是一款面向服务端应用的收集器, 主要目标用于配备多颗CPU的服务器治理大内存.

- G1 is planned as the long term replacement for the Concurrent Mark-Sweep Collector (CMS).

-XX:+UseG1GC启用G1收集器.

与其余基于分代的收集器不一样, G1将整个Java堆划分为多个大小相等的独立区域(Region), 虽然还保留有新生代和老年代的概念, 但新生代和老年代再也不是物理隔离的了, 它们都是一部分Region(不须要连续)的集合.如：

每块区域既有可能属于O区、也有多是Y区, 所以不须要一次就对整个老年代/新生代回收. 而是当线程并发寻找可回收的对象时, 有些区块包含可回收的对象要比其余区块多不少. 虽然在清理这些区块时G1仍然须要暂停应用线程, 但能够用相对较少的时间优先回收垃圾较多的Region. 这种方式保证了G1能够在有限的时间内获取尽量高的收集效率.

G1的新生代收集跟ParNew相似: 存活的对象被转移到一个/多个Survivor Regions. 若是存活时间达到阀值, 这部分对象就会被提高到老年代.如图：

其特定是：

一整块堆内存被分为多个Regions.

存活对象被拷贝到新的Survivor区或老年代.

年轻代内存由一组不连续的heap区组成, 这种方法使得能够动态调整各代区域尺寸.

Young GC会有STW事件, 进行时全部应用程序线程都会被暂停.

多线程并发GC.

 

G1老年代GC特色以下:

并发标记阶段

1 在与应用程序并发执行的过程当中会计算活跃度信息.

2 这些活跃度信息标识出那些regions最适合在STW期间回收(which regions will be best to reclaim during an evacuation pause).

3 不像CMS有清理阶段.

再次标记阶段

1 使用Snapshot-at-the-Beginning(SATB)算法比CMS快得多.

2 空region直接被回收.

拷贝/清理阶段(Copying/Cleanup Phase)

1 年轻代与老年代同时回收.

2 老年代内存回收会基于他的活跃度信息.