System.currentTimeMillis () vs. new Date () vs. Calendar.getInstance (). GetTime ()

En Java, ¿cuáles son las implicaciones de rendimiento y recursos del uso

System.currentTimeMillis() 

vs.

new Date() 

vs.

Calendar.getInstance().getTime()

Según tengo entendido, System.currentTimeMillis()es el más eficiente. Sin embargo, en la mayoría de las aplicaciones, ese valor largo necesitaría convertirse a una Fecha o algún objeto similar para hacer algo significativo para los humanos.

System.currentTimeMillis()obviamente es el más eficiente, ya que ni siquiera crea un objeto, sino new Date()que en realidad es solo una envoltura delgada de un largo, por lo que no está muy lejos. CalendarPor otro lado, es relativamente lento y muy complejo, ya que tiene que lidiar con la considerable complejidad y todas las rarezas inherentes a las fechas y horas (años bisiestos, horario de verano, zonas horarias, etc.).

Por lo general, es una buena idea tratar solo con marcas de tiempo u Dateobjetos largos dentro de su aplicación, y solo usarlos Calendarcuando realmente necesite realizar cálculos de fecha / hora, o formatear fechas para mostrarlos al usuario. Si tiene que hacer mucho de esto, usar Joda Time es probablemente una buena idea, para una interfaz más limpia y un mejor rendimiento.

Mirando el JDK, el constructor más interno para Calendar.getInstance()tiene esto:

public GregorianCalendar(TimeZone zone, Locale aLocale) {
    super(zone, aLocale);
    gdate = (BaseCalendar.Date) gcal.newCalendarDate(zone);
    setTimeInMillis(System.currentTimeMillis());
}

entonces ya hace automáticamente lo que sugieres. El constructor predeterminado de Date contiene esto:

public Date() {
    this(System.currentTimeMillis());
}

Por lo tanto, realmente no es necesario obtener la hora del sistema específicamente a menos que desee hacer algunos cálculos matemáticos antes de crear su objeto Calendario / Fecha. También tengo que recomendar joda-time para usar como reemplazo de las propias clases de calendario / fecha de Java si su propósito es trabajar mucho con los cálculos de fecha.

Si está USANDO una fecha, le recomiendo que use jodatime, http://joda-time.sourceforge.net/ . Usar System.currentTimeMillis()campos que son fechas parece una muy mala idea porque terminarás con un montón de código inútil.

Tanto la fecha como el calendario están seriamente alterados, y el calendario es definitivamente el peor de todos.

Le aconsejaría que lo use System.currentTimeMillis()cuando realmente esté operando con milisegundos, por ejemplo, así

 long start = System.currentTimeMillis();
    .... do something ...
 long elapsed = System.currentTimeMillis() -start;

Prefiero usar el valor devuelto por System.currentTimeMillis()para todo tipo de cálculos y solo uso Calendaro Datesi realmente necesito mostrar un valor que sea leído por humanos. Esto también evitará el 99% de sus errores de horario de verano. :)

En mi máquina intenté comprobarlo. Mi resultado:

Calendar.getInstance (). GetTime () (* 1000000 veces) = 402ms
nueva Fecha (). getTime (); (* 1000000 veces) = 18 ms
System.currentTimeMillis () (* 1000000 veces) = 16 ms

No te olvides de GC (si usas Calendar.getInstance()o new Date())

Dependiendo de su aplicación, puede considerar usar en su System.nanoTime()lugar.

Intenté esto:

        long now = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            new Date().getTime();
        }
        long result = System.currentTimeMillis() - now;

        System.out.println("Date(): " + result);

        now = System.currentTimeMillis();
        for (int i = 0; i < 10000000; i++) {
            System.currentTimeMillis();
        }
        result = System.currentTimeMillis() - now;

        System.out.println("currentTimeMillis(): " + result);

Y el resultado fue:

Fecha (): 199

currentTimeMillis (): 3

System.currentTimeMillis() obviamente es el más rápido porque es solo una llamada al método y no se requiere recolector de basura.