Discussion :

[Underzeci]

Salut,

Je me posais une question sur la place que prenne en mémoire les variables qui référencent un objet. Je me prend un exemple simple pour fixer les idées :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
public class Test {
 
	public static void main(String[] args) {
 
		Test t1 = new Test();;
		Test t2 = null;
		Test t3;
               // reste du code

Pour t1:
je crée un objet en mémoire, sa référence est donné par t1 et vaut par exemple Test@15db9742
une adresse codée donc sur 32 bits qui correspond à l'adresse où se situe réellement l'objet en mémoire.

Pour t2 :
t2 ne référence aucun objet. Si j'utilise un system.ou.println(t2), j'obtiens bien sûr null, mais il y a bien un espace mémoire réservé pour stocker la variable t2 (même si cette variable pointe vers aucun objet). Peut on réellement connaître la valeur que prend cette variable ?

Pour t3 :
je ne vois pas vraiment la différence avec t2. t3 n'est pas initialisé donc ne pointe vers aucun objet. C'est comme si on vait t3 = null, non ? Y a t il un espace mémoire réservé pour t3 ? Peut on connaitre la valeur qui est stocké dans t3 ?

Merci

[thelvin]

Hello,

En Java il n'y a pas de notion d'adresse mémoire. Notamment la donnée Test@15db9742 représente un identifiant unique d'objet à l'intérieur du cycle de vie de la JVM, mais n'a absolument rien à voir avec une adresse physique. De plus, cette donnée est relative à l'objet lui-même, comment est-il identifié par unicité, et n'a rien à voir avec les variables qui pointent vers lui.

Certes en informatique il n'y a pas de magie, et quand on stocke des données il faut bien qu'elles soient quelque part en mémoire. Mais Java s'organise comme ça lui chante et ne te fournira pas d'information sur les emplacements mémoire physique, sauf à moins que tu fasses des bouts de code en JNI, auquel cas la JVM passe par tout un ensemble d'étapes pour le permettre.

De plus dans l'exemple que tu donnes là, les variables sont des variables locales, qui apparaissent et disparaissent le temps d'exécution d'une méthode. Ça veut dire que leur cycle de vie n'est pas lié à un objet. Elles n'ont pas besoin d'exister durablement, dans un emplacement indépendant de la méthode qui a besoin d'elles. En informatique typique de telles variables seront stockées dans la pile, par opposition au tas dans lequel on met tout ce qui doit être sauvegardé durablement, typiquement les objets.

Typiquement c'est dans la pile, mais, la JVM est libre de faire ce qui l'arrange. Par exemple elle pourra préférer stocker une valeur dans un des registres du processeur. Dans ce cas-là, pas d'adresse, et pas vraiment de notion de taille occupée en mémoire.

Dans ton exemple, pour t1 il faut distinguer deux questions : stocker l'objet en mémoire et stocker en mémoire la variable qui pointe vers cet objet. L'objet lui-même aura la taille qu'il aura. La référence vers cet objet aura toujours la même taille quel que soit l'objet, sa classe etc. 32 bits sur un système 32 bits et 64 bits sur un système 64 bits.

Pour t2, c'est la même chose que t1 : une variable capable de stocker la référence d'un objet. Elles ont toutes la même taille, et peuvent toutes prendre soit la référence d'un objet soit null.

Pour t3, c'est particulier vu que c'est une variable locale et que tu ne l'as pas initialisée. Si elle n'est pas initialisée tu ne peux pas t'en servir : tu auras une erreur de compilation si tu essaies. Autrement dit c'est la même chose que si elle n'existait pas. Si tu déclares une variable locale sans l'initialiser, c'est la même chose que si tu ne faisais rien, et elle n'occupe aucun emplacement mémoire.

[Underzeci]

OK merci, c'est très clair.