System.currentTimeMillis проти System.nanoTime

Точність Vs. Точність

Що я хотів би знати, чи слід використовувати System.currentTimeMillis () або System.nanoTime () при оновленні позицій об’єкта в моїй грі? Їх зміна в русі прямо пропорційна минулому часу з моменту останнього дзвінка, і я хочу бути максимально точним.

Я читав, що між різними операційними системами є деякі серйозні проблеми з врегулюванням часу (а саме те, що Mac / Linux має майже 1 мс роздільну здатність, а Windows має роздільну здатність 50 мс). Я в основному запускаю свої програми на Windows і роздільна здатність 50 мс здається досить неточною.

Чи є кращі варіанти, ніж два, які я перерахував?

Будь-які пропозиції / коментарі?

Якщо ви просто шукаєте надзвичайно точні вимірювання минулого часу , використовуйте System.nanoTime(). System.currentTimeMillis()дасть вам найточніший можливий пройдений час у мілісекундах з епохи, алеSystem.nanoTime() надасть точний наносекундний час відносно деякої довільної точки.

З документації Java:

public static long nanoTime()

Повертає поточне значення найбільш точного доступного системного таймера в наносекундах.

Цей метод може використовуватися лише для вимірювання минулого часу і не пов'язаний з будь-яким іншим поняттям системи або часу настінного годинника. Значення, що повертається представляє наносекунд з моменту деякого фіксованого але довільного походження часу (можливо , в майбутньому, так що значення можуть бути негативними). Цей спосіб забезпечує наносекундну точність, але не обов'язково наносекундну точність. Не дається гарантій щодо того, як часто змінюються значення. Відмінності в послідовних викликах, що тривають більше 292 років (2 ⁶³ наносекунди), не будуть точно обчислювати минулий час через чисельне переповнення.

Наприклад, щоб виміряти, скільки часу потрібно для виконання коду:

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

Дивіться також: JavaDoc System.nanoTime () та JavaDoc System.currentTimeMillis () для отримання додаткової інформації.

Оскільки ніхто інший цього не згадував ...

Не безпечно порівнювати результати System.nanoTime()викликів між різними потоками. Навіть якщо події потоків відбуваються у передбачуваному порядку, різниця в наносекундах може бути позитивною чи негативною.

System.currentTimeMillis() безпечний для використання між нитками.

Оновлення Аркадія : Я спостерігав більш правильну поведінку System.currentTimeMillis()Windows 7 в Oracle Java 8. Час повернуто з точністю до 1 мілісекунди. Вихідний код у OpenJDK не змінився, тому я не знаю, що викликає кращу поведінку.

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

Всередині VM Hotspot: Годинники, таймери та події планування - Частина I - Windows

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

System.nanoTime()не підтримується у старих JVM. Якщо це турбота, дотримуйтесьcurrentTimeMillis

Щодо точності, ви майже правильні. На деяких машинах Windows, currentTimeMillis()має роздільну здатність близько 10 мс (не 50 мс). Я не впевнений, чому, але деякі машини Windows настільки ж точні, як і машини Linux.

Раніше я використовував GAGETimer з помірним успіхом.

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

Ви можете подумати, що гравці не вподобають налаштувань часу під час гри, і, можливо, ви матимете рацію. Але не варто недооцінювати збої через синхронізацію часу в Інтернеті чи, можливо, користувачів віддалених настільних ПК. API nanoTime не застрахований від подібних порушень.

Якщо ви хочете використовувати годинник, але уникати розривів через синхронізацію часу в Інтернеті, ви можете розглянути такий клієнт NTP, як Meinberg, який "налаштовує" тактову частоту на нуль, замість того, щоб періодично скидати годинник.

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

Так, якщо така точність потрібна System.nanoTime() , але пам’ятайте, що тоді вам потрібен JVM Java 5+.

У моїх системах 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 () і отримав значне покращення зору в плавності руху.

Хоча одна мілісекунда може здатися такою, ніби вона вже повинна бути точною, візуально це не так. До факторів, які nanoTime()можна покращити, належать:

• точне розміщення пікселів нижче роздільної здатності настінного годинника
• можливість анти-псевдоніму між пікселями, якщо ви хочете
• Неточність настінного годинника Windows
• тремтіння годинника (невідповідність того, коли настінний годинник насправді тикає вперед)

Як свідчать інші відповіді, nanoTime має вартість продуктивності, якщо викликається повторно - найкраще було б викликати її лише один раз за кадр і використовувати те саме значення, щоб обчислити весь кадр.

Я мав хороший досвід роботи з нанотим . Він забезпечує час настінного часу у вигляді двох довгих (секунд після епохи та наносекунд протягом цієї секунди), використовуючи бібліотеку JNI. Він доступний з попередньо складеною частиною JNI і для Windows, і для Linux.

System.currentTimeMillis()не є безпечним протягом минулого часу, оскільки цей метод чутливий до зміни годин в системі в режимі реального часу. Ви повинні використовуватиSystem.nanoTime . Будь ласка, зверніться до довідкової системи Java:

Про метод nanoTime:

.. Цей метод забезпечує наносекундну точність, але не обов'язково наносекундну роздільну здатність (тобто те, як часто змінюється значення) - жодних гарантій не надається, крім того, що роздільна здатність є принаймні такою ж хорошою, як і в CurrentTimeMillis ().

Якщо ви використовуєте System.currentTimeMillis()минулий час, це може бути негативно (Назад <- у майбутнє)

Одне тут - невідповідність методу nanoTime. він не дає дуже послідовних значень для одного і того ж input.currentTimeMillis робить набагато кращі з точки зору продуктивності та послідовності, а також, хоча і не такий точний, як nanoTime, має менший запас похибки , а отже, більше точності в його значенні. Тому я б запропонував вам використовувати currentTimeMillis