Discussion :

[Junta]

Bonjour,

Cela faisait quelques temps que je n'étais pas venu poser des questions tatillonnes sur ce forum, me revoici donc à la charge.

Aujourd'hui, je m'intéresse au problème de libération de la mémoire occupée par les objets Java.

Hypothèse de base : à partir d'un certain moment, je sais que les objets que j'utilise dans mon code ne seront plus utilisés.

Proposition : je me demande si la création de l'interface ci-après est viable :

Code :

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

1
2
3
4
5
6
7
public interface Destroyable {
	/**
         * Provoque la fermeture de toutes les ressources utilisées par l'objet et la libération de ces ressources.
         * <strong>Après l'appel de la méthode <code>destroy</code>, l'objet ne doit plus être utilisé.</strong>
         */
	void destroy();
}

L'idée serait qu'à partir du moment où je n'ai plus besoin de l'un de mes objets, je fais appel à la méthode destroy, de sorte de minimiser l'occupation mémoire réelle de mon application.

Exemple de classe "Destroyable" :

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 MaClasse {
	private Map<Object, Integer> map;
	private StringBuilder stringBuilder;
	private Destroyable destroyableObject;
 
	[...]
 
	public void destroy() {
		// Propagation
		destroyableObject.destroy();
 
		// Et nettoyage de l'objet
		destroyableObject = null;
		map.clear();
		map = null;
		stringBuilder = null;
	}
}

Sur le papier, ça a l'air bien, mais voila que PMD vient râler :

Code :

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

Assigning an Object to null is a code smell. Consider refactoring.

D'où mes questions :
- est-ce que quelqu'un a déjà expérimenté un mécanisme similaire ?
- Est-ce qu'il peut permettre d'optimiser la gestion de la mémoire, ou bien est-il complètement inutile car déjà implémenté par le Garbage Collector ?

Merci d'avance

Junta

[adiGuba]

Salut,


La question serait plutôt de savoir ce que fait "MaClasse", et la raison pour laquelle ses attributs serait d'un coup inutile ?

a++

[Junta]

C'est vrai que mon exemple n'est pas très parlant, en voici un autre :

En gros, l'application ressemblerait à un Notepad à base d'onglets.

La classe "Ecrivain" a pour but d'écrire des événements dans un fichier, et ce jusqu'à ce que
1 - l'application se termine
2 - l'utilisateur décide de fermer l'onglet associé au fichier en cours de modification (mais ne termine pas l'application)

Elle ressemblerait donc à ça :

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
public class Ecrivain {
	private BufferedWriter writer;
 
	[...]
 
	public void destroy() {
		// Fermeture des ressources
		try {
			writer.close();
		} catch (IOException e) {
			System.out.println("Attention ! Il y a eu une erreur !");
		}
 
		// Libération de la mémoire
		writer = null;
	}
}

Dans le cas 1 (l'application se termine), j'imagine que la libération de la mémoire n'est pas un problème puisque la JVM est également terminée.

Dans le cas 2, en revanche, l'application reste lancée. C'est seulement l'onglet associé au fichier qui est fermé. Et c'est là que je me pose la question de l'utilité de classes "Destroyable".

[tchize_]

Dans tous les cas, les ressources natives que tu utilise (socket, fichiers, etc) doivent être fermées. On peux se poser, par contre, la question de l'utilité de mettre ca dans une méthode destroy. En effet, il est beaucoup plus propre de mettre, par exemple, les writer.close() dans un bloc finally qui suit l'ouvertur du writer, sous peine d'une grosse prise de tete quand à s'assurer que ce sera bien appelé. Quand à la mise à null, d'un manière générale, elle ne sert à rien car le garbage collector sait très bien gérer ca. Bien évidement, si l'objet contenant doit rester en utilisation mais que son contenu doit etre vidé (ce qui n'est pas le cas de ton exemple), il faudra bien mettre à null, mais généralement, on jette le contenant avec le contenu

[adiGuba]

Dans le cas 1 (l'application se termine), j'imagine que la libération de la mémoire n'est pas un problème puisque la JVM est également terminée.

En effet il n'y a aucun problème dans ce cas là...

Dans le cas 2, en revanche, l'application reste lancée. C'est seulement l'onglet associé au fichier qui est fermé. Et c'est là que je me pose la question de l'utilité de classes "Destroyable".

Ton instance d'Ecrivain devrait être lié à ton onglet. Donc si tu supprimes ton onglet ton écrivain n'est plus accessible et sera alors libéré...

On distingue alors deux cas :

• La mémoire Java. Et là tu n'as pas grand chose à faire le GC saura se débrouiller.
• Les autres ressources, comme dans ce cas présent avec un flux (vers un fichier ?). Là le GC n'a alors plus rien à voir... et il faut traiter tout cela manuellement, donc oui il te faudra appeler une méthode de libération.

Mais perso je te conseillerait de te méfier de cela : c'est assez casse-gueule de conserver un flux en attribut, et le risque d'erreur est assez grand. Il serait préférable de limiter sa portée à une méthode, afin de s'assurer de sa fermeture...

Que fait la classe Ecrivain exactement ?

a++