Discussion :

[prugne]

Bonjour,
Je me base sur un exemple pour comprendre l’éligibilité des variables d'instances dans le gc.

J'ai une classe Island :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
public class Island {
   Island n;
   public static void main (String [] args){
 Island I2 = new Island();
 Island i3 = new Island();
 Island i4 = new Island();
 
i2.n = i3;
i3.n = i4;
i4.n = i2;
 
 
i2=null;
i3=null;
i4 = null;
}
}

Donc j'ai des 3 variables d'instances i2, i3, i4 qui pointent sur respectivement sur un objet Island en mémoire mais je ne comprend pas c'est les point suivants lorsqu'il y a une affectation de i2.n=i3
y a quelqu'un qui pourrai m'aider sur la compréhension ?
merci d'avance

[thelvin]

Donc j'ai des 3 variables d'instances i2, i3, i4 qui pointent sur respectivement sur un objet Island en mémoire

Non, ce sont des variables locales de la méthode main(), ce ne sont pas des variables d'instance.
Par contre, elles pointent chacune sur un objet Island en mémoire, certes.

Tu as une seule variable d'instance, et elle s'appelle n.

mais je ne comprend pas c'est les point suivants lorsqu'il y a une affectation de i2.n=i3

Cela affecte la variable d'instance n de i2. Ainsi, cette variable d'instance pointe vers i3.


Note : pour l'instant je ne vois pas trop le rapport avec l'éligibilité au gc.

[prugne]

Non, ce sont des variables locales de la méthode main(), ce ne sont pas des variables d'instance.
Par contre, elles pointent chacune sur un objet Island en mémoire, certes.

Tu as une seule variable d'instance, et elle s'appelle n.



Cela affecte la variable d'instance n de i2. Ainsi, cette variable d'instance pointe vers i3.


Note : pour l'instant je ne vois pas trop le rapport avec l'éligibilité au gc.

tu veux dire que i3 est affecté ài2.n?
après on met à null i2,i3,i4 donc ces variables locales ne pointent plus vers leur objet respectif...les objets sont liés entre eux non?
bon c'est un peu confus ...

[le y@m's]

Note : pour l'instant je ne vois pas trop le rapport avec l'éligibilité au gc.

J'imagine que cela a à voir avec les références cycliques. En effet, i2, i3 et i4 sont mise à null dans la méthode mais l'instance précédemment dans i2 est référencée par i3.n, l'instance précédemment dans i3 est référencée par i4.n et l'instance précédemment dans i4 est référencée par i2.n.
J'imagine que la question est de savoir si ces instances sont éligible par le GC alors qu'elles sont pourtant référencées.
La réponse est oui car ces instances ne sont plus "atteignables" (le GC gère les références cycliques).

[thelvin]

tu veux dire que i3 est affecté ài2.n?

Oui.

après on met à null i2,i3,i4 donc ces variables locales ne pointent plus vers leur objet respectif...les objets sont liés entre eux non?

Oui.
Enfin en principe mais, en effet, rien d'autre n'est lié à eux, le programme ne peut plus les atteindre, ils sont en effet éligibles pour le gc. Et donc ça n'a pas beaucoup de sens de se demander ce qui leur arrive et dans quel état ils sont : de toute façon ça ne peut plus avoir d'effet sur le programme.

bon c'est un peu confus ...

Pas vraiment... Les cycles sont une notion courante en informatique et mathématique.

[prugne]

Oui.



Oui.
Enfin en principe mais, en effet, rien d'autre n'est lié à eux, le programme ne peut plus les atteindre, ils sont en effet éligibles pour le gc. Et donc ça n'a pas beaucoup de sens de se demander ce qui leur arrive et dans quel état ils sont : de toute façon ça ne peut plus avoir d'effet sur le programme.



Pas vraiment... Les cycles sont une notion courante en informatique et mathématique.

Et ce cycle qui est une notation courante,cela correspond à un design pattern?
Suis pas familière ou encore peu avec ces notions de cycles....en java dans mon cas.

[atha2]

Je pense que thelvin fait allusion aux graphes.

[Robin56]

Je pense que thelvin fait allusion aux graphes.

Je confirme, il fait référence à la notion de référence cyclique (A qui référence B qui référence C qui référence A).

Et non ce n'est pas un design pattern. Un design pattern est un arrangement de classe déjà éprouvé (donc bonne pratique). Il permet de proposer une conception de classes répondant à un soucis d'architecture particulier. Tu auras plus de détails ici. Mais je deviens un peu hors sujet là.