JVM学习笔记——垃圾回收器

经典收集器与垃圾分代之间的关系

新生代收集器：Serial、ParNew、Parallel Scavenge
老年代收集器：Serial Old、Parallel Old、CMS
整堆收集器：G1

如何查看默认回收器

-XX:+PrintCcommandLineFlags 查看命令行相关参数，包括垃圾收集器
使用命令行指令：jinfo -flag相关垃圾收集器参数 进程ID

Serial回收器：串行回收

serial收集器作为HotSpot中Client模式下的默认新生代垃圾收集器。
Serial收集器采用复制算法、串行回收和“stop-the-word”机制的方式回收内存。
除了年轻代之外，serial收集器还提供执行与老年代垃圾收集的Serial old收集器，Serial Old收集器同样采用了串行回收和“stop the word”机制，只不过内存回收算法使用的是标记——压缩算法。
serial old是运行在client模式下默认的老年代的垃圾收集器。
serial old在server模式下主要有两个用途：1、新生代的parallel scavenge配合使用 2、作为老年代cms收集器的后备垃圾收集方案

这个收集器是一个单线程收集器，但他的单线程并不是说他仅仅使用一个cpu或一条收集线程完成垃圾收集，重要的是进行垃圾收集时必须暂停其他所有的工作线程，直至收集结束（stop the world）

这种垃圾收集器了解即可，现在已经不用串行的了，而且在限定单核cpu才可以用，现在都不是单核了。
对于交互强的应用而言，这种垃圾收集器是不能接收的。

ParNew回收器：并行回收

ParNew收集器除了采用并行回收的方式执行内存回收外，和Serial之间几乎没有任何区别，ParNew收集器在年轻代也是采用复制算法、stop the world机制

parnew和serial哪个效率更高

在多cpu环境下，由于可以充分利用多cpu、多核心等物理硬件资源有事，可以更快的完成垃圾收集，提升程序的吞吐量。
但是在单个cpu环境下parnew比serial收集器效率低，虽然serial收集器基于串行回收，但是由于cpu不需要频繁切换线程，因此可以有效避免线程交互产生的额外开销

除serial外，目前只有parnew gc能和cms收集器配合工作

Parallel Scavenge回收器：吞吐量优先

parallel Scavenge和parNew一样采用了复制算法、并行回收、stop the world 机制

那么parallel收集器的出现是否多此一举

和ParNew收集器不同，Parallel Scavenge收集器的目标则是达到一个可控制的吞吐量，他被称为吞吐量有限的垃圾收集器
自适应调节策略也是Parallel Svavenge和ParNew的一个重要区别

高吞吐量可以高效的利用cpu时间，尽快完成程序的运行任务，主要适合在后台运算而不需要太多交互的任务。 因此，常见在服务器环境中使用。例如，那些执行批量处理、订单处理、工资支付、科学计算的应用程序

Parallel收集器在1.6时提供了用于执行老年代垃圾收集的parallel old收集器，来替代serial old收集器

parallel old收集器采用了标记-压缩算法，但同样也是基于并行回收和stop the word

-XX:ParallelGCThreads 设置年轻代并行收集器的线程数
-XX：MaxGCPauseMillis 设置垃圾收集器最大停顿时间

CMS回收器：低延迟

这款收集器时hotspot中第一款真正意义上的并发收集器，第一次实现了垃圾收集线程与用户线程同时工作。
cms收集器关注点时尽可能缩短垃圾收集时用户线程停顿时间，停顿时间越短就越适合与用户交互的程序，良好提升用户体验
目前很大一部分java应用集中在互联网站或者B/S系统的服务端上，这类应用尤其重视响应速度，希望停顿时间最短。
cms的垃圾收集算法采用标记-清除算法，也会stop the word

不幸的是，cms作为老年代的收集器，无法与新生代收集器Parallel Scavenge配合工作，只能选择ParNew或者Serial中的一个。

执行过程

初始标记：所有工作线程都会因为stop the word出现短暂暂停，这个阶段的主要任务仅仅只是标记出GC Roors直接关联到的对象。一旦标记完成之后会回复之前被暂停的所有应用线程，由于直接关联对象比较小，所以这里速度非常快

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

重新标记：由于并发标记阶段中，程序的工作现场会和垃圾收集线程同时或者交叉运行，为了**修正并发标记期间，因用户线程继续运作而导致标记产生变动的那一部分对象的标记记录，**这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也比并发标记时间短

并发清除：**清理删除掉标记阶段的已经死亡的对象，释放内存空间。**由于不需要移动存活对象，所以这个阶段也是可以与用户线程并发执行的

