rap - ¿Es System.currentTimeMillis() la mejor medida del rendimiento de tiempo en Java?
big o rap (7)
¿Es System.currentTimeMillis () la mejor medida del rendimiento de tiempo en Java? ¿Hay algún error al usar esto para comparar el tiempo antes de que se tome la acción y el tiempo después de la acción? ¿Hay una mejor alternativa?
Además de System.nanoTime() , JMX es probablemente la mejor opción viable:
java.lang.management.ManagementFactory.getThreadMXBean()
puede consultar el tiempo de CPU del subproceso actual (medido en nano segundos pero no con nano segundos de precisión, como para System.nanoTime ())
Antes de Java 1.5 solo existía System.currentTimeMillis. Sin embargo, la granularidad del valor depende del sistema operativo subyacente y puede ser grande. En Windows XP a veces terminé con huecos de 20 ms. Escuché que Linux es mucho mejor con brechas en el rango de 1-2ms.
Con Java 1.5 también puedes usar System.nanoTime. Nunca tuve problemas con este.
Puede usar el Cronómetro de Google Guava, lo que hace que medir el tiempo sea muy fácil.
Si necesita mediciones de tiempo monótonas, System.nanoTime es una mejor opción. System.currentTimeMillis está sujeto a las variaciones de tiempo UTC - segundos de salto, actualizaciones NTP y jitter, así como a los usuarios que configuran el reloj del sistema *. Esto puede causar algunos fallos espectaculares en ciertos tipos de aplicaciones de temporización. Se supone que System.nanoTime es inmune a todo eso.
Los problemas con System.nanoTime incluyen un desbordamiento numérico periódico y una inexactitud de la temporización a largo plazo, lo que hace que System.currentTimeMillis sea mejor durante períodos de tiempo más largos (siempre que los usuarios dejen el reloj del sistema solo). Tenga en cuenta que los cambios de horario de verano y de zona horaria no deben afectar a System.currentTimeMillis.
* Windows "Sincronización con el tiempo de Internet" realiza cambios paso a paso. Esto puede ser muy perjudicial, a diferencia de una implementación de cliente NTP adecuada que "persigue" al servidor ajustando la frecuencia de la base de tiempo del cliente.
Una consecuencia es que esto mide el tiempo real transcurrido, no el tiempo de CPU, por lo que depende mucho de la carga del sistema. Esto está bien si está en una máquina de otro modo libre, pero a veces puede producir resultados interesantes si otros procesos están tratando de hacer el trabajo.
Este artículo tiene una solución interesante al problema.
Espero que no, es lo que uso cuando no uso nanoTime() .