System.currentTimeMillis против System.nanoTime

Если вы просто ищете чрезвычайно точные измерения пройденное время, используйте System.nanoTime(). System.currentTimeMillis() даст вам наиболее точное возможное время в миллисекундах, прошедшее с эпохи, но 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 (2⁶³ 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 () для получения дополнительной информации.

System.nanoTime() не поддерживается в старых JVM. Если это вызывает беспокойство, придерживайтесь currentTimeMillis.

Что касается точности, то вы почти правы. На НЕКОТОРЫХ машинах с Windows currentTimeMillis() имеет разрешение около 10 мс (а не 50 мс). Я не уверен, почему, но некоторые машины с Windows так же точны, как и машины с Linux.

Раньше я использовал GAGETimer с умеренным успехом.

Да, если требуется такая точность, используйте 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.currentTimeMillis() в Windows 7 в Oracle Java 8. Время возвращалось с точностью до 1 миллисекунды. Исходный код в OpenJDK не изменился, поэтому я не знаю, что вызывает лучшее поведение.

Дэвид Холмс из Sun опубликовал статью в блоге пару лет назад, в которой очень подробно рассматриваются API-интерфейсы синхронизации Java (в частности, System.currentTimeMillis() и System.nanoTime()), когда вы хотите их использовать и как они работают внутри компании.

Внутри виртуальной машины Hotspot: часы, таймеры и планирование событий - Часть I - Windows

Один очень интересный аспект таймера, используемого Java в Windows для API-интерфейсов, которые имеют параметр синхронизированного ожидания, заключается в том, что разрешение таймера может меняться в зависимости от того, какие другие вызовы API могли быть сделаны - в масштабе всей системы (а не только в конкретном процессе). . Он показывает пример, в котором использование Thread.sleep() вызовет это изменение разрешения.

У меня был хороший опыт работы с нанотремя. Он обеспечивает время настенных часов в виде двух длин (секунды с начала эпохи и наносекунды в пределах этой секунды) с использованием библиотеки JNI. Он доступен с предварительно скомпилированной частью JNI как для Windows, так и для Linux.

Поскольку никто об этом не упомянул ...

Сравнивать результаты вызовов System.nanoTime() между разными потоками небезопасно. Даже если события потоков происходят в предсказуемом порядке, разница в наносекундах может быть положительной или отрицательной.

System.currentTimeMillis() безопасен для использования между потоками.

одна вещь здесь - непоследовательность метода nanoTime. он не дает очень согласованных значений для одного и того же ввода. currentTimeMillis намного лучше с точки зрения производительности и согласованности, а также, хотя и не так точен, как nanoTime, имеет меньшую погрешность. , и, следовательно, большая точность в его стоимости. Поэтому я бы посоветовал вам использовать currentTimeMillis

Как уже говорили другие, currentTimeMillis - это время часов, которое изменяется из-за перехода на летнее время (нет: переход на летнее время и часовой пояс не связаны с currentTimeMillis, остальное верно), пользователей, меняющих настройки времени, дополнительных секунд и синхронизации времени в Интернете. Если ваше приложение зависит от монотонно увеличивающихся значений прошедшего времени, вы можете предпочесть nanoTime.

Вы можете подумать, что игроки не будут возиться с настройками времени во время игры, и, возможно, вы будете правы. Но не стоит недооценивать сбой из-за синхронизации времени в Интернете или, возможно, пользователей удаленных рабочих столов. API nanoTime невосприимчив к такого рода сбоям.

Если вы хотите использовать время часов, но избегаете прерываний из-за синхронизации времени в Интернете, вы можете рассмотреть клиент NTP, такой как Meinberg, который «настраивает» тактовую частоту на ноль, вместо того, чтобы просто периодически сбрасывать часы.

Я говорю из личного опыта. В приложении для погоды, которое я разработал, я получал случайные всплески скорости ветра. Мне потребовалось время, чтобы понять, что моя временная шкала нарушается из-за поведения часов на типичном ПК. Все мои проблемы исчезли, когда я начал использовать nanoTime. Последовательность (монотонность) была важнее для моего приложения, чем грубая точность или абсолютная точность.

Для игровой графики и плавного обновления положения используйте System.nanoTime(), а не System.currentTimeMillis(). Я переключился с currentTimeMillis () на nanoTime () в игре и получил значительное визуальное улучшение плавности движения.

Хотя может показаться, что одна миллисекунда уже должна быть точной, визуально это не так. Факторы, которые может улучшить nanoTime(), включают:

• точное позиционирование пикселей ниже разрешения настенных часов
• возможность сглаживания между пикселями, если хотите
• Неточность настенных часов на окнах
• дрожание часов (несоответствие фактического времени, когда настенные часы тикают вперед)

Как показывают другие ответы, у nanoTime действительно есть затраты на производительность при повторном вызове - лучше всего вызывать его только один раз за кадр и использовать то же значение для расчета всего кадра.

System.currentTimeMillis() небезопасен для истекшего времени, потому что этот метод чувствителен к системным изменениям часов реального времени системы. Вам следует использовать System.nanoTime. См. Справку по системе Java:

О методе 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()..

Если вы используете System.currentTimeMillis(), ваше прошедшее время может быть отрицательным (Назад <- в будущее)