java我可以合理地期望从系统中得到的最差的解决方案是什么。纳米时代？

Question

我正在编写的软件要求的时间戳分辨率为微秒或更高

我计划将^{}与^{}结合使用，就像这样，尽管这只是一个粗略的代码草图：

private static final long absoluteTime = (System.currentTimeMillis() * 1000 * 1000);
private static final long relativeTime = System.nanoTime();

public long getTime()
{
    final long delta = System.nanoTime() - relativeTime;
    if (delta < 0) throw new IllegalStateException("time delta is negative");
    return absoluteTime  + delta;
}

nanoTime的文档说明：

This method provides nanosecond precision, but not necessarily nanosecond resolution (that is, how frequently the value changes) - no guarantees are made except that the resolution is at least as good as that of currentTimeMillis().

所以它没有给我们一个比毫秒更好的分辨率保证

再深入一点，在nanoTime（可以预见这是一种本地方法）的掩护下：

• Windows使用^{}API，它承诺 分辨率小于一微秒，这是伟大的

• Linux使用带有标志的^{}来确保值为 单调，但不承诺决心

• Solaris与Linux类似

• 消息来源没有提到OSX或基于Unix的OSs如何处理这个问题

（source）

我已经看到一些模糊的暗示，它将“通常”具有微秒分辨率，例如this answer关于另一个问题：

On most systems the three least-significant digits will always be zero. This in effect gives microsecond accuracy, but reports it at the fixed precision level of a nanosecond.

但是没有来源，“通常”这个词是非常主观的

问题：在什么情况下nanoTime会返回分辨率低于微秒的值？例如，可能一个主要的操作系统版本不支持它，或者需要一个特定的硬件功能，而这个功能可能不存在。请尽量提供来源，如果可以的话

---

我使用的是Java1.6，但是如果在这个问题上有实质性的好处，那么我很有可能升级

Answer 1

Question: Under what circumstances might nanoTime return a value whose resolution is worse than microseconds? What operating systems, hardware, JVMs etc. that are somewhat commonly used might this affect? Please try to provide sources if you can.

要求列出所有可能违反该约束的情况似乎有点过分，没有人知道您的软件将在哪些环境下运行。但为了证明这是可能发生的，他描述了一个例子，由于争用，纳米时间在windows机器上变得不如一微秒精确（就其自身的延迟而言）

另一种情况是在虚拟机下运行的软件，它以非常粗糙的方式模拟硬件时钟

由于特定于平台和硬件的行为，该规范被故意含糊不清

一旦您验证了所使用的硬件和操作系统确实提供了您所需要的，并且虚拟机通过了必要的功能，您就可以“合理地期望”微秒精度