Saltar al contenido

System.currentTimeMillis frente a System.nanoTime

Solución:

Si solo busca medidas extremadamente precisas de tiempo transcurrido, usar System.nanoTime(). System.currentTimeMillis() le dará el tiempo transcurrido más preciso posible en milisegundos desde la época, pero System.nanoTime() le da un tiempo preciso en nanosegundos, relativo a algún punto arbitrario.

De la documentación de Java:

public static long nanoTime()

Devuelve el valor actual del temporizador del sistema disponible más preciso, en nanosegundos.

Este método solo se puede utilizar para medir el tiempo transcurrido y no está relacionado con ninguna otra noción de sistema o tiempo de reloj de pared. El valor devuelto representa nanosegundos ya que algunos valores fijos pero arbitrarios origen tiempo (quizás en el futuro, por lo que los valores pueden ser negativos). Este método proporciona una precisión de nanosegundos, pero no necesariamente una precisión de nanosegundos. No se ofrecen garantías sobre la frecuencia con la que cambian los valores. Diferencias en llamadas sucesivas que abarcan más de aproximadamente 292 años (263
nanosegundos) no calculará con precisión el tiempo transcurrido debido al desbordamiento numérico.

Por ejemplo, para medir cuánto tiempo tarda en ejecutarse un código:

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

Consulte también: JavaDoc System.nanoTime () y JavaDoc System.currentTimeMillis () para obtener más información.

Como nadie más ha mencionado esto …

No es seguro comparar los resultados de System.nanoTime() llamadas entre diferentes subprocesos. Incluso si los eventos de los hilos ocurren en un orden predecible, la diferencia en nanosegundos puede ser positiva o negativa.

System.currentTimeMillis() es seguro para su uso entre hilos.

Actualización de Arkadiy: he observado un comportamiento más correcto de System.currentTimeMillis() en Windows 7 en Oracle Java 8. La hora se devolvió con una precisión de 1 milisegundo. El código fuente en OpenJDK no ha cambiado, por lo que no sé qué causa el mejor comportamiento.


David Holmes de Sun publicó un artículo de blog hace un par de años que tiene una visión muy detallada de las API de sincronización de Java (en particular System.currentTimeMillis() y System.nanoTime()), cuándo querría usar cuál y cómo funcionan internamente.

Dentro de la máquina virtual de Hotspot: relojes, temporizadores y programación de eventos – Parte I – Windows

Un aspecto muy interesante del temporizador utilizado por Java en Windows para las API que tienen un parámetro de espera temporizada es que la resolución del temporizador puede cambiar según las otras llamadas a la API que se hayan realizado: en todo el sistema (no solo en el proceso en particular) . Él muestra un ejemplo en el que se usa Thread.sleep() causará este cambio de resolución.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *