java - System.currentTimeMillis（）は、Javaの時間パフォーマンスの最良の尺度ですか？

Question

System.currentTimeMillis（）は、Javaの時間パフォーマンスの最良の尺度ですか？これを使用して、アクションが実行される前の時間とアクションが実行された後の時間を比較する場合の落とし穴はありますか？より良い代替案はありますか？

Answer 1

私はそうしないことを望みます-それは私が使用しないときに私が使用するものnanoTime()です。

Answer 2

Google Guava のストップウォッチを使用すると、時間の測定が非常に簡単になります。

Answer 3

それに加えてSystem.nanoTime()、JMX はおそらく実行可能な最良のオプションです。

java.lang.management.ManagementFactory.getThreadMXBean()

現在のスレッドのCPU時間を照会できます（ナノ秒単位で測定されますが、（）のようにナノ秒の精度ではありませんSystem.nanoTime）

Answer 4

If you need monotonic time measurements, System.nanoTime is a better choice. System.currentTimeMillis is subject to UTC timing variations -- leap seconds, NTP updates and jitter, as well as users setting the system clock*. This can cause some spectacular failures in certain kinds of timing applications. System.nanoTime is supposed to be immune to all that.

The problems with System.nanoTime include periodic numeric overflow and long term timing inaccuracy, making System.currentTimeMillis better for longer time spans (provided that users leave the system clock alone). Note that daylight saving time and time zone changes should not affect System.currentTimeMillis.

*Windows "Sync with internet time" makes stepwise changes. This can be very disruptive, as opposed to a proper NTP client implementation that "chases" the server by adjusting the client timebase frequency.

Answer 5

Java 1.5より前は、System.currentTimeMillisしかありませんでした。ただし、値の粒度は基盤となるオペレーティングシステムによって異なり、大きくなる可能性があります。Windows XPでは、20ミリ秒のギャップが発生することがありました。Linuxの方が、ギャップが1〜2ミリ秒の範囲ではるかに優れていると聞きました。

Java 1.5では、System.nanoTimeを使用することもできます。私はこれで問題があったことはありません。

Answer 6

1 つの落とし穴は、これが CPU 時間ではなくリアルタイムの経過時間を測定することです。そのため、システム負荷に大きく依存します。これは、それ以外の場合は無料のマシン上であれば問題ありませんが、他のプロセスが作業を行おうとしている場合、興味深い結果が得られることがあります。

この記事には、この問題に対する興味深い解決策があります。