Все, что я читал о currentTimeMillis и nanoTime, похоже, сосредоточено только на точности. Если я ищу только прошедшее время в миллисекундах, какой из них мне следует использовать, если мне нужна лучшая производительность?
Похоже, что currentTimeMillis был бы ответом, поскольку мне не нужно преобразовывать окончательный ответ из ns в ms, но это с точки зрения моего приложения, и то, что происходит под капотом, может сделать его неправильным выбором, поэтому я ' м спрашиваю.
По сути, в чистой Java есть всего два варианта; вы уже назвали их:
System.currentTimeMillisSystem.nanoTimeОба метода являются встроенными в JVM.
В Linux они скомпилированы в прямые вызовы gettimeofday или clock_gettime соответственно.
В Windows - GetSystemTimeAsFileTime или QueryPerformanceCounter соответственно.
Производительность этих методов сильно зависит от платформы, архитектуры ЦП, версии ОС, версии Java, количества параллельных потоков и т. Д. на моем ноутбуке с Windows currentTimeMillis занимает 7 нс, а nanoTime - 16 нс, а на многопроцессорном сервере Linux оба метода занимают около 40 нс. Так что это зависит от обстоятельств.
Настоятельно рекомендую прочитать сообщение Алексея Шипилёва Нанотрастение нанотрему охватывает многие аспекты измерения времени в Java.
Вы не должны использовать currentTimeMillis, всегда используйте nanoTime для измерения прошедшего времени. На самом деле использование currentTimeMillis могло дать отрицательный результат. Это потому, что он использует системные часы, которые корректируются (иногда идут в обратном направлении) на время в вашем часовом поясе. Метод nanoTime использует часы, запускаемые JVM, которые используются именно для отсчета времени.
currentTimeMillisнапрямую, делая ваши измерения в некоторых случаях совершенно неверными. Если вы можете жить с этим, сделайте это. В противном случае используйте nanoTime, который является строго монотонным счетчиком и является причиной, по которой вам следует использовать nanoTime для любого серьезного приложения. - person zapl schedule 26.10.2016