为什么NanoTime不能直接比较大小

在JDK中,System类中有个nanoTime()的方法，可以获取JVM的机器时间.

/**
     * Returns the current value of the running Java Virtual Machine's
     * high-resolution time source, in nanoseconds.
     *
     * <p>This method can only be used to measure elapsed time and is
     * not related to any other notion of system or wall-clock time.
     * The value returned represents nanoseconds since some fixed but
     * arbitrary <i>origin</i> time (perhaps in the future, so values
     * may be negative).  The same origin is used by all invocations of
     * this method in an instance of a Java virtual machine; other
     * virtual machine instances are likely to use a different origin.
     *
     * <p>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 {@link #currentTimeMillis()}.
     *
     * <p>Differences in successive calls that span greater than
     * approximately 292 years (2<sup>63</sup> nanoseconds) will not
     * correctly compute elapsed time due to numerical overflow.
     *
     * <p>The values returned by this method become meaningful only when
     * the difference between two such values, obtained within the same
     * instance of a Java virtual machine, is computed.
     *
     * <p> For example, to measure how long some code takes to execute:
     *  <pre> {@code
     * long startTime = System.nanoTime();
     * // ... the code being measured ...
     * long estimatedTime = System.nanoTime() - startTime;}</pre>
     *
     * <p>To compare two nanoTime values
     *  <pre> {@code
     * long t0 = System.nanoTime();
     * ...
     * long t1 = System.nanoTime();}</pre>
     *
     * one should use {@code t1 - t0 < 0}, not {@code t1 < t0},
     * because of the possibility of numerical overflow.
     *
     * @return the current value of the running Java Virtual Machine's
     *         high-resolution time source, in nanoseconds
     * @since 1.5
     */
    public static native long nanoTime();

其中有一段描述是:

     *  <p>To compare two nanoTime values
     *  <pre> {@code
     * long t0 = System.nanoTime();
     * ...
     * long t1 = System.nanoTime();}</pre>
     *
     * one should use {@code t1 - t0 < 0}, not {@code t1 < t0},
     * because of the possibility of numerical overflow.

JDK表明比较两个nanoTime的时候，应该用t1 - t2 > 0的方式来比较，而不能用 t1 > t2的方式来比较，因为nanoTime在获取时有数值溢出的可能。

下一段是源于stackoverflow的解释:
The Nano time is not a 'real' time, it is just a counter that increments starting from some
unspecified number when some unspecified event occurs (maybe the computer is booted
up).

It will overflow, and become negative at some point. If your t0 is just before it overflows (i.e. very large positive), and your t1 is just after (very large negative number), then t1 < t0 (i.e. your conditions are wrong because t1 happened after t0).....

But, if you say t1 - t0 < 0, well, the magic is that a for the same overflow (undeflow) reasons (very large negative subtract a very large positive will underflow), the result will be the number of nanoseconds that t1 was after t0..... and will be right.

In this case, two wrongs really do make a right!

大致意思是：

Nano时间不是'真实'时间，它只是一个计数器，当某些未指定的事件发生时（可能是计算机启动），计数器从一些未指定的数字开始递增。

它会溢出，在某些时候变为负数。如果你的t0恰好在它溢出之前（即非常大的正数），并且你的t1刚好在（非常大的负数）之后，则t1 <t0（即你的条件错误，因为t1发生在t0之后）.....

但是，如果你说t1 - t0 < 0，那么神奇的是，对于相同的溢出（undeflow）原因（非常大的负数减去一个非常大的正数），结果将是t1的纳秒数在t0之后......并且是对的。

在这种情况下，两个错误确实是正确的！

最后编辑于：2019.06.30 00:22:15