JEP 230：JDK 12 的新微基准测试套件

OpenJDK 微基准测试套件（OpenJDK Microbenchmark Suite，JEP 230） 基于 Java Microbenchmark Harness（JMH） ，是 JDK 12 版本的一个新特性。JEP 230 的目标在于提供一个稳定且经过优化的基准，其中包括了近 100 个基准测试的初始集合（从 jmh-jdk-microbenchmarks 项目导入的，这是 JMH 基准测试的一个套件），并且还提升了编写新基准测试和搜索已有基准测试的便利性。

微基准测试套件并不是像 java 、 javac 、 jdeps 和 jconsole 那样的独立 JDK 工具。相反，它的代码是与 JDK 源码放到一起的 。如 JEP 230 的 提案 所述：

微基准测试套件的构建将会集成到常规的 JDK 构建系统中。它将会是一个独立的 target，在常规的 JDK 构建中并不会执行它，这样的话，对微基准测试套件不感兴趣的开发人员和其他人员就能保持较短的构建时间。

微基准测试，是衡量一小段 Java 代码性能的艺术，如果没有按照正确的方式实现的话，可能会导致不精确和 / 或误导性的结果。要编写正确的微基准测试，需要考虑很多的事情。在“ Optimizing Java ”一书的第 5 章，作者 Ben Evans 、 James Gough 和 Chris Newland 讨论了编写微基准测试所面临的挑战：

我们无法将正在执行的代码与 JIT 编译器、内存管理和 Java 运行时提供的其他子系统分离开来。同时，我们也不能忽视测试所运行的操作系统、硬件、运行时条件（如加载）等因素的影响。

甲骨文的 Java 语言架构师 Brian Goetz 在 剖析有缺陷的基准测试时 ，这样说到：

微基准测试的可怕之处在于，它们总能生成一个数字，即便这个数字毫无意义。它们的确测量了一些东西，只是我们并不能确定测试的是什么。

通常，它们只度量了特定微基准测试的性能，仅此而已。但是很容易让你相信你的基准测试度量了特定构造的性能，并错误地总结该构造的性能。

Aleksey Shipilëv 是 Red Hat 的首席软件工程师，在 Twitter 上是这样回应性能问题的 ：

任何脱离了反汇编 / 代码生成分析的纳基准测试（nanobenchmark）都是不可信的。

来自甲骨文的核心技术人员 Claes Redestad 与 InfoQ 讨论了这个新的微基准测试套件。

InfoQ：创建这个微基准测试套件的最初动机是什么？

Claes Redestad：多年以来，微基准测试就是 OpenJDK 开发过程的一部分，实际上微基准测试套件只是将微基准测试的使用更紧密地集成到 OpenJDK 开发过程中的漫长道路上的一个步骤。

作为最初推动力的一部分，大多数（甚至可以说所有）微基准测试已经存在很长时间了，它们所依赖的 microbenchmark harness，即 JMH，已经存在好多年了。唯一新鲜的事情是它们集成到了 OpenJDK 构建系统中和主 OpenJDK 仓库中。

在构想这个 JEP 的时候，OpenJDK 项目被分割到多个存储库和 forest 中，这使得编写跨 tree 的测试 (和微基准测试) 非常麻烦。最初的 JEP 提案试图为这些微基准测试添加一个新的存储库，但这一努力最终搁浅了，部分原因在于人们对它是否值得这么麻烦而产生了分歧。

在此之后，OpenJDK 已经整合为一个单独的仓库结构，很多单独开发的测试套件也整合到了主仓库中。该项目五年前面临的很多障碍已经不复存在了。

最终继续推进 JEP 230 提案的动机在于，将功能测试集成和整合（co-locate）到主 OpenJDK 仓库的努力获得了成功。作为整合的测试套件，这并不意味着我们所做的 所有 基准测试都是基于整合的微环境（实际上，远远未实现）。但是，当我们要测试新的 API，而这个 API 只在当前工作的分支上可用时，将这些测试全部集成到一个仓库中是非常便利的。

InfoQ：为什么微基准测试套件不是一个单独的工具呢（像 java、javac、jdpes 和 jconsole 那样）？

Redestad：实际上，JEP 230 只提供了构建和运行微基准测试的方法，并将其作为开发 OpenJDK 本身的一个组成部分，所以套件并没有很自然地转换为适合包含到 JDK 交付物中的工具；这有点像我们不会把所有其他测试打包到 JDK 二进制下载文件中。

InfoQ：对于开发人员来说，开始使用微基准测试套件的最佳方式是什么，比如说到哪里去寻找源码？

Redestad：我猜想，大多数的 Java 开发人员可能希望将微基准测试添加到自己的项目中，而不是贡献给 OpenJDK。因此，对他们来说，虽然微基准测试套件可能有助于寻找灵感，但我建议还是要先阅读 JMH。它提供了相当多的例子，并且很容易搭建一个项目并开始进行尝试。 Aleksey Shipilëv 维持这个项目许多年了，并且提供了大量的资源。

如果你希望构建、测试 OpenJDK，甚至想为 OpenJDK 做出贡献的话，那可以从 https://openjdk.java.net/ 开始，通过 http://hg.openjdk.java.net/jdk/jdk 下载代码，并阅读 http://hg.openjdk.java.net/jdk/jdk/raw-file/96d290a7e94f/doc/testing.html 上的测试文档。

InfoQ：关于微基准测试套件，你还有什么要与我们的读者分享的吗？

Redestad：为 OpenJDK 做出贡献的一种方法是在你自己的 CI 中实际构建并运行这些微基准测试，并报告发现的回归结果。目前，有太多的硬件和系统配置，我们可能不会像你这样在每次新增硬件时都运行所有可用的基准测试，所以你可能会发现我们无法检测到的问题。

InfoQ：微基准测试套件的前景如何？

Redestad：目前，我正在寻求反馈，同时鼓励更多的 OpenJDK 开发人员使用它，甚至改进它。我很高兴地看到已经有新的微基准测试添加了进来，对特性集本身也有一些非常好的外部贡献，比如添加对构建原生库的支持（ https://bugs.openjdk.java.net/browse/JDK-8219393 ）。

我希望我们能够在细节上进行足够多地改进，以便在开发新特性的时候，添加和运行微基准测试能够像添加新的功能测试那样简单和自然。.

InfoQ：你目前的工作职责是什么呢，换句话说，你日常都做些什么？

Redestad：我的主要职责是帮助很多 OpenJDK 开发人员在性能方面按照正确的方式前进。对 JEP 230 的贡献就是这种事情。在我们的夜间测试中进行回归检测筛选则是我的另一项这样的工作。

每天，我都会竭尽所能提供修复和改进。在过去的几年里，我从减少 OpenJDK 的启动和内存占用开销中得到了很多乐趣，包括重构和改进内部 lambda 运行时，以获取比 JDK 8 更短的引导时间。

除了微基准测试套件之外，JDK 12 其他的新特性包括：体验式的新垃圾收集器 Shenandoah （JEP 189）、 增强的 switch 语句 （JEP 325）以及新的 JVM constants API（JEP 334）。

参考资源

• JMH - Java Microbenchmark Harness ——来自 Jenkov.com 的一个教程
• Claes Redestad 撰写的 JEP 230 - Microbenchmarks Suite （2018 年 11 月 16 日）

查看英文原文： JEP 230: A New Microbenchmark Suite for JDK 12