这里的一个问题是nanoTime方法的不一致性。对于相同的输入，它不会给出非常一致的值。currentTimeMillis在性能和一致性方面做得更好，而且，尽管没有nanoTime那么精确，但它的误差范围更低，因此它的值更准确。因此，我建议您使用currentTimeMillis

如果您只是在寻找极其精确的流逝时间度量，请使用System.nanoTime()。System.currentTimeMillis()将为您提供自epoch以来可能最精确的以毫秒为单位的经过时间，但是System.nanoTime()将为您提供相对于某个任意点的纳秒精确时间。

摘自Java文档:

public static long nanoTime() Returns the current value of the most precise available system timer, in nanoseconds. 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 origin time (perhaps in the future, so values may be negative). This method provides nanosecond precision, but not necessarily nanosecond accuracy. No guarantees are made about how frequently values change. Differences in successive calls that span greater than approximately 292 years (263 nanoseconds) will not accurately compute elapsed time due to numerical overflow.

例如，要测量一些代码执行所需的时间:

long startTime = System.nanoTime();    
// ... the code being measured ...    
long estimatedTime = System.nanoTime() - startTime;

更多信息请参见:JavaDoc System.nanoTime()和JavaDoc System.currentTimeMillis()。

这里的一个问题是nanoTime方法的不一致性。对于相同的输入，它不会给出非常一致的值。currentTimeMillis在性能和一致性方面做得更好，而且，尽管没有nanoTime那么精确，但它的误差范围更低，因此它的值更准确。因此，我建议您使用currentTimeMillis

是的，如果需要这样的精度，请使用System.nanoTime()，但请注意，您需要Java 5+ JVM。

在我的XP系统上，我看到系统时间报告为至少100微秒278纳秒，使用以下代码:

private void test() {
    System.out.println("currentTimeMillis: "+System.currentTimeMillis());
    System.out.println("nanoTime         : "+System.nanoTime());
    System.out.println();

    testNano(false);                                                            // to sync with currentTimeMillis() timer tick
    for(int xa=0; xa<10; xa++) {
        testNano(true);
        }
    }

private void testNano(boolean shw) {
    long strMS=System.currentTimeMillis();
    long strNS=System.nanoTime();
    long curMS;
    while((curMS=System.currentTimeMillis()) == strMS) {
        if(shw) { System.out.println("Nano: "+(System.nanoTime()-strNS)); }
        }
    if(shw) { System.out.println("Nano: "+(System.nanoTime()-strNS)+", Milli: "+(curMS-strMS)); }
    }

对于游戏图像和平滑的位置更新，使用System.nanoTime()而不是System.currentTimeMillis()。我在游戏中从currentTimeMillis()切换到nanoTime()，在运动的平滑度上有了很大的视觉改善。

虽然1毫秒看起来已经很精确了，但从视觉上看并非如此。nanoTime()可以改进的因素包括:

精确的像素定位低于时钟分辨率 如果你想要，像素之间的抗别名能力 窗户挂钟不准 时钟抖动(当挂钟实际滴答前进时不一致)

正如其他答案所表明的那样，如果重复调用nanoTime，确实会有性能损失——最好每帧只调用一次，并使用相同的值来计算整个帧。

正如其他人所说，currentTimeMillis是时钟时间，由于夏令时而改变(不是:夏令时和时区与currentTimeMillis无关，其余为真)，用户更改时间设置，闰秒和互联网时间同步。如果您的应用程序依赖于单调增加运行时间值，您可能更喜欢nanoTime。

你可能认为玩家不会在游戏过程中摆弄时间设置，也许你是对的。但不要低估互联网时间同步或远程桌面用户带来的破坏。nanoTime API不会受到这种中断的影响。

如果你想使用时钟时间，但避免由于互联网时间同步造成的间断，你可以考虑一个NTP客户端，如Meinberg，它“调整”时钟速率为零，而不是定期重置时钟。

这是我的亲身经历。在我开发的一个天气应用程序中，我得到了随机出现的风速峰值。我花了一段时间才意识到，我的时间库被一台典型PC上的时钟时间行为打乱了。当我开始使用nanoTime时，我所有的问题都消失了。对于我的应用程序来说，一致性(单调性)比原始精度或绝对精度更重要。