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

In Java, quali sono le prestazioni e le implicazioni delle risorse dell'utilizzo

System.currentTimeMillis() 

vs.

new Date() 

vs.

Calendar.getInstance().getTime()

A quanto ho capito, System.currentTimeMillis()è il più efficiente. Tuttavia, nella maggior parte delle applicazioni, quel valore lungo dovrebbe essere convertito in una Data o in un oggetto simile per fare qualcosa di significativo per l'uomo.

System.currentTimeMillis()è ovviamente il più efficiente in quanto non crea nemmeno un oggetto, ma in new Date()realtà è solo un involucro sottile di un lungo, quindi non è molto indietro. Calendard'altra parte, è relativamente lento e molto complesso, poiché deve fare i conti con la considerevole complessità e tutte le stranezze inerenti a date e orari (anni bisestili, ora legale, fusi orari, ecc.).

In genere è una buona idea gestire solo timestamp o Dateoggetti lunghi all'interno dell'applicazione e utilizzarli solo Calendarquando è effettivamente necessario eseguire calcoli di data / ora o formattare le date per visualizzarle all'utente. Se devi fare molto di questo, usare Joda Time è probabilmente una buona idea, per un'interfaccia più pulita e prestazioni migliori.

Guardando il JDK, il costruttore più interno per Calendar.getInstance()questo ha questo:

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

quindi fa già automaticamente ciò che suggerisci. Il costruttore predefinito di Date contiene questo:

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

Quindi non c'è davvero bisogno di ottenere l'ora di sistema in modo specifico a meno che tu non voglia fare un po 'di matematica con esso prima di creare l'oggetto Calendar / Date con esso. Inoltre, devo consigliare joda-time da utilizzare in sostituzione delle proprie classi di calendario / data di Java se il vostro scopo è quello di lavorare molto con i calcoli della data.

Se stai USANDO una data, ti consiglio vivamente di usare jodatime, http://joda-time.sourceforge.net/ . Usando System.currentTimeMillis()per i campi che lo sono date sembra una pessima idea perché finirai con un sacco di codice inutile.

Sia la data che il calendario sono seriamente corretti e Calendar è sicuramente il peggior performer di tutti.

Ti consiglierei di usare System.currentTimeMillis()quando stai effettivamente operando con millisecondi, ad esempio in questo modo

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

Preferisco utilizzare il valore restituito da System.currentTimeMillis()per tutti i tipi di calcoli e usare solo Calendaro Datese devo davvero visualizzare un valore letto dagli umani. Ciò eviterà anche il 99% dei bug dell'ora legale. :)

Sulla mia macchina ho provato a controllarlo. Il mio risultato:

Calendar.getInstance (). GetTime () (* 1000000 volte) = 402ms
nuova data (). getTime (); (* 1000000 volte) = 18ms
System.currentTimeMillis () (* 1000000 volte) = 16ms

Non dimenticare GC (se usi Calendar.getInstance()o new Date())

A seconda della tua applicazione, potresti considerare di utilizzare System.nanoTime()invece.

Ho provato questo:

        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);

E il risultato è stato:

Data (): 199

currentTimeMillis (): 3

System.currentTimeMillis() è ovviamente il più veloce perché è solo una chiamata di metodo e non è necessario il Garbage Collector.