java System.nanoTime 真的很慢。是否可以实现高性能的 Java 分析器？

Question

我进行了测试，发现在我的机器上调用 System.nanoTime() 函数的开销至少为 500 ns。

似乎很难有一个高性能的 java 分析器。对于企业软件，假设一个函数耗时约 350 秒，方法调用次数为 12,500,000,000 次。因此，调用 System.nanoTime() 的次数为:12,500,000,000 * 2 = 25,000,000,000(一个用于开始时间戳，一个用于结束时间戳)System.nanoTime 的总开销是:500 纳秒 * 25,000,000,000 = 500 * 25000 秒 = 12500000 秒。

注:所有数据均来自真实案例。

有什么更好的获取时间戳的方法吗？

Answer 1

我在商业 Java 性能分析器方面工作了 10 年，用于开发和生产。

简短的回答是 - 是的，您是对的。你无法做到这一点。即使可以，将除微不足道的检测外的任何东西放入如此频繁调用的方法中也可以:

• 改变 JIT 处理代码的方式，从而

• 以难以预测(但从性能调整的角度来看通常没有用)的方式扭曲您的性能数据。

  (让我们不要开始讨论在 JIT 完成后如何在基本上是紧密的汇编循环中进行系统调用会影响 CPU 在预取方面可能能够进行的所有奇特优化，从而导致否则不必要的上下文切换和刷新你的 L1 缓存等等)

测试慢速(或者“不经常调用”会更好？)方法是可以的。例如，您可以使用大量 JDBC API 来捕获数据库问题。

对于实际 Java 代码的实际性能调整(与 Java 调用不同，如网络、文件系统、数据库等)，检测并不是真正可行的方法。您会得到更容易理解的结果，但现在大概 7 年没有人做过用于性能调优的线路级检测 - 同样的原因。

相反，商业分析器使用“采样”技术 - 他们定期获取堆栈跟踪。 JVMTI 有一些不错的调用，使得每隔几毫秒执行一次非常便宜。然后你假设堆栈跟踪之间的所有时间都花在了新堆栈上(这显然不是真的，但从统计上讲，它在一个不短的测量周期内产生了准确的结果) - 你已经得到了一些可操作的性能数据，没有疯狂的开销或任何类型的观察者效应。