java mybatis，nano java_java – System.nanoTime()完全無用？

那個帖子是錯誤的，nanoTime是安全的。有一個評論鏈接到

a blog post by David Holmes，一個實時和并發的家伙在太陽。它說：

System.nanoTime() is implemented using the QueryPerformanceCounter/QueryPerformanceFrequency API […] The default mechanism used by QPC is determined by the Hardware Abstraction layer(HAL) […] This default changes not only across hardware but also across OS versions. For example Windows XP Service Pack 2 changed things to use the power management timer (PMTimer) rather than the processor timestamp-counter (TSC) due to problems with the TSC not being synchronized on different processors in SMP systems, and due the fact its frequency can vary (and hence its relationship to elapsed time) based on power-management settings.

所以，在Windows上，這是一個問題，直到WinXP SP2，但它不是現在。

java mybatis、我找不到第二部分(或更多)談論其他平臺，但該文章包括一個說，Linux遇到并解決了同樣的問題，與一個鏈接到FAQ for clock_gettime(CLOCK_REALTIME)，說：

Is clock_gettime(CLOCK_REALTIME) consistent across all processors/cores? (Does arch matter? e.g. ppc, arm, x86, amd64, sparc).

It should or it’s considered buggy.

However, on x86/x86_64, it is possible to see unsynced or variable freq TSCs cause time inconsistencies. 2.4 kernels really had no protection against this, and early 2.6 kernels didn’t do too well here either. As of 2.6.18 and up the logic for detecting this is better and we’ll usually fall back to a safe clocksource.

ppc always has a synced timebase, so that shouldn’t be an issue.

java回收無用類對象。所以，如果福爾摩斯的鏈接可以讀取為暗示nanoTime調用clock_gettime(CLOCK_REALTIME)，那么它是安全的ish從內核2.6.18在x86上，并始終在PowerPC(因為IBM和摩托羅拉，不像英特爾，實際知道如何設計微處理器)。

遺憾的是，沒有提到SPARC或Solaris。當然，我們不知道IBM JVM是做什么的。但是Sun JVM在現代Windows和Linux上得到這個權利。

編輯：這個答案是基于它引用的來源。但我仍然擔心，它可能實際上是完全錯誤。一些更新的信息將是真正有價值的。我剛剛碰到一個鏈接到一個four year newer article about Linux’s clocks這可能是有用的。