Java предоставляет доступ к двум методам получения текущего времени: System.nanoTime() и System.currentTimeMillis(). Первый дает результат в наносекундах, но реальная точность намного хуже (много микросекунд).
Обеспечивает ли JVM наилучшую возможную ценность для каждой конкретной машины? В противном случае, есть ли какая-нибудь библиотека Java, которая может дать более точные измерения, возможно, за счет привязки к конкретной системе?
Проблема с получением сверхточных измерений времени заключается в том, что некоторые процессоры не могут/не обеспечивают такие крошечные приращения.
Насколько я знаю, System.currentTimeMillis() и System.nanoTime() — лучшее измерение, которое вы сможете найти.
Обратите внимание, что оба возвращают значение long.
В Java немного бессмысленно измерять время до наносекундного масштаба; случайное попадание GC легко уничтожит любую точность, которую это могло бы дать. В любом случае, в документации указано, что, хотя это дает точность в наносекундах, это не то же самое, что точность в наносекундах; и есть операционные системы, которые в любом случае не сообщают о наносекундах (поэтому при доступе к ним вы найдете ответы, квантованные до 1000; это не удача, это ограничение).
Не только это, но и в зависимости от того, как эта функция на самом деле реализована в ОС, вы все равно можете обнаружить квантованные результаты (например, ответы, которые всегда заканчиваются на 64 или 128 вместо промежуточных значений).
Также стоит отметить, что цель метода состоит в том, чтобы найти две разницы во времени между некоторым (близким) временем начала и сейчас; если вы берете System.nanoTime() в начале долго работающего приложения, а затем используете System.nanoTime() много времени спустя, это может быть довольно далеко от реального времени. Таким образом, вы должны действительно использовать его только в течение периодов менее 1 с; если вам нужно более длительное время работы, миллисекунд должно быть достаточно. (А если это не так, то придумайте последние несколько цифр; вы, вероятно, произведете впечатление на клиентов, и результат будет таким же достоверным.)
К сожалению, я не думаю, что на данный момент Java RTS достаточно развита.
Время Java пытается обеспечить наилучшее значение (они фактически делегируют собственный код для вызова получения времени ядра). Тем не менее, спецификации JVM делают это грубое измерение времени отказом от ответственности в основном для таких вещей, как действия GC и поддержка базовой системы.
Я не понял, как обратиться к #1, если только вашему приложению не нужно выполнять GC. Приличное приложение среднего размера, вероятно, иногда тратит десятки миллисекунд на паузы GC. Вам, вероятно, не повезло, если ваше требование к точности ниже 10 мс.
Что касается № 2, вы можете настроить ядро Linux на дать больше точности. Тем не менее, вы также получаете меньше из своей коробки, потому что теперь контекст ядра переключается чаще.
Возможно, стоит взглянуть на это под другим углом. Есть ли причина, по которой OPS требует точности на 10 мс ниже? Можно ли сказать оператору, что точность составляет 10 мс, И также просмотреть журнал GC в это время, чтобы они знали, что время с точностью +-10 мс без активности GC в это время?
Если вы хотите записать какое-то явление порядка наносекунд, вам действительно нужна операционная система реального времени. Точность таймера будет сильно зависеть от реализации в операционной системе таймера высокого разрешения и базовое аппаратное обеспечение.
Однако вы все равно можете использовать Java, так как доступны версии RTOS.
JNI: создайте простую функцию для доступа к инструкции Intel RDTSC или регистру PMCCNTR сопроцессора p15 в ARM.
Чистая Java: вы можете получить лучшие значения, если готовы отложить до тиканья часов. Вы можете вращать проверку System.nanoTime() до тех пор, пока значение не изменится. Если вы знаете, например, что значение System.nanoTime() изменяется каждые 10000 итераций цикла на вашей платформе на величину DELTA, тогда фактическое время события было finalNanoTime-DELTA*ITERATIONS/10000. Вам нужно будет «разогреть» код, прежде чем проводить фактические измерения.
Взлом (только для профилирования и т. д.): если сборка мусора сбивает вас с толку, вы всегда можете измерить время, используя высокоприоритетный поток, работающий во втором jvm, который не создает объекты. Заставьте его вращаться, увеличивая длину в общей памяти, которую вы используете в качестве часов.