CMS的利与弊

尽管CMS采用的是并发收集，但是在其初始化标记和再次标记这两个阶段仍然需要执行stop the word机制暂停程序中的工作线程，不过暂停时间并不会太长，因此可以说明目前所有的垃圾收集器都做不到完全不需要stop the word，只能尽力缩短暂停时间

由于最耗费时间的并发标记与并发清除阶段都不需要暂停工作，所以整体的回收是底停顿的

另外，由于在垃圾收集阶段用户线程没有中断，所以在cms回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此cms收集器不能像其他收集器哪有等到老年代几乎被填满再进行收集，而是当堆内存使用率达到某一阈值时便开始进行回收，以确保应用程序再cms过程中有足够的空间支持应用运行。要是cms运行期间预留的内存无法满足需要，就会出现一次concurrent mode failure失败，这时虚拟机将启动后备预案，临时启用serial old收集器来进行老年代垃圾收集，这样停顿时间就长了。

CMS收集器的垃圾收集算法采用的是标记-清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的对象所占用的内存空间极有可能是不连续的，不可避免的产生内存碎片。那么cms在为新对象分配空间时将无法使用指针碰撞计数，只能采用空闲列表执行内存分配

那么cms为什么不用标记压缩算法呢？

因为并发清理阶段用户线程还在运行，而标记压缩算法需要调整对象的位置，会影响用户线程的执行

优点

并发收集
低延迟

缺点

会产出内存碎片
对cpu资源非常敏感：在并发阶段，他虽然不会导致用户停顿，但是会因为占用一部分线程导致程序变慢，总吞吐量下降
无法处理浮动垃圾：在并发标记阶段如果产生新的垃圾对象cms无法对这些对象进行标记，最终导致这些新垃圾没有被及时回收

serial gc、parallel gc、concurrent mark sweep gc这三个gc有什么不同呢？

最小化的使用内存和并行开销，选择serial gc
最大化应用程序吞吐量 parallel gc
最小化停顿时间 cms gc

G1回收器：区域分代式

这是一款面向服务端应用的垃圾收集器，主要针对配备多核cpu及大容量内存的机器，以极高的概率满足GC停顿时间的同时，还兼备高吞吐的特性。
是jdk9以后的默认垃圾收集器，被官方称为全功能的垃圾收集器

并行与并发

并行性：在G1回收期间，可以有多个gc线程同时工作，有效利用多核计算能力。此时用户现场stw
并发性：g1拥有与应用程序交替执行的能力，部分工作可以和应用程序同时执行。因此，一般来说，不会在整个回收阶段发生完全堵塞应用程序的情况

分代收集

从分代上看G1仍然属于分代型垃圾回收器，他会区分年轻代和老年代，年轻代依旧有eden区和survivor区。但从堆的结构上看，他不要求整个Eden区、年轻代或者老年代是连续的，也不再坚持固定大小和固定数量
将堆空间分为若干区域（如下图），这些区域中包含了逻辑上的年轻代和老年代
和之前的各类回收器不同，他同时兼顾年轻代和老年代。

空间整合

cms：标记清除算法、内存碎片、若干次gc后进行一次碎片整理
g1将内存划分为一个个的region。内存回收时以region作为基本单位的**，Region之间是复制算法，但整体可看作是标记-压缩**，两种算法都可以避免内存碎片。这种特性有利于程序长时间运行，分配大对象时不会因为无法找到连续内存空间而提前出发下一次gc，尤其是java堆非常大的时候，g1优势更加明显

可预测的停顿时间模型

能让使用者明确指定一个长度为m好眠的时间段内，消耗垃圾收集上的时间不超过n秒

由于分区原因，g1可以只选取部分区域进行回收，这样缩小了回收范围，对于全局停顿的情况也能得到很好的控制
g1跟踪哥哥region里面的垃圾堆积的价值大小（回收所获得的空间大小及回收所需时间的经验值），在后台维护一个优先列表，每次根据允许的收集时间，有限回收价值最大的region。保证g1在有限的时间内可以获得尽可能高的收集效率

分区Region：化整为零

使用g1收集器时，他将整个java堆划分为2048个大小相同的Region，每个Region快大小根据堆空间的实际大小而定，整体被控制在1mb到32mb之间，且为2的n次幂，既1mb、2mb、4mb、8mb。所有Region大小相同，且jvm生命周期不会改变。
一个region可能属于eden、survivor或者old内存区域。但是一个region只可能属于一个角色。途中e表示region属于eden区，s表示survivor区，o表示old区。空白表示未使用的内存空间
g1还能加了一个新的内存区域叫humongous区，主要存储大对象，如果超过region的50%就放到H

