System.nanoTime () абсолютно бесполезен?

Документация Java 5 также рекомендует использовать этот метод для той же цели.

Этот метод может только использоваться для измерения прошедшего времени и не связан ни с каким другим понятием системы или тактовое стеной время.

документ

Нет, это не... Это просто зависит от Вашего ЦП, проверьте Таймер События Высокой точности для того, как/почему вещи по-другому рассматривают согласно ЦП.

В основном, считайте источник своего Java и проверьте то, что Ваша версия делает с функцией, и если это будет работать против ЦП, то Вы будете работать на нем.

IBM даже предлагает , Вы используете ее для сравнительного тестирования производительности (сообщение 2008 года, но обновленный).

Это, кажется, не проблема на Core 2 Duo, выполняющем Windows XP и JRE 1.5.0_06.

В тесте с тремя потоками я не вижу System.nanoTime () идущий назад. Процессоры и заняты, и потоки засыпают иногда для вызова перемещающихся потоков.

[РЕДАКТИРОВАНИЕ] я предположил бы, что это только происходит на физически отдельных процессорах, т.е. что счетчики синхронизируются для нескольких ядер на том же, умирают.

Linux исправляет для несоответствий между центральными процессорами, но Windows не делает. Я предлагаю, чтобы Вы предположили, что System.nanoTime () только с точностью до приблизительно 1 микросекунды. Простой способ получить более длительную синхронизацию состоит в том, чтобы назвать нечто () 1000 или больше раз и разделить время на 1 000.

Я сделал немного поиска и нашел, что, если Вы педантичны затем да, это можно было бы считать бесполезным... в особенности ситуации... это зависит от того, как время, чувствительное Ваши требования...

Выезд эта кавычка от сайта Sun Java:

часы реального времени и System.nanoTime () и на основе того же системного вызова и таким образом на основе тех же часов.

С Java РТС, все основанные на времени API (например, Таймеры, Периодические Потоки, Крайний срок, Контролируя, и т.д) основаны на таймере с высоким разрешением. И вместе с приоритетами в реальном времени они могут удостовериться, что соответствующий код будет выполнен в нужное время для ограничений реального времени. Напротив, обычные API Java SE предлагают всего несколько методов, способных к обработке времен с высоким разрешением без гарантии выполнения в установленный срок. Используя System.nanoTime () между различными точками в коде для выполнения измерений прошедшего времени должно всегда быть точным.

Java также имеет протест в течение нановремени () метод:

Этот метод может только использоваться для измерения прошедшего времени и не связан ни с каким другим понятием системы или тактовое стеной время. Возвращенное значение представляет наносекунды с некоторого фиксированного, но произвольного момента времени (возможно, в будущем, таким образом, величины могут быть отрицательными). Этот метод обеспечивает точность наносекунды, но не обязательно точность наносекунды. Никакие гарантии не сделаны о том, как часто значения изменяются. Различия в последовательных вызовах, которые охватывают больше, чем приблизительно 292,3 года (2 <глоток> 63 наносекунды) точно не вычислят прошедшее время из-за числового переполнения.

казалось бы, что единственный вывод, который может быть сделан, состоит в том, что на нановремя () нельзя положиться как точное значение. По сути, если Вы не должны измерять времена, которые являются простыми нано секундами независимо затем, этот метод достаточно хорош, даже если получающаяся возвращенная величина отрицательна. Однако, если Вам нужна более высокая точность, они, кажется, рекомендуют использовать Java РТС.

Так для ответа на вопрос... никакое нановремя () не бесполезно.... его просто не самый благоразумный метод для использования в каждой ситуации.

Заявление об ограничении ответственности: я разработчик этой библиотеки

Возможно, вам это больше понравится:

http://juliusdavies.ca/nanotime/

Но он копирует DLL или Unix .so (общий объект) файл в домашний каталог текущего пользователя, чтобы он мог вызывать JNI.

Некоторая справочная информация находится на моем сайте по адресу:

http://juliusdavies.ca/posix_clocks/clock_realtime_linux_faq.html

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

При вычислении позиций графики в обновлении кадра nanoTime () приводит к НАМНОГО более плавному движению в моей программе.

И я тестирую только на многоядерных машинах.