Discussion :

[techz]

Bonjour à tous .
Voila , j'utilise un javaBean de portée Session et de type : <ArrayList<Object>> .
Ce Javabean contient des objets volumineux prenant beaucoup de place en mémoire .
Je pensais que etant donné que ce javabean etait de portée session , lorsque la session etait terminé (cad lorsque l'utilisateur ferme son navigateur) le javabean etait detruit et libère donc la mémoire qui lui etait allouée ainsi que tous les objets qu'il contenait (puisque dans mon cas , le javabean est un ArrayList<Object> .) .
Mais en fait il n'en est rien .
Lorsque je ferme le navigateur , l'occupation mémoire ne baisse pas .
J'ai donc pensé qu'il fallait attendre le timer de fin de session spécifié dans le fichier web.xml de tomcat et qui est de 30mn .
Mais au bout de 35 mn apres fermeture du navigateur , rien ne se passe .
J'ai donc décider de créer un bouton "QUITTER" sur le portail et quand je clique dessus cela appelle le fichier quitter.jsp suivant :

Code :

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

1
2
//monTableau etant mon javabean
monTableau = null;

Mais lorsque je clique sur "QUITTER" l'occupation mémoire ne baisse pas , et je n'ai pourtant aucune erreure .

je tente alors ca :

Code :

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

monTableau.clear();

Mais ca ne change rien .

Je ne comprend pas comment faire pour libérer la mémoire et détruire mon javaBean lorsque je n'en ai plus besoin .

Quelqu'un pourrait m'aider ?

[techz]

Du coup je viens d'essayer ca pour voir :

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
<%@page import="java.util.ArrayList"%>
<%
	out.println("Mémoire utilisée :" + (((Runtime.getRuntime().totalMemory()/1024)/1024)*100)/((Runtime.getRuntime().maxMemory()/1024)/1024)+"%<br>") ;
 
	ArrayList<String> monTableau = new ArrayList<String>();
 
	for (int i = 0 ; i < 80000000 ; i++)
	{
		monTableau.add("xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx");
	}
	out.println("Tableau rempli<br>");
 
	out.println("Mémoire utilisée :" + (((Runtime.getRuntime().totalMemory()/1024)/1024)*100)/((Runtime.getRuntime().maxMemory()/1024)/1024)+"%<br>") ;
 
	out.println("VIDAGE<br>");
 
	monTableau.clear();
	monTableau = null;
	System.gc();
 
	out.println("Mémoire utilisée :" + (((Runtime.getRuntime().totalMemory()/1024)/1024)*100)/((Runtime.getRuntime().maxMemory()/1024)/1024)+"%<br>") ;
%>

ET le resultat est :

Mémoire utilisée :0%
Tableau rempli
Mémoire utilisée :83%
VIDAGE
Mémoire utilisée :86%

[slim_java]

la gestion de la mémoire est prise en charge par le ramasse-miette.
mais il est possible d'invoquer le garbage collector avec

Code :

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

System.gc()

[adiGuba]

Salut,

Je pensais que etant donné que ce javabean etait de portée session , lorsque la session etait terminé (cad lorsque l'utilisateur ferme son navigateur) le javabean etait detruit et libère donc la mémoire qui lui etait allouée ainsi que tous les objets qu'il contenait (puisque dans mon cas , le javabean est un ArrayList<Object> .) .
Mais en fait il n'en est rien .
Lorsque je ferme le navigateur , l'occupation mémoire ne baisse pas .

La session d'une application web n'est pas détruite à la fermeture du navigateur ! Le serveur ne peut pas savoir le moment où le navigateur est fermé.

La session est conservé pendant un certain temps depuis la dernière action de l'utilisateur. C'est pourquoi il faut éviter de stocker n'importe quoi en session...

Code :

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

1
2
//monTableau etant mon javabean
monTableau = null;

S'il s'agit d'un bean en session il faut le supprimer de la session avec removeAttribute().

Je ne comprend pas comment faire pour libérer la mémoire et détruire mon javaBean lorsque je n'en ai plus besoin .

Il suffit de ne plus conserver de référence en session ni dans le scope application (ni en static !!!). Le GC se chargera de tout cela au moment opportun !

Toutefois tu ne verras pas de changement instantanément ! En effet le GC peut regrouper les libérations pour optimiser la gestion de la mémoire.
Mieux : si l'occupation mémoire de l'OS n'est pas trop important, il peut conserver cette espace mémoire afin de le réutiliser plus tard, en considérant que si ton application a utilisé beaucoup de mémoire, elle risque d'en avoir encore besoin...



a++

PS : Ne te base pas sur Runtime pour surveiller la mémoire, mais utilise plutôt un outils de monitoring comme jconsole...

Et ne surtout pas invoquer directement le GC ! A moins que tu ne veuilles plomber les performances de ton application...

[ipingu]

C'est le garbage collector qui s'occupe de libérer la mémoire. En mettant à null la reference vers ton objet, le GC saura que tu n'utilises plus cet objet. Ainsi, lorsque ta mémoire sera saturée, le garbage collector videra l'espace mémoire utilisé par cet objet, puisqu'il n'y aura plus aucune référence qui pointera vers l'objet.

Laisses le GC faire son travail en gros... s'il ne libère pas l'espace mémoire de l'objet, c'est que le programme n'a pas besoin de plus de mémoire. Lorsqu'il en aura par contre besoin, le GC videra l'espace mémoire.

Des posts interessants sur le GC ou l'analyse de l'empreinte mémoire des programmes :

http://blog.xebia.fr/2008/03/12/gc-g...ge-first-jdk7/
http://http://blog.xebia.fr/2008/11/...oire-dune-jvm/

[techz]

Salut,

S'il s'agit d'un bean en session il faut le supprimer de la session avec removeAttribute().
..

Ok , donc si je fait :

Code :

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

1
2
 
session.removeAttribut("monTableau");

Lorsque le gc aura besoin de libérer de la mémoire , il pourrat utiliser l'espace qui etait allouer a mon bean ?
Même si la session de mon utilisateur n'est pas terminée ?

[Rei Ichido]

Oui, à la condition que ton tableau ne soit référencé nulle part ailleurs. En particulier, pas via un autre objet mis en Session, dans un formulaire qui trainerait, etc. ^^

[techz]

Si je fais un :

Code :

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

session.removeAttribut("monTableau");

juste avant que l'utilisateur ne ferme se session , c'est bon non ?
Il n'y aura de toute facon plus aucunes references puisque le navigateur est fermé .

Certes , il y a aura d'autre monTableau qui existent , mais ils sont dans d'autres session pour d'autres utilisateurs , donc ca ne pose pas de problème ? ce n'est pas la même instance ...

[Rei Ichido]

Je dis juste que ton tableau peut avoir été utilisé dans d'autres classes, par exemple des classes globales, et de là on pourrait avoir une référence qui resterait vivante quelque part. Pour ça il faut connaître le code
Mais en assumant que nulle part ailleurs ce tableau n'est référencé, alors effectivement il devient éligible pour le gc, et donc tu n'as plus à t'en soucier.

[adiGuba]

Par curiosité : que contient "monTableau", et pourquoi as-il besoin d'être stocké en session ???

a++

[techz]

En fait mon Tableau contient le resultat de différentes requetes passées a une bdd.
J'ai besoin de les mettre en session pour qu'ils soient accessible tous le long de la session d'un utilisateur afin qu'il puisse faire des traitements dessus .
J'ai pensé a serializer sur le disque dur , mais le problème c'est que cela devient incomfortable pour l'utilisateur , car c'est trop long , le volume de données est tres important : plusieurs Giga par resultats.(Oui j'ai bcp de mémoire sur mon serveur ^^)

Sinon j'aurais une question pour les pros (surtout pour voir si j'ai bien compris) :
Le gc s'execute dans un thread de manière asynchrone , ce qui fait qu'on ne peut savoir a quel moment il va s'executer.
Sauf si on passe a la JVM le parametre -noasyncgc et que l'on appelle System.gc() dans le code .
Lorsque le GC fait son travail, il execute la methode finalize des objets non referencés (celle de la classe mère Object si notre propre classe ne possede pas de finalize) puis libère la mémoire alloué a cet objet .
Dans le cadre de J2EE et d'un serveur tomcat , lorsqu'un utilisateur appelle une page jsp , tout les objets de cette même page sont crées lors de la construction de la page html par le serveur puis une fois que la page html est envoyé au client , tous les objets de cette page jsp sont eligible au GC puisqu'ils ne sont plus reférencés ? c'est bien ca ?
Bien sur si cette page contient des javaBean qui ont une portée session ou application , je suppose que ceux-ci ne sont eligible et reste en mémoire entre les différente pages .

Merci d'avance de vos éclaircissements .

[Rei Ichido]

Le gc s'execute dans un thread de manière asynchrone , ce qui fait qu'on ne peut savoir a quel moment il va s'executer.
Sauf si on passe a la JVM le parametre -noasyncgc et que l'on appelle System.gc() dans le code .

Attention, quand tu fais -noasyncgc autant que je sache tu zappes simplement les appels automatiques faits par la JVM au gc. De toute façon, quand tu utilises System.gc(), tu ne fais que solliciter l'appel au gc, il n'y a pas de garantie que ça soit fait immédiatement.
Pour le reste, ok

[Baptiste Wicht]

Sauf si on passe a la JVM le parametre -noasyncgc et que l'on appelle System.gc() dans le code

Cette option est encore supportée mais est ignorée depuis Java 1.2. Si tu essaies, tu devrais avoir un warning disant que l'option n'est plus supportée. Elle est juste encore là pour des raisons de compatibilités, mais cela ne va rien changer.

[tchize_]

plusieurs gigas pour la session utilisateur?!? Je doute que, meme en une journée, un user puisse traiter et modifier un Giga de données, ce qui me laisse à penser que tu ferais mieux de revoir la manière dont tu gères tes objets en mémoire. Il y a visiblement beaucoup de déchets.

Quand au GC: laisse le faire son boulot. Les variables qui ne sont plsu référencées seront nettoyées à temps.

[adiGuba]

J'ai besoin de les mettre en session pour qu'ils soient accessible tous le long de la session d'un utilisateur afin qu'il puisse faire des traitements dessus .
J'ai pensé a serializer sur le disque dur , mais le problème c'est que cela devient incomfortable pour l'utilisateur , car c'est trop long , le volume de données est tres important : plusieurs Giga par resultats.(Oui j'ai bcp de mémoire sur mon serveur ^^)

Je serait curieux de savoir ce que tu manipules précisément, et pourquoi tu ne peux pas te contenter d'exécuter la bonne requête lorsqu'il le faut uniquement.

Lorsque le GC fait son travail, il execute la methode finalize des objets non referencés (celle de la classe mère Object si notre propre classe ne possede pas de finalize) puis libère la mémoire alloué a cet objet .

La méthode finalize() peut retarder la libération de l'objet, car si elle est redéfini cela force le GC à revérifié que l'objet ne soit pas "revenu à la vie"...

Dans le cadre de J2EE et d'un serveur tomcat , lorsqu'un utilisateur appelle une page jsp , tout les objets de cette même page sont crées lors de la construction de la page html par le serveur puis une fois que la page html est envoyé au client , tous les objets de cette page jsp sont eligible au GC puisqu'ils ne sont plus reférencés ? c'est bien ca ?
Bien sur si cette page contient des javaBean qui ont une portée session ou application , je suppose que ceux-ci ne sont eligible et reste en mémoire entre les différente pages .

C'est bien ca !
La durée de vie de la session dépend de la configuration du serveur, et de la dernière action de l'utilisateur (à moins de la détruire explicitement).
Le scope application reste quand à lui vivant pendant toutes l'exécution du serveur (il faut donc éviter d'y mettre n'importe quoi).

De toute façon, quand tu utilises System.gc(), tu ne fais que solliciter l'appel au gc, il n'y a pas de garantie que ça soit fait immédiatement.

Et dans le meilleur des cas le GC ignorera complètement l'appel (d'ailleurs on peut forcer cela avec l'option -XX:+DisableExplicitGC).
L'appel explicite au GC n'est généralement pas une bonne solution, car cela génèrera un full-GC c'est à dire une vérification de tous les objets, ce qui peut être assez couteux en temps...

Il est préférable de laisser le GC se débrouiller seul ! De toute manière si la mémoire vient vraiment à manquer il fera la full-GC de lui même...

a++