设置h的原因：对于堆中大对象默认会分配到老年代，但是如果是一个短期存在的大对象会堆垃圾收集器造成负面影响。为了解决这个问题，g1划分了一个humongous区专门存放大对象，**如果h区装不下一个大对象，那么g1会寻找连续的h区来存储。**为了能找到连续的h区，有时候不得不启动full gc。g1的大多数行为都把h区作为老年代的一部分来看待

G1回收的三个环节

年轻gc（young gc）

老年代并发标记过程（concurrent marking）

混合回收（mixed gc）

如果需要单线程，独占式，高强度full gc还是继续存在的，它针对gc的评估失败提供一种失败保护机制，即强力回收

应用程序分配内存，当年轻代的eden区用尽时开始年轻代回收；g1年轻代手机阶段是一个并行的独占式收集器。再年轻代回收器，g1 gc暂停所有应用程序线程，启动多线程执行年轻代回收，然后从年轻代区间移动存活对象到servivor区间或者老年区间，也有可能两个区间都会设计

当对内存使用达到一定值（默认45%），开始老年代并发标记过程

标记完成马上开始混合回收过程，对于一个混合回收器，g1 gc从老年区间移动存活对象到空闲区间，这个空闲区间也就称为老年代的一部分，和年轻代不同，老年代的g1回收器和其他gc不同，g1的老年代会收取不需要整个老年代回收，一次只扫描、回收以下部分老年代的region就可以。同时，这个老年代的region是和年轻代一起被回收的

比如：一个web服务器，java进程对打堆内存为4g，每分钟相应1500个请求，每45秒回新喷配大约2g内存，g1每45秒进行一次年轻代回收，每31小时整个堆的使用率达到45%，会开始老年代并发标记过程，标记完成后开始四到五次的混合回收

G1回收器垃圾回收过程：Remembered Set

一个对象被不同区域引用的问题
一个region不可能是鼓励的，一个Region中的对象可能被其他任意region中对象引用，判断对象存活时，是否需要扫描整个java堆才能保证准确？
再其他的分代收集器，也存在这样的问题（g1更加突出）
回收新生代也不得不同时扫描老年代
这样的话会降低minor gc的效率

解决办法：
无论g1还是其他分代收集器，都是使用remembered set避免全局扫描
每个region都有一个对应的remembered set
每次reference类型数据写操作时，都会产生一个write barrier暂时中断操作
然后检查将要写入的引用指向对象是否和该reference类型数据再不同的region（其他收集器：检查老年代对象是否引用了新生代对象）
如果不同，通过cardtable把相关引用信息记录到引用指向对象的所在region对应的remembered set中
当进行垃圾收集时，再gc根节点的枚举范围加入Remembered set ，就可以保证不进行全局扫描，也不会有遗漏

每个region都有一个小本本，谁引用我我就记一下（如图中粉色）

G1回收过程一：年轻代GC

扫描根

根指的是static遍历指向的对象，正在执行的方法调用链条上的局部变量等。根引用联通Rset（Remembered Set）记录的外部引用作为扫描存活对象的入口

更新Rset

处理dirty card queue（脏卡表）中的card，更新Rset。此阶段完成后，Rset可以准确的反映老年代堆所在的内存分段中对象的引用

对于应用程序的引用赋值语句Object.field = object，jvm会再之前和之后指向特殊的操作以在dirty card queue中存一个保存了对象引用信息的card。再年轻代回收的时候会对Dirty card queue中所有card进行处理，以更新rset，保证Rset实时准确的反映引用关系

为什么不在引用赋值语句处直接更新Rset呢，这是为了性能需要，Rset的处理需要线程同步，开销会很大，使用队列性能会好很多

处理Rset

识别被老年代对象指向的Eden中的对象，这些被指向的Eden中的对象被认为是存活对象

复制对象

此阶段，对象树被遍历，Eden区内存段中存活的对象会被复制到Survivor区中空的内存分段，survivor区内存段中存活的对象如果年龄未达到阈值，年龄会加一，达到阈值会被复制到old中空内存分段，如果survivor空间不足，eden部分数据会直接进行老年代空间

处理引用

处理soft，weak，phantom，final，jni weak等引用。最终eden空间数据为空，gc停止工作，而目标内存中的对象都是连续存储的，没有碎片，所以复制过程可以达到内存整理效果，减少碎片

G1回收过程二：并发标记过程

初始标记阶段

标记从根节点直接可达的对象。整个阶段是stw的，并且会触发一次年轻代gc

根区域扫描

