2020年腾讯云KonaJDK开源贡献总结

导语：在2020年发布的 JDK15 中，腾讯成为国内厂商历史首位 Notable 贡献者，全球贡献第五。

时光飞逝，一转眼，2020年已经结束，自2019年11月KonaJDK开源，也已超过一年。在过去的这一年里，KonaJDK不断提升，锐意进取，为腾讯内部及外部云上客户提供了稳定的Java运行环境。关于KonaJDK服务腾讯及云业务，我们已经在《KonaJDK 赋能云上 Java 新生态》一文中做了表述。与此同时，2020年我们也积极参与了OpenJDK开源社区贡献。2021新年伊始，我们以腾讯云JDK工具提升方面的贡献为例，总结2020年腾讯KonaJDK参与社区的工作。

Serviceability

并行堆扫描

在JDK内存分析工具中， Jmap是最为常用的一种，其中 jmap -histo工具会对java堆进行遍历，统计每一个对象所属的类型，最后会给出这样一个数据：

这些数据展示了每个类存在的对象数，以及这些对象一共占据的内存大小。此类信息对于java堆使用情况统计，内存泄漏问题分析都非常有用。

但是在实际使用中，我们发现 jmap 的一次使用要消耗很长时间。例如在笔者的开发环境上，用Jmap -histo <pid> 扫描一个包含6GB对象的java堆,要耗费4秒左右的时间。而在一些超大堆的场景下，如大数据业务，由于 jmap 在运行过程中需要暂停 Java 业务线程，所以可能会出现一次 jmap 发生导致 Java 进程无响应，从而主备结点切换，最终造成业务系统抖动。

经过调研，我们对jmap -histo原理进行了分析，并做了并行化优化，如下图

在具体实现上，虽然我们针对的是jmap这个工具，但实际上更多的修改是在GC方面，针对不同的GC算法，堆的布局不一样，也需要采用不同的并行方式来适配。例如：

ParallelScavenge 按照不同的分代空间进行并行扫描
G1 按照不同的region进行并行扫描
ZGC与ShenandoahGC 基本上是实现了一个并行的marking机制

基于不同的实现方法，优化效果也会不一样，但总体上达到了2-8倍的并行堆扫描速度提升。下图是同样机器上针对G1GC堆的扫描测试结果（-Xmx8g，堆中对象达到6GB）：

目前，对于不同GC的patch都已经提交到社区并被接收。用户也很快会在KonaJDK8上看到相应的功能，包括对CMS堆的支持。

gzipped heap dump

在实际业务中，根据运维人员的反馈，我们发现jvm提供的heap dump功能存在一定的缺陷——dump的数据文件非常大，在网络带宽受限的情况下难以传输，非常不便。通过参与社区的研发，我们发现最近开源社区中对于jcmd增加了Gzipped heap dump支持。但是对于其他常用heap dump工具如jmap、jhsdb 等都没有增加相应支持，并且我们也没有观察到社区在这方面的计划。因此，作为社区的一员，同时为了解决我们运维人员以及云业务用户在使用上的痛点，我们对jmap、jhsdb等工具添加了compressed heap dump的支持。目前针对jmap的patch已经合入社区，针对jhsdb的patch由于需要变动heapdump的实现，社区还在review中，我们会持续跟进。

下图是使用jmap -dump <pid>与jmap -dump:gz=1 <pid> 在相同测试进程，相同堆占用情况下得到的heap dump文件，文件大小压缩了7倍左右：