大数据与云计算的新引擎 – Kona JDK 11揭秘

丨导语

时间过得真快，JDK 11已经发布近两年了，大家从最开始看到ZGC、JFR等特性的眼前一亮直到今天，似乎并没有见到广泛进入生产，Java开发者的普遍疑问是：

● JDK 11有什么突出生产价值？到底有没有开箱即用的性能提升或者功能收益？

● JDK半年即一个主版本，如何充分利用前沿版本新特性，又能避免令人眼花缭乱的Java版本变化？

腾讯JDK团队针对大数据/机器学习和云计算等业务的前沿需求，正在探索新的长期支持版本Kona JDK 11，本文将对其中部分实践进行介绍，希望从生产经验的角度为大家的技术决策提供一手参考。

Kona JDK 11当前特性优化

Kona JDK 11以社区主分支的OpenJDK 11u为基础，除了保持长期支持版本的兼容性、可靠性、安全、性能等核心要素，目前重点针对以下几个突出的业务需求和痛点进行了改进：

● 向量计算优化：针对大数据/机器学习场景的“算力”优化需求，移植并改进了社区前沿版本中的Vector API技术，将其作为Kona 11长期支持版本中的特性，并且与数据平台部团队合作在广告核心业务场景探索落地。

● 大堆GC优化：针对大数据大堆场景等高度可靠性SLA需求，改进GC策略，有效避免不合理的Mixed GC导致的长时间应用停顿。

● 针对在线服务场景和混布场景的内存成本优化需求，改进JVM GC策略，降低应用内存开销。

JDK 11通用场景性能表现如何？

首先，这个问题众说纷纭，也有人在自己的benchmark中得到JDK 8性能最好的结论，我们还是通过一些工业标准benchmark的数据说话，总体来说大多数场景Kona JDK 11对比Kona JDK 8，具有非常明显的性能提升，请看下面简单的性能对比数据。

Specjvm2008峰值性能对比

Specjbb2015 max-jOPS性能对比

Specjbb2015 critical-jOPS性能对比

腾讯大数据Hermes产品 + Kona 11通用版本

Benchmark中看到的性能指标变化，能否真正落实到产品中呢？腾讯大数据Hermes等产品团队采纳了Kona JDK 11，同等硬件环境、同样JVM参数、不做代码改进的性能结果，这个数据非常能够说明Kona JDK的通用性能价值。

典型查询SQL的查询耗时表现（越低越好）

AVG/Min/Max查询耗时对比（越低越好）

总体来说，简单的JDK版本升级即在该场景获得了10+%的性能提升！

Kona 11向量计算版本揭秘

在公司广告等核心业务中，性能/算力不仅仅意味着单位计算资源能够处理更多的业务流量，也深刻影响着我们能够扩展探索的模型复杂度等能力范围，但是，摩尔定律某种程度上在今天已经失效，CPU Core的频率已经多年基本上没有明显上升，免费的性能提升逐步消失，还有哪些性能优化空间可以挖掘呢？

数据并行化！

以大数据场景为例，算力提升依赖于机器（集群）、线程（多核）和指令（SIMD）三种层次的并行计算。分布式集群和多线程大家非常熟悉，也必不可少，但JVM层面在指令级别的优化往往被忽略，而充分利用SIMD是算力的倍增器之一。

JVM向量化/SIMD通常有三种手段：

● 直接使用native语言编写，然后在Java中通过JNI调用，这种方式比较普遍，但因为CPU和计算环境的多变而非常难以开发和维护，相当于抛弃了JVM的效率优势。并且，单纯静态编译因缺少运行时Profile信息，很难进行一些动态编译的优化措施，相当于放弃了部分优化空间，业界探索多年的PGO（Profile-Guided Optimization，也叫FGO/FOGO...），生产实践中大多也不那么香。

● 自己做JVM Intrinsic级别优化，这很cool，但坦白说对普通开发者基本不现实；

● 更加可行的是利用JVM JIT编译器提供的自动向量化（Auto-Vectorization）能力。但是，不仅仅是Java语言，自动向量化技术自身多年来始终没有太大突破，比如Hotspot JVM中，目前仅在C2编译器提供 SupperWord Optimization，依赖于条件苛刻的循环优化等技术，开发维护有难度且脆弱。

