在进行 Java 代码性能测试时，您想要测试 JIT 编译的代码，而不是原始字节码。为了使字节码被编译，您必须通过多次执行代码来触发编译，并允许足够的 yield 时间使后台线程完成编译。
我正在寻找一个阈值，在任何现代操作系统中都可以安全应用，例如 Mac OS 或 Windows 用于开发环境，Linux 用于 CI / 生产。
答案:由于OP的意图并非确定该块是否JIT编译，而是确保测量优化代码，因此我认为OP需要观看一些这些基准测试讲座。
TL;DR版本：没有可靠的方法可以确定是否达到了“稳态”：
您只能进行长时间的测量，以获得您的具体系统通常需要多长时间才能达到您可以声明为“稳定”的状态的近似估计。
观察-XX:+PrintCompilation是不可靠的，因为您可能处于计数器仍在波动的阶段，而JIT正在等待编译下一批现在热门的方法。由于此原因，您可能会有许多预热高原。该方法甚至可以根据待机的分层编译器的数量重新编译多次。
虽然人们可能会争论调用阈值，但这些东西也不可靠，因为涉及到分层编译，方法可能更早地在调用者中内联，概率计数器可能会错过更新等等。也就是说，关于-XX:CompileThreshold=#的常见智慧是不可靠的。
JIT编译不是您追求的唯一预热效果。自动GC启发式算法，调度器启发式算法等也需要预热。
获取一个微基准测试工具，这将使任务更加容易！
建议您使用CompilationMXBean而不是建议的标志，该方法允许您检查JVM编译所花费的时间。如果时间太长，请重复运行测试，直到该值足够稳定为止（请耐心等待！）。框架可以帮助您创建良好的基准测试。个人而言，我喜欢caliper。但是，永远不要相信您的基准测试。
根据我的经验，在模仿javac的习语时，自定义字节码表现最佳。关于这个问题，我可以提到一个轶事，我曾经为Java源代码写过自定义字节码的等效代码：
int[] array = {1, 2, 3};
javac 创建数组并使用 dup 分配每个值，但我将数组引用存储在本地变量中，并将其加载回操作数栈以分配每个值。该数组的大小比那个大，性能差异明显。
最后，在编写基准测试之前，我建议阅读这篇文章。