Combien d'octets de mémoire utilise un objet java.util.Date ?

Question

Je dois stocker une grande quantité de dates (potentiellement assez importante pour que la quantité d'espace heap utilisée soit une préoccupation donc s'il vous plaît, pas de leçons sur l'optimisation prématurée), et je me demande s'il est judicieux d'utiliser une sorte de représentation primitive au lieu de java.util.Date (ou une autre classe de Date existante). Je sais que je pourrais faire un profilage pour essayer, mais est-ce que quelqu'un sait exactement combien d'octets de mémoire utilise un objet Date unique?

Answer 1

Ma réaction instinctive était que le surdébit de mémoire pour Date serait très faible. En examinant le code source, il semble que la classe contient seulement un champ d'instance (un long appelé millisecondes). Cela signifie que la taille d'un objet date est la taille d'un long plus la taille d'une instance d'objet - c'est-à-dire, très petite.

J'ai ensuite trouvé ce code qui crée des milliers d'objets pour déterminer la taille de l'objet. Il dit que la taille de java.util.Date est de 32 octets. Comparez cela avec simplement stocker la date comme un long (ce qui se fait en interne) - un long fait 8 octets, donc vous devez payer quatre fois pour la commodité d'avoir un objet date.

Cependant, le surdébit de création d'objets n'est pas très élevé. Donc si vous êtes vraiment inquiet à propos de l'espace, stockez les dates comme longs et créez un objet Date au besoin.

Answer 2

Utiliser le type primitif long ?

Ce n'est pas un objet, donc moins d'espace, et les dates peuvent être exprimées en tant que valeur longue. Ensuite, convertissez de l'avant en arrière entre Date et long lorsque vous voulez stocker les dates et utiliser moins de mémoire.

Answer 3

En utilisant le cadre d'instrumentation de Java, getObjectSize indique que c'est 24B.

Answer 4

Comme répondu ici également :

La manière la plus simple de répondre à cette question est de regarder le code source de java.util.Date.

Elle possède seulement 2 champs non-statiques (Java 1.7.0_55) :

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

long occupe 8 octets en mémoire et cdate est une référence d'objet qui occupe 4 octets. Donc un total de 12 octets.

Si cdate était instancié, cela pourrait nécessiter des octets supplémentaires en mémoire, mais si vous regardez également les constructeurs, parfois il ne sera même pas touché, et dans d'autres cas il sera mis à null à la fin du constructeur, donc le résultat final est toujours 12 octets.

Ceci est uniquement pour créer un Date. Si vous appelez des méthodes sur le Date (par exemple Date.toString()), cela va créer et stocker un objet dans le champ cdate qui ne sera pas supprimé. Donc si vous appelez certaines méthodes sur le Date, son utilisation en mémoire augmentera.

Remarque : Les références d'objet peuvent faire 64 bits sur des JVM 64 bits, auquel cas l'utilisation en mémoire serait de 16 octets.

Remarque #2 : Notez également que ce n'est que l'utilisation en mémoire de l'objet Date lui-même. Il est très probable que vous stockiez sa référence quelque part, par exemple dans un tableau ou une liste ou un champ dans une autre classe, ce qui nécessitera 4 octets supplémentaires (ou peut-être 8 octets sur des JVM 64 bits).

Answer 5

Si c'est littéralement une date, plutôt qu'une date et une heure, vous pourriez même utiliser un entier :

20110113