【硬刚JVM】JVM 专题二十二：垃圾回收（六）垃圾回收器 （三）

本文是对《【硬刚大数据之学习路线篇】从零到大数据专家的学习指南(全面升级版)》的JVM部分补充。

4. GC日志分析

4.1 日志分析

1.通过阅读GC日志，我们可以了解Java虚拟机内存分配与回收策略。

2.内存分配与垃圾回收的参数列表-XX：+PrintGC：输出GC日志。类似-verbose： gc

 3.-XX： +PrintGCDetails输出GC的详细日志       

4.-XX：+ PrintGCTimeStamps输出GC的时间戳(以基准时间的形式)

5.-XX：+ PrintGCDateStamps输出GC的时间戳(以日期的形式，如2013-0504m21：53：59.234+0800)      

6.-XX： +PrintHeapAtGC：在进行GC的前后打印出堆的信息

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

4.2 日志补充说明

1."[GC"和"[FullGC"说明了这次垃圾收集的停顿类型，如果有"Full"则说明GC发生了"stop-the-World"；

2.使用Serial收集器在新生代的名字是 Default New Generation，因此显示的是"[De fnew；

3.使用 Parnew收集器在新生代的名字会变成"[ParNew"，意思是"Parallel New Generation

4.使用Parallel Scavenge收集器在新生代的名字是"[Psyounggen；

5.老年代的收集和新生代道理一样，名字也是收集器决定的；

6.使用G1收集器的话，会显示为"garbage- first heap"

7.Allocation Failure

• 表明本次引起GC的原因是因为在年轻代中没有足够的空间能够存储新的数据了。

8.Psyounggen：5986K->696K(8704K)J5986K->704K(9216K)

• 中括号内：GC回收前年轻代大小，回收后大小，(年轻代总大小)
• 括号外：GC回收前年轻代和老年代大小，回收后大小，(年轻代和老年代总大小)

9.user代表用户态回收耗时，sys内核态回收耗时，real实际耗时。由于多核的原因，时间总和可能会超过real时间

4.3 堆空间日志数据解读

   

   

   

   

   

4.4 日志分析工具

1.如果想把GC日志存到文件的话，是下面这个参数：

2.可以用一些工具去分析这些gc日志：

| 常用的工具有：GCViewer、 GCEasy、 GCHisto、 GCLogViewer、Hpjmeter、 garbagecat等。

5. 垃圾回收器的新发展

5.1 概述

1.GC仍然处于飞速发展之中，目前的默认选项G1 GC在不断的进行改进，很多我们原来认为的缺点，例如串行的Full GC、 Card Table扫描的低效等，都已经被大幅改进，例如，JDK10以后，Full GC已经是并行运行，在很多场景下，其表现还略优于Parallel GC的并行Full GC实现。

2.即使是Serial GC，虽然比较古老，但是简单的设计和实现未必就是过时的，它本身的开销，不管是GC相关数据结构的开销，还是线程的开销，都是非常小的，所以随着云计算的兴起，在Serverless等新的应用场景下， Serial GC找到了新的舞台。

3.比较不幸的是CMS GC，因为其算法的理论缺陷等原因，虽然现在还有非常大的用户群体，但在JDK9中已经被标记为废弃，并在JDK14版本中移除

5.2 Shenandoah GC

1.我们还看到了引入了两个新的收集器：ZGC(JDK11出现)和Shenandoah(Open JDK12)。主打特点：低停顿时间

2.Open JDK12的Shenandoah GC：低停顿时间的GC(实验性)

3.Shenandoah，无疑是众多GC中最孤独的一个。是第一款不由Oracle公司团队领导开发的Hotspot垃圾收集器。不可避免的受到官方的排挤。比如号称OpenJDK和OracleJDK：没有区别的 Oracle公司仍拒绝在OracleJDK12中支持 Shenandoah

4.Shenandoah垃圾回收器最初由RedHat进行的一项垃圾收集器研究项目Pauseless GC的实现，旨在针对JVM上的内存回收实现低停顿的需求。在2014年贡献给OpenJDK

5.Red Hat研发Shenandoah团队对外宣称， Shenandoah垃圾回收器的暂停时间与堆大小无关，这意味着无论将堆设置为260MB还是2606B，99.9%的目标都可以把垃圾收集的停顿时间限制在十毫秒以内。不过实际使用性能将取决于实际工作堆的大小和工作负载。

6.这是Redhat七在2016年发表的论文数据，测试内容是使用E8对200GB的维基百科数据进行索引。从结果看：

• 停顿时间比其他几款收集器确实有了质的飞跃，但也未实现最大停顿时间控制在十毫秒以内的目标。
• 而吞吐量方面出现了明显的下降，总运行时间是所有测试收集器里最长的。

7.总结：

• Shenandoah GC的弱项：高运行负担下的吞吐量下降
• Shenandoah GC的强项：低延迟时间。
• Shenandoah GC的工作过程大致分为九个阶段，这里就不再赘述。在之前Java12新特性视频里有过介绍。

5.3 ZGC

1.ZGC与Shenandoah目标高度相似，在尽可能对存吐量影响不大的前提下，实现在任意堆内存大小下部可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。

2.《深入理解Java虚拟机》一书中这样定义ZGC：ZGC收集器是一款基于Region内存布局的，(暂时)不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-压缩算法的，以低延迟为首要目标的一款垃圾收集器。

3.ZGC的工作过程可以分为4个阶段：并发标记-并发预备重分配-并发重分配并发重映射等。

4.ZGC几乎在所有地方并发执行的，除了初始标记的是STW的。所以停顿时间几乎就耗费在初始标记上，这部分的实际时间是非常少的

5.在ZGC的强项停顿时间测试上，它亳不留情的将Parallel、G1拉开了两个数量级的差距。无论平均停顿、95%停顿、99%停顿、99.9%停顿，还是最大停顿时间，ZGC都能毫不费劲控制在10毫秒以内。

6.测试数据

 7.JDK14的新特性

• ZGC应用在macos上
• ZGC应用在Windows上
• JDK14之前，ZGC仅Linux才支持。
• 尽管许多使用ZGC的用户都使用类エinux的环境，但在 Windows和 macos上，人们也需要ZGC进行开发部署和测试。许多桌面应用也可以从ZGC中受益。因此，ZGC特性被移植到了Windows和macos上。
• 现在mac或Windows上也能使用ZGC了，示例如下：

5.4 Ali GC

1.AliGC是阿里巴巴JVM团队基于G1算法开发，面向大堆应用场景，指定场景下的对比：