我已将其视为微基准测试的潜在陷阱之一。如果您指定@Measurement（或@Warmup）将运行固定的时间，则意味着在比较不同的运行（例如，不同的平台，不同的VM版本等）时，您将获得更少的比较“苹果到苹果”，因为运行不会做相同的工作！
如果一次运行执行得更快，那么它将在给定时间内执行更多操作。这就引入了可能使结果产生偏差的混淆因素：更多的动态优化机会，缓存差异，每个操作的统计信息等等。
另一方面，如果您指定固定数量的操作，则每次运行都执行完全相同的工作量，从而提高了对结果的信心。
那么，JMH使用这种指定固定时间量而不是固定操作数的方法的原因是什么？是否有一些重要原因导致我错过了这个设计决策？我在JMH文档中和在线讨论中都进行了搜索，但找不到该问题的答案。
答案 0 :(得分：4)
固定数字可能不是一个好的选择。假设我们选择10,000，这足以预热代码。如果操作非常短，则可能不足以获得最佳结果，但是如果要花费10秒，则10次运行将需要12天才能获得结果。运行一段固定的时间，您至少知道要花多长时间。
在实际使用中，您可能会在已知的时间量（而不是固定的迭代次数）内运行代码。