Misleading Microbenchmarks on the Java Virtual Machines
本文表明，即使遵循 Java 微基准测试套件（JMH）指南，JVM 上的微基准测试仍可能因诱导出引发激进且缺乏代表性的优化的不切实际执行配置文件而产生误导性的性能结果，并提出了扩展指南以缓解这些问题。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
想象一下，你是一位厨师，正试图决定两把新刀中哪一把更锋利。你设计了一个测试：在厨房里只有你一人、没有其他任务、且纸张厚度始终一致的情况下，连续切割同一张纸1000次。
基于这个测试，A刀似乎快得惊人。但在现实世界中，当你同时切洋葱、切番茄、并切割坚韧的牛排时，A刀实际上可能比B刀更慢。
这正是论文《Java虚拟机上的误导性微基准测试》所论证的：当软件开发人员测试他们的代码时，也会发生同样的情况。
问题所在：“无菌”测试厨房
开发人员经常使用一种名为JMH（Java微基准测试套件）的工具来测试小段代码。他们想知道：“我这种新的数学运算方式是否比旧的方式更快？”
该论文将这类测试运行的环境称为“无菌环境”。这就像一个实验室，其中：
- 只执行一项任务：代码在隔离状态下被测试，没有其他程序运行。
- 输入永不改变：代码反复接收完全相同的数据。
- 计算机变得“懒惰”：Java虚拟机（JVM）——运行Java代码的引擎——非常智能。它会观察你的操作，并试图预测你下一步要做什么，以优化性能。这被称为推测性优化。
陷阱：“过度专业化”的厨师
关键在于：由于测试如此“无菌”（重复且隔离），JVM引擎会感到困惑。它看到代码每次都做完全相同的事情，于是心想：“啊！这段代码将永远只切割5英寸长的纸片。我将构建一台专门完美切割5英寸纸片的定制机器。”
于是，引擎为那一种特定场景构建了一个高度专业化、超高速的代码版本。
结果：测试显示：“哇，这段代码快了40%！”
现实：在实际应用中，代码会接收各种不同尺寸的“纸片”。这台专用机器会崩溃，代码的实际运行速度反而慢于原本更灵活的原版。
该论文展示了三个具体示例，说明这种欺骗性是如何发生的：
1. “一刀切”的哈希码
- 测试：开发人员创建了一种计算数字列表“指纹”的新方法。在测试中，他们只向该方法提供恰好包含10个数字的列表。
- 假象：由于引擎专门为10个数字的列表进行了优化，新代码看起来非常出色。
- 现实：当代码在实际应用中被用于处理包含3个、50个或100个数字的列表时，这种“专业化”的代码变得笨拙且缓慢。原本那个枯燥的旧代码其实一直更优。
2. Stream API（流水线）
- 测试：开发人员通过仅隔离运行一个特定查询，来测试一种处理数据的现代方法（称为Streams）。
- 假象：引擎看到这一个查询，便为其完美优化了流水线。
- 现实：实际应用会运行成千上万种不同的查询。引擎那“完美”的流水线无法应对这种多样性，导致性能下降。论文发现，在测试中看似快了41%的代码，在实际中反而更慢。
3. “不公平”的集合比较
- 测试：开发人员想证明他们新的“List”或“Map”（数据存储工具）比Java内置的标准工具更快。
- 假象：他们运行测试，新工具获胜。
- 现实：标准Java工具在测试开始前就已经“预热”并获得了优化，因为Java系统使用它们来自我设置。而新工具在无菌测试中获得了“全新开始”，旧工具则被其历史所拖累。这就像一场比赛：一名选手从起跑线开始，另一名选手却被迫先绕跑道跑一圈，但计时器只在两人同时冲过终点线时才开始。论文表明，当你纠正这种不公平时，“新”工具往往实际上并不更快。
解决方案：“污染”测试
论文提出了一个简单的解决方法：不要让测试过于干净。
在测量速度之前，你应该“污染”环境。这意味着在开始计时之前，先用多种不同的输入和场景运行代码。
- 类比：在计时你的刀具之前，先切胡萝卜、土豆、番茄和一块坚韧的肉。让引擎见识到多样性。
- 结果：引擎不再试图只为单一事物构建机器。它会构建一个能妥善处理各种情况的通用机器。现在，测试结果才能真正反映现实世界中会发生的情况。
核心结论
如果你在完美、隔离且永不变化的气泡中测试代码，你可能会得到一个看似出色却是虚假的结果。要获得真相，你就必须在混乱、现实的环境中测试代码，就像现实生活一样，事物总是在变化。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。