Dimensioni oggetto "Data" Java

Question

Come determinare in modo efficace la dimensione di un oggetto Date nella memoria?

Inizialmente ha attraversato questo link che parla di 9 byte per un oggetto data ..

stavo cercando di scoprirlo quando ho trovato questo link, dove si parla di 32 byte !!! ! per un oggetto data in memoria.

Date Object Size in Memory

aiuto gentile.

Motivo per ragionare su queste righe: Sto caricando milioni di oggetti di una certa classe in memoria, per alcuni calcoli. Una delle variabili in quella classe è un oggetto Date. Posso memorizzare il valore come un valore lungo, ma ciò richiederebbe piccoli accorgimenti nel codice. Sto pensando di mantenere l'impronta della memoria al minimo valore possibile. Per fare ciò, ho bisogno di conoscere i requisiti di memoria esatti in ogni caso per prendere una chiamata sullo stesso.

Answer 1

Il tuo primo link parla della dimensione quando serializzato, stai parlando della dimensione in memoria. Ecco perché le dimensioni sono diverse.

Serializzato, come per il collegamento, 9 byte per il salvataggio lungo.

In memoria, come per il secondo collegamento, 32 byte per gli oggetti lunghi e altri che consentono di lavorare con la data.

Answer 2

Dipende dalla vostra implementazione, cosa intendete fare con esso e come definite e misurate le dimensioni. Ad esempio,

public static void main(String[] args) { 
    Date d = new Date(); 
    ByteArrayOutputStream baos = new ByteArrayOutputStream(); 

    try (ObjectOutputStream oos = new ObjectOutputStream(baos);) { 
     oos.writeObject(d); 
     oos.flush(); 
    } catch (Exception e) { 
     e.printStackTrace(); 
    } 
    byte[] written = baos.toByteArray(); 
    System.out.println(written.length); 
} 

uscite

46 

qui.

Modifica

Utilizzando la primitiva long utilizzerà sempre meno memoria quindi qualsiasi tipo di oggetto (Date incluso). Questo è fondamentalmente il motivo per cui Java include i primitivi. Infine, l'utilizzo di un'istanza di Calendar e la conservazione dei valori come long dovrebbero offrire la flessibilità necessaria per ridurre al minimo le modifiche al codice.

Answer 3

Il modo più semplice per rispondere a questa domanda è guardare il codice sorgente di java.util.Date.

Ha solo 2 campi non statici (Java 1.7.0_55):

private transient long fastTime; 
private transient BaseCalendar.Date cdate; 

long ha una dimensione di memoria di 8 byte e cdate è un riferimento all'oggetto che ha una dimensione di 4 byte. Quindi un totale di 12 byte.

Se cdate sarebbe istanziato, potrebbe richiedere ulteriori byte nella memoria, ma se si guardano le costruttori troppo, a volte sarà nemmeno essere toccato, e in altri sarà null -ed alla fine del il costruttore, quindi il risultato finale è anche 12 byte.

Questo è solo per la creazione di Date. Se si chiamano i metodi su Date (ad esempio Date.toString()), lo crea e memorizza un oggetto nel campo cdate che non verrà cancellato. Pertanto, se chiami determinati metodi su Date, l'utilizzo della memoria aumenterà.

Nota: I riferimenti agli oggetti potrebbero essere lunghi 64 bit su JVM a 64 bit, nel qual caso l'utilizzo della memoria sarebbe di 16 byte.

Nota n. 2: Si noti inoltre che questo è solo l'utilizzo della memoria dell'oggetto Date stesso. Molto probabilmente memorizzerai il suo riferimento da qualche parte, ad es. in un array o elenco o un campo in qualche altra classe che richiederà 4 byte aggiuntivi (o forse 8 byte su JVM a 64 bit).