目前，OpenJDK前沿版本中孵化的Vector API技术，提供超高性能的同时，保持着Java/JVM平台开发/维护效率的优势，开发者可以用普通Java API的方式编码，无需担忧晦涩的底层研发。不足之处则是，孵化项目在生产落地间存在着版本鸿沟，很难想象生产负载直接升级到开发中的JDK 15上，社区也不会对该版本进行长期支持，另外孵化项目真正到生产实践，仍然存在一些技术问题。

腾讯JDK团队，将Vector API技术引入到Kona 11中，修复了众多孵化项目在生产环境的JVM问题，大幅降低CPU指令级别优化的生产落地难度，提供了大数据/机器学习场景的极致性能，同时提供长期支持版本的定期更新维护，解决业务团队的后顾之忧。

目前我们也逐步将部分修复回馈到了OpenJDK社区的前沿版本，让整个社区受益。

向量计算优化效果

大家可以从下面一组数据看到训练性能的提高：

即使是相比于jblas这种高性能类库，JVM Vector API版本的性能整体亦提升了49% ～ 78%，这是非常可观的性能收益，而且从研发效率、可靠性、可移植性等方面，JVM无缝支持的Vector API具有无可比拟的效率优势，生产价值突出。

云计算 + Kona JDK 11

Kona JDK 11在云微服务产品场景进行了初步落地探索：

1）在腾讯云中间件微服务产品中，我们将腾讯云中间件微服务支撑环境升级到Kona JDK 11后，对微服务应用进行了稳定性和性能压力测试，测试结果显示稳定性表现良好，压测QPS有5%的性能提升。

2）利用AOT与AppCDS技术提高微服务应用冷启动性能。通过将微服务应用冷启动过程中使用的class进行AOT和AppCDS，微服务应用冷启动性能分别提升46%和25%，综合冷启动性能提升接近超过一倍。

是时候升级到JDK 11吗？

由于JDK 9之后陆续引入的Java平台模块化系统（JPMS, Java Platform Module System）等重构工作，JDK新版本与当前主流JDK 8版本存在一定的兼容性差异，这也是为什么JDK新版本的采纳速度有所延迟。

不过随着Java生态的发展，目前主流开源软件、框架、类库和工具等，大都已经逐步完善，JDK 11的功能与性能优势也逐步得到了业界的认可，这一点也体现在近期的一些业界调查问卷报告中，我们可以看到下图中，JDK 11 的采纳显著提高，虽然该报告未必反映了国内的实际情况，但仍然说明是时候认真考虑升级到Kona JDK 11了。

我们将JDK版本升级定义为三个层次：

● 应用能够运行在Kona JDK 11上

● 应用自身能够基于Kona JDK 11编译构建

● 完整无误的构建和运行在JDK 11上

在目前进行的几个升级场景中，大部分可以通过修改运行参数、升级软件包版本等方式，即可快速达到完整的版本升级，这充分体现了整个Java生态已经逐步完成了对JDK新版本的支持工作，相当一部分生产障碍已经不存在。腾讯JDK团队也将逐步公开分享我们在JDK 11迁移中的经验教训，希望能够对加大有所帮助，避免踩坑。

总结：

JDK 11是一个值得认真考虑的版本，Kona JDK 11的针对性优化，让其在大数据/机器学习、云计算等场景具备明显的性能和功能优势，限于篇幅我们今天没有对大堆GC优化、ZGC等新特性生产化进行赘述，后续将有专门的文章进行详细介绍，敬请期待。

后续我们会尽快开源Kona JDK 11，为大家提供一个生产验证的、开箱即用的JDK 11版本，并且解决JDK 11自身落地的不足，扩展其核心能力。

于此同时，腾讯JDK团队虽然是OpenJDK社区的后来者，但我们已经在积极upstream尽可能多的改进到OpenJDK主分支，让更广泛的Java生态从中受益。不知大家有没有注意到，在前段时间社区发布的JDK 14公告中，Tencent已经成为国内仅有的个别贡献公司之一被提名，我们会再接再厉！