@levinzhang
2019-05-02T02:36:29.000000Z
字数 3183
阅读 344
by
OpenJDK微基准测试套件（OpenJDK Microbenchmark Suite，JEP 230）基于Java Microbenchmark Harness（JMH），是JDK 12版本的一个新特性。来自甲骨文的核心技术人员Claes Redestad与InfoQ讨论了这个新的微基准测试套件。
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）。