Discussion :

[Emcy]

Bonjour,

j'ai créé une classe :

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
23
24
25
26
27
 
//exemple de création d'une classe
public class ClassTest {
	private int pVal;
	private static int pNbrObjetsDeLaclasse = 0;
 
	public ClassTest(){
		pVal = 0;
		pNbrObjetsDeLaclasse++;
	}
 
	public void setVal(int v){
		pVal = v;
	}
 
	public int getVal(){
		return pVal;
	}
 
	public static int getNbInstance(){
		return pNbrObjetsDeLaclasse;
	}	
 
	public void close(){
		pNbrObjetsDeLaclasse--;
	}	
}

comment faire pour détruire une instance de la classe pour qu'elle ne prenne plus d'espace mémoire ?

pour le moment je fais ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
 
	    ClassTest monObjet1 = new ClassTest();
	    monObjet1.setVal(10);
 
	    ClassTest monObjet2 = new ClassTest();
	    monObjet2.close();
	    monObjet2 = null;
 
	    System.out.println("Valeur = " + monObjet1.getVal());  
	    System.out.println("Nombre d'instances en cours : " + monObjet1.getNbInstance());

=> est-ce que monObjet2 est bien détruit en mémoire ?
=> n'est-il pas possible de le détruire en une seule commande (attention, il faut mettre à jour pNbrObjetsDeLaclasse avant sa destruction) ?

[herch]

salut,
il n'y pas de destructeur comme le c++ en java, c'est le garbage collector qui se charge de nettoyer la mémoire. Un objet est détruit par le garbage collector lorsqu'il n'y a aucune référence sur lui.
pour remplacer le destructeur, il y a en java la méthode finalize() qu'on peut redéfinir, cette méthode est appelée avant que l'objet soit détruit par le garbage collector
un exemple pour illustrer tout ceci

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
 
public class TestFinalisation
{
	public TestFinalisation()
	{
		System.out.println("Création de l'objet - Appel du constructeur");
	}
	protected void finalize() throws Throwable
	{
		System.out.println("Destruction de l'objet - Appel de la méthode finalize");
	}
	public static void main(String[] args)
	{
		TestFinalisation t = new TestFinalisation();
		//L'objet n'est plus référencé par la variable
		t = null;
		//On fait appel au garbage collector
		System.gc();
	}
}

la sortie du programme est ainsi

Création de l'objet - Appel du constructeur
Destruction de l'objet - Appel de la méthode finalize

A noter qu'il est possible que la méthode finalize ne soit pas appelée par le gc, alors pour être sur on pourrait faire appel à la méthode System.runFinalization()

[Emcy]

A noter qu'il est possible que la méthode finalize ne soit pas appelée par le gc, alors pour être sur on pourrait faire appel à la méthode System.runFinalization()

=> il faut lancer System.runFinalization() après System.gc() pour être sur de la destructioon de l'objet ? ... j'ai lancé System.runFinalization() seul et ça ne ne lance pas finalize() (contrairement à System.gc() )

[herch]

j'ai lancé System.runFinalization() seul et ça ne ne lance pas finalize() (contrairement à System.gc() )

en effet... j'avais seulement testé avec la méthode gc sans le runFinalisation

[Emcy]

ok, merci pour les infos

[adiGuba]

Salut,


System.gc() et System.runFinalization() n'ont aucune garantie de résultat et se contente de "demander" au GC s'il a le temps de faire cela...

Mais globalement ces méthodes NE DEVRAIENT PAS être utilisées par le développeurs Java car il va à l'encontre du principe même du GC ! Et surtout cela aboutit généralement à des performances moindres du fait de cycle GC inutile...

• Si on n'utilises des ressources non-critiques (de la mémoire), dans 99% des cas le GC se débrouille très bien et libèrera la mémoire au mieux.
• Si on a des ressources critiques dont l'utilisation doit être le plus court possible (flux, socket, connexion JDBC, etc.) alors on doit libérer explicitement les ressources via une méthode close() dans un try/finally...

Attention également car l'utilisation des méthodes finalize() à tendance à donner plus de boulot au GC (qui doit surveiller les "résurrections") et cela peut entrainer un allongement de la durée de libération réelle de l'objet...

a++