https://docs.oracle.com/javase/6/docs/api/java/lang/System.html#currentTimeMillis() 说：
以毫秒为单位返回当前时间。请注意，虽然返回值的时间单位是毫秒，但值的粒度取决于底层操作系统并且可能更大。例如，许多操作系统以几十毫秒为单位测量时间。
我不清楚我是否可以保证这段代码总是打印不断增加（或相同）的数字。
while (1) {
System.out.println(System.currentTimeMillis() );
}
【问题讨论】：
currentTimeMillis 是否单调。
简短的回答是否定的，System.currentTimeMillis() 是不是单调的。它基于系统时间，因此在时钟调整的情况下（例如通过NTP）可能会受到任何一种方式（向前或向后）的影响。
System.nanoTime() 是单调的，当且仅当底层平台支持 CLOCK_MONOTONIC - 请参阅 Java bug report 6458294 上的 cmets，了解在某些情况下这是/不是真的情况。
（另外，我个人观察到（多次）System.currentTimeMillis() 在没有时钟调整的情况下跨线程“向后”运行——也就是说，在一个线程中对该方法的调用返回比另一个线程中的调用低的值，即使它在“实时”中按时间顺序发生）
如果您需要单调源，支持单调的平台上的System.nanoTime() 是您的最佳选择。
【讨论】：
currentTimeMillis() 倒退？这看起来是一件相当棘手的事情，我想到了海森堡。您是否以某种方式同步了线程？还能观察到时间倒流吗？
long start = System.currentTimeMillis()，然后启动另一个线程来完成这项工作，它本身在最后完成了long end = System.currentTimeMillis()，并减去了两者。在运行时间非常短的工作的情况下，这种差异（并不少见）是负面的。这让我很困惑，直到我做了一些研究并深入研究了代码。 :)
long startInCallingThread = Sys.cTM() 并将该值传递给线程#2，这将得到Sys.cTM() - startInCallingThread 的负值？有趣的。您是否可能在虚拟机中运行它？ 没有时钟调整，您是指仅手动调整还是包括自动调整，例如由 ntp 守护程序引起的自动调整？
不，它不会总是 >= 所有之前的调用。
如果您从同一个线程快速连续多次调用它，它可能不会每次都增加（我知道这是 >= 的 = 部分，但这种行为经常让人感到惊讶）。
如果您从多个线程快速连续多次调用它，它可能会执行任意数量的操作——它可能会在线程间稍微回退非常小的时间，具体取决于实现和随机机会。
最严重的是，如果用户（罕见）或 NTP 同步（可能很常见）调整系统时钟，则该值可能会在时间上大量回退。
【讨论】：
不可能保证增加，因为用户可能会改变调用之间的系统时间。
除此之外，它应该保持增长，因为它表示自纪元以来的毫秒数。如果这是正常的“挂钟”，您将不得不担心闰日或夏令时转换的时间变化。
【讨论】：
如果你想要一个单调递增的值，你可以这样做。
public enum Time {
;
private static long lastTime;
public synchronized static long increasingTimeMillis() {
long now = System.currentTimeMillis();
if (now > lastTime)
return lastTime = now;
return ++lastTime;
}
}
只要您每秒调用它少于一千次，您增加的时间就不会偏离实际时间太远，而是独一无二的。 （即使您重新启动应用程序，这也可以工作）
【讨论】：
synchronized 锁
@Mark Rushakoff 是对的； nanoTime() 可能更可靠一些。
附录：注意@Steven Schlansker 引用的caveats。
【讨论】：