Discussion :

[michelp3]

Bonjour, une petit code et une question simple

t est-il éligible au gerbage collector ???

Merci

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
19
20
21
22
 
package test_suite;
 
class S {
 
	T t ;
	public S(){
		t = new T();
	}
}
 
class T {
 
}
 
public class Q139 {
	public static void main(String[] args) {
 
		S s = new S();
		s = null;
	}
}

[Influenza]

Bonjour,

Tout est éligible au GC du moment qu'on ne s'en sert plus.
Une fois que ton instance de "S" sera inutile, "t" le deviendra aussi et sera éligible.

Mathieu

PS: J'aime bien le "gErbage colllector"

[michelp3]

OK mais une fois s = null;

t devient éligible au garbage collector ???

[Influenza]

C'est plus subtile que ça. Même si tu ne mets pas ta variable à null, elle sera éligible au GC. De manière générale, quand tu codes en Java, tu n'as pas besoin de te soucier du GC. Java nettoie très bien la mémoire depuis la version 1.4 sans que le développeur n'ait besoin de faire d'effort particulier. (genre casser les références cycliques...)

Mathieu

[michelp3]

Moi je demande çà par ce que j'ai besoin de savoir QUAND ???

[thelvin]

Baisse le ton.

Ça n'a pas de sens, j'ai "besoin de savoir quand." Tout dépend précisément quelle est la problématique qui t'intéresse. Évaluer le moment d'une éligibilité en fonction de quelques lignes de code, n'est pas une problématique.

On peut par exemple chercher à savoir quand on pourra compter sur le fait qu'un objet est effacé de la mémoire (réponse : ça dépend des OS, mais en tout cas pas avant que le processus Java ne soit terminé.) Ou d'autres choses. Des vraies motivation d'analyse.

Sur le plan purement théorique, t est éligible au garbage-collector dès que l'instance qui le contient l'est (la première valeur de S.) Et elle l'est juste après l'appel à new S(), puisqu'elle n'est pas utilisée ensuite.

Sur le plan simpliste, accessible aux débutants, pareil : t est éligible au garbage-collector dès que l'instance qui le contient l'est. Et cette instance l'est dès que plus rien ne pointe vers elle, donc que s ne pointe plus vers elle puisqu'il pointe vers null.

Toutefois, dans les deux cas, ça ne servait à rien de faire s = null;. En théorie ce qui compte c'est que plus rien ne l'utilise, et c'est le cas dès la fin de son constructeur. En plus simple ce qui compte, c'est que plus rien ne pointe vers elle, ce qui arrive de toute façon quand la portée de s se termine.

[michelp3]

OK ce n'est pas très réaliste mais c'est une question pour la certification ...

je réponds à ce que on me demande

Ce n'est pas moi hélas qui fait les questions ...

Merci pour ta réponse complète

[thelvin]

Je m'en doutais, mais on est pas là pour faire tes devoirs, tu sais.

Si c'est pour la certif, il faut le dire et demander comment ça marche. Et on t'aurait donné des éléments de réponse, le contexte étant simple, les réponses aussi.
Pas "c'est quoi la réponse à cette question ?"

[michelp3]

Vous devenez très autoritaire ... même si à mon Age (53) , je n'ai pas honte de

me faire aider pour faire mes devoirs !!!

[thelvin]

Désolé, c'est les règles.

De toute façon je pense pas que se faire faire son travail devienne plus efficace avec l'âge. Soit on devient capable de faire, soit non.

[michelp3]

Bonne soirée quand meme , jeune grincheux ...

[Influenza]

Il fallait me mettre les propositions du QCM, j'aurais coché une réponse
Bon courage à toi pour ta préparation de la certification.

Mathieu

[tchize_]

Pour répondre à ta question, la réponse est "quand le jvm constate qu'elle n'en a plus besoin". D'une manière générale, une instance deviens collectable si il n'y a plus aucun chemin de hard reference partant d'un objet non collectable vers cette instance.

La manière dont le garbage collector fait ces calculs n'est pas précisé dans la spec et laissé libre à tout implémentation de la jvm.

[bouye]

De manière générale, quand tu codes en Java, tu n'as pas besoin de te soucier du GC.

Et de manière particulière, notamment en codage d'interface graphiques, ce genre ce mauvais comportement, que des années de lobotomie "y a un GC, ont generalise et font que la plupart des gens pense qu'il n'y a pas besoin de liberer le refs ou de faire le nettoyage" ne peut au final que mener vers des OutOfMemoryError ou des programmes qui pour tourner on besoin de flags du genre -Xmx800m ou des choses du genre.

Effectivement, plus personne ne prend le temps d'aller desenregistrer ses listeners et autres callbacks une fois qu'on plus besoin d'avoir un écran a portée de main ; déjà avec Swing c’était pas mal au niveau passage et conservation de références, mais avec FX c'est pire.
A voir la discussion "How to deal with Memory Leaks, that are caused by Binding" avec notamment plusieurs interventions de membres de l’équipe de JavaFX dont Richard Bair, le Lead Architect.

D'ailleurs, je ne me suis pas encore penché sur le cas du JDK8 et de ses lambdas qui permettent de passer... des références de methodes ce qui devrait, en théorie, encore augmenter le nombre de références "cachées" (auxquelles le programmeur ne pense pas a priori) vers un objet.

Et il y a également des fuites mémoires ou non-optimisations dans les implémentations de base des collections. Ce n'est pas pour rien que la session a laquelle il m'a été donné de participer et qui avait le plus de spectateurs (beaucoup de gens qui n'avaient pas booké la session ont été obligés de rester en dehors de la salle) lors de la JavaOne 2012 était :

From Java code to Java heap: Understanding and optimizing your appl...

Java nettoie très bien la mémoire depuis la version 1.4 sans que le développeur n'ait besoin de faire d'effort particulier.

I beg to differ...
C'est un peu mieux avec le G1 et le JDK8 mais ce n'est toujours pas assez performant (coté client et même avec un flag -server). Une analyse de mes programmes avec jmap montre que les objets sont conservés en mémoire bien plus longtemps que prévu et ce même quand mon propre code n'a plus aucune référence dessus. Le pire c'est que jconsole permet effectivement de réclamer la mémoire assez efficacement sur un programme qui tourne. Bref, vivement la self-tunning JVM promise pour Java 9 et en retard puisque sans arrêt repoussée.

[Influenza]

Bonjour,

J'avais effectivement mis "en général" pour simplifier le débat, mais il est vrai qu'il y a des problèmes de "memory leak" en Java qu'il faut traiter. Cependant, pour avoir connu Java 1.2 et 1.3 où un simple objet A qui référence un objet B et B qui référence A ne pouvaient être détruits, la JVM a fait depuis d'énormes progrès...
Après la JVM rend la mémoire quand elle veut. Même les objets qui devraient être détruits, la JVM ne les enlèvera que si elle le juge nécessaire...

Mathieu

PS : La présentation ne fonctionne pas chez moi, mais m'intéresse fortement.

[bouye]

Malheureusement le site de développez fait une intégration automatique de l'URL de la présentation dans le topic mais tu peux aller sur le site d'origine en cliquant sur son titre dans le cadre.

La version 2013 (je n'ai pas été à la JavaOne 2013) est :

http://fr.slideshare.net/cnbailey/memory-efficient-java

Normalement les sites des JavaOne 2012 et 2013 devraient avoir les enregistrement audio synchronisés sur la présentation.

[tchize_]

Malheureusement le site de développez fait une intégration automatique de l'URL de la présentation dans le topic

http://www.slideshare.net/cnbailey/j...e-to-java-heap