导语:在2020年发布的 JDK15 中,腾讯成为国内厂商历史首位 Notable 贡献者,全球贡献第五。java
时光飞逝,一转眼,2020年已经结束,自2019年11月KonaJDK开源,也已超过一年。在过去的这一年里,KonaJDK不断提高,锐意进取,为腾讯内部及外部云上客户提供了稳定的Java运行环境。关于KonaJDK服务腾讯及云业务,咱们已经在《KonaJDK 赋能云上 Java 新生态》一文中作了表述。与此同时,2020年咱们也积极参与了OpenJDK开源社区贡献。2021新年伊始,咱们以腾讯云JDK工具提高方面的贡献为例,总结2020年腾讯KonaJDK参与社区的工做。web
并行堆扫描算法
可是在实际使用中,咱们发现 jmap 的一次使用要消耗很长时间。例如在笔者的开发环境上,用Jmap -histo <pid> 扫描一个包含6GB对象的java堆,要耗费4秒左右的时间。而在一些超大堆的场景下,如大数据业务,因为 jmap 在运行过程当中须要暂停 Java 业务线程,因此可能会出现一次 jmap 发生致使 Java 进程无响应,从而主备结点切换,最终形成业务系统抖动。微信
在具体实现上,虽然咱们针对的是jmap这个工具,但实际上更多的修改是在GC方面,针对不一样的GC算法,堆的布局不同,也须要采用不一样的并行方式来适配。例如:网络
-
ParallelScavenge 按照不一样的分代空间进行并行扫描 -
G1 按照不一样的region进行并行扫描 -
ZGC与ShenandoahGC 基本上是实现了一个并行的marking机制
基于不一样的实现方法,优化效果也会不同,但整体上达到了2-8倍的并行堆扫描速度提高。下图是一样机器上针对G1GC堆的扫描测试结果(-Xmx8g,堆中对象达到6GB):架构
目前,对于不一样GC的patch都已经提交到社区并被接收。用户也很快会在KonaJDK8上看到相应的功能,包括对CMS堆的支持。app
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中,咱们会持续跟进。jvm
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个。

《不要再乱下载JDK了:Elasticsearch在国产化ARM环境下的首个大坑》

扫描下方二维码关注本公众号,
了解更多微服务、消息队列的相关信息!


本文分享自微信公众号 - 腾讯云中间件(gh_6ea1bc2dd5fd)。
若有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一块儿分享。