导语：在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
经过调研，我们对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
同样，我们目前正在将这一特性引入KonaJDK8中，用户很快会在KonaJDK8与腾讯云产品中看到相应的支持。
2020年腾讯在OpenJDK社区对外贡献小结
2020年， 腾讯KonaJDK团队作为OpenJDK社区的新成员，全年贡献70多个commits，主要是HotSpot(JIT、Runtime和GC)、SVC、Core Libraries和Infrastucture等领域，总代码修改量2000+行。
其中比较重要的包括：HotSpot核心模块9个patch、Vector API AVX512向量支持 6个patch、map大堆Heap Inspection并行加速优化4个。
在2020年发布的 JDK15 中， 腾讯 成为国内厂商历史首 位 Notable 贡献者 ， 全球贡献第五 。
以上只是腾讯云KonaJDK团队在2020年作为OpenJDK社区新同学的第一份答卷。 在2021年，我们会更加努力，保障腾讯及客户Java业务高效稳定的同时，将我们的经验进一步输出到社区，与社区共建更好的Java生态！
《不要再乱下载JDK了：Elasticsearch在国产化ARM环境下的首个大坑》
扫描下方二维码关注本公众号，
了解更多微服务、消息队列的相关信息！
戳原文，了解更多KonaJDK的信息
点亮在看，你最好看
本文分享自微信公众号 - 腾讯云中间件（gh_6ea1bc2dd5fd）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。