G1 gc扫描survivor区直接可达的老年对区域对象，并标记被引用的对象，这一过程必须在young gc之前完成

并发标记

再整个堆中进行并发标记（和应用程序进行并发指向），此过程可能会被young gc中断，再并发标记阶段，若发现区域悐中所有对象都是垃圾，这个语句会被立即回收。同时，并发标记过程中，会计算每个区域的对象或许（区域中存活对象的比例）

再次标记

由于应用程序持续进行，需要修正上一次的标记结果。是stw的，g1中采用了比cms更快的初始快照算法：snapshot-at-the-beginning

独占清理

计算哥哥区域的存活对象和gc回收比例，并进行排序。识别可以混合回收的对象，为下一阶段做铺垫，是stw的

并发清理阶段

识别并清理完全空闲的区域

G1回收过程三：混合回收

当越来越多的对象晋升到老年代old region时为了，避免堆内存被耗尽，虚拟机会触发一个混合的垃圾收集器，既Mixed gc ，该算法并不是一个old gc，除了回收整个young region，还会回收一部分的old region。这里需要注意：是一部分老年代，而不是全部老年代。可以选择那些old region进行回收，从而可以堆垃圾回收的耗时进行控制，也要值得注意的是mixed gc并不是full gc

G1回收可选的过程四：full gc

g1初衷就是要避免full gc。但是如果上述方式不能正常工作，g1 ** 会停止应用程序的指向（stw），使用单线程**的内存回收算法进行垃圾回收，性能会非常差，停顿时间会很长
要避免full gc，一旦发生需要进行调整，什么时候会发生full gc呢？比如堆内存太小，当g1再赋值存活对象的时候没有空的内存分段使用，否则会退回到full gc，这种情况可以通过增大内存解决

导致full gc 的原因可能有两个：
evacuation的时候没有足够的to-space来存放晋升的对象
并发处理过程完成之前空间耗尽

G1回收器优化建议

• 年轻代大小：
  避免使用-Xmn或- XX：NewRatio等相关选项显示设置年轻代大小
  固定年轻代的大小会覆盖暂停事件目标
• 暂停事件目标不要过于苛刻
  G1 GC的吞吐量目标是90%的应用程序事件和10%的垃圾回收时间
  评估G1 GC的吞吐量时，暂停事件目标不要太苛刻。目标太过严苛表示你愿意承胜更多的垃圾回收开销，而这些会直接影响到吞吐量

经典垃圾回收器总结

怎么选择垃圾收集器

• 有限调整堆的大小让jvm自适应完成
• 如果内存小雨100M，使用权串行收集器
• 如果是单核、单机程序，并且没有停顿时间的要求，串行收集器
• 如果是多cpu、需要高吞吐量、允许停顿时间超过1秒，选择并行或者jvm自己选择
• 如果是多cpu、追求停顿时间，需快速响应（比如延迟不超过1秒），使用并发收集器。官方推荐g1，性能高，现在互联网项目基本都是g1

GC日志分析

参数：

• -XX:+PrintGC 输出GC日志
• -XX:+PrintGCDetails 输出GC的详细日志
• -XX"+PrintGCTimeStamps 输出GC时间戳（以基准时间的形式）
• • XX:+PrintGCDateStamps 输出GC的时间戳（以日期的形式，如2013-05-04T20:51:15.234+0800）
• • XX:+PrintHeapAtGC 在进行GC前后打印出堆堆信息
• -Xloggc：…/logs/gc.log 日志文件的输出路径

日志补充说明

• “[GC"和”[Full GC"说明了这次垃圾回收的停顿类型，如果有“Full”则说明GC发生了“Stop The World”
• 使用Serial收集器在新生代的名字是Default NewGeneration，因此显示的是"[DefNew"
• 使用Parallel Scavenge 收集器在新生代的名字是"[PSYoungGen“
• 老年代的手机和新生代道理一样，名字也是收集器决定的
• 使用G1收集器的话，会显示为“garbage-first heap”
• Allocation Failure：表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了
• [PSYoungGen: 5986k->696k(8704k)] 5986k->704k(9216k)：中括号内：GC回收钱年轻代大小，回收后大小（年轻代总大小）。括号外：GC回收钱年轻代和老年代大小，回收后大小，（年轻代和老年大总大小）
• user代表用户态回收耗时，sys内核态回收耗时，rea实际耗时。由于多核原因，时间总和可能会超过real时间

YoungGC

FullGC

GC日志分析工具

日志输出语句：

-Xloggc：…/logs/gc.log 日志文件的输出路径

在线分析工具：GCEasy

上传日志文件之后直接在线分析

离线日志分析：GCviewer

上传日志文件