System.currentTimeMillis（）是Java中时间性能的最佳衡量标准吗？
System.currentTimeMillis（）是Java中时间性能的最佳衡量标准吗？ 使用它来比较采取行动之前的时间和采取行动之后的时间是否有任何问题？ 还有更好的选择吗？
我希望不是 – 这是我在不使用nanoTime()时使用的。
除了System.nanoTime()之外，JMX可能是最可行的选择：
java.lang.management.ManagementFactory.getThreadMXBean()
你可以查询当前的线程cpu时间（以纳秒为单位测量但不是纳秒精度，对于System.nanoTime （））
看看这个：
如何计算方法在Java中的执行时间？
如果您需要单调时间测量，System.nanoTime是更好的选择。 System.currentTimeMillis受UTC时序变化的影响 – 闰秒，NTP更新和抖动，以及设置系统时钟*的用户。 这可能会在某些类型的定时应用中引起一些惊人的失败。 System.nanoTime应该对所有这些都免疫。
System.nanoTime的问题包括周期性数字溢出和长期计时不准确，使得System.currentTimeMill对于更长的时间跨度更好（假设用户单独留下系统时钟）。 请注意，夏令时和时区更改不应影响System.currentTimeMillis。
* Windows“与互联网时间同步”进行逐步更改。 这可能是非常具有破坏性的，而不是通过调整客户端时基频率来“追逐”服务器的正确NTP客户端实现。
您可以使用Google Guava的秒表，这使得测量时间变得非常容易。
在Java 1.5之前，只有System.currentTimeMillis。 但是，值的粒度取决于底层操作系统，并且可能很大。 在Windows XP上，我有时最终会出现20ms的差距。 我听说Linux在1-2ms范围内的差距更好。
使用Java 1.5，您还可以使用System.nanoTime。 我从来没有遇到过这个问题。
一个问题是，它测量的是实时时间，而不是CPU时间 – 所以它非常依赖于系统负载。 如果您使用其他免费的计算机，这很好，但如果其他进程正在尝试工作，有时可能会产生有趣的结果。
本文有一个解决问题的有效方法。