Discussion :

[Piolet]

Re hello,
comment faire ( a part un bon code ) pour optimiser un peu la gestion de la mémoire avec java, est-ce que reimplémenter finalize() peut etre une solution ou bien alors faut il préciser aux utilisateur les adresses des boutiques a montgallet qui vendent de la bonne RAM pour pas chère?

voila merci

ps : Pour info j'ai un peu regarder l'evolution de mon appli avec JProfiler, meme si je ne comprends pas grand chose a son fonctionnement, mais les chiffres liés au instanciation ne cesse d'augmenter...c ptet normal, mais qd je ne fais rien avec mon appli j'aurais aimé que les chiffres stagnent...maintenant c ptet normal, je pose aussi la question au cas ou ?

[Ioan]

Bonjour,
Voici mon avis.
Tu ne peux rien y faire.
La gestion de la mémoire en java est en général complétement inaccessible. Tout est géré par le gc et companie(implémentation native de la jvm, tout en C si ma mémoire est bonne).
1 - ) Pourquoi vouloir optimiser cela? Tes accès mémoire sont si essentiels au fonctionnement de l'appli?
2 - ) Si tu avais la possibilité de faire cela, crois tu pouvoir le faire mieux qu'un programme spécialisé?
C'est un des points forts de java. Tu n'as pas à gerer la mémoire, tu n'as plus de pb de leak, etc ... Pour des langages comme C/C++ tu peux gérer tout cela, mais est-ce vraiment nécessaire? Pour le rapport "qualité/prix" (avantages/problèmes si je peux me permettre), est-ce que ca vaux le coup?
Désolé, ca fais pas vraiment avancer le schmilblick
Si un spécialiste e la gestion mémoire à mieux à proposer, je suis preneur
@+

[Fladnag]

si tu veux limiter la memoire utilisée par tes objets, il faut que tu les remettent a null dès que tu ne les utilise plus. Comme ca le garbage collector peux faire son travail plus simplement.

[Piolet]

vedear...
bah
1-) parce que sinon l'appli plante... et c pas top top de dire bah c parce que c votre pc qué de lamerde...c pas mon appli
2-)ouui j'ay arriverais je suis trop fort, non effectivement je n'y arriverais ptet pas mais...je me disais que si y avait une méthode pour bien faire un appel du GC au bon moment ou qq petit tips ca aurait pu m'aider
merci qd meme pour ton aide (comme d'hab )

Fladnag
j'ai déja fais qq rajout comme ca dans mon code...mais perso je ne vois pas, enfin si je vois ou je pourrais rajouter tout c null....mais y a tellement de ligne de code que je suis démoraliser rien k l'idée de tout relire...et en plus rien ne garantit le bon fonctionnement une fois que ca ca sera fait...
enfin je peux tjs essayer merci a toi

[Debernad]

c votre pc qué de lamerde...c pas mon appli

Loin de moi de jouer les troubles fêtes mais si tu ne fait rien et que la jvm continue à instancier des Objets Java c'est qu'il y a peut être un probléme dans ton application ...
Car jusqu' à preuve du contraire, la Jvm ne crée pas des Objets Java au hasard, rien que pour se faire plaisir ... la jvm n'est pas un être vivant doté d'une intelligence, elle ne fait que ce que l'application lui demandes ...

Donc il serait intéressant d'utiliser ton profiler pour déterminer quelques sont les classes instanciées pour comprendre pourquoi et surtout savoir quel traitement est effectué en tache de fond lorsque tu ne fais rien ...
Enfin si ta mémoire ne cesse d'augmenter, cela peut signifier que tu ne relache pas les Objets Java que tu crée et donc que tu conserves des références à ces Objets ... tant que ces références existent le ramasse-miette est dans l'impossibilité de détruire ces Objets Java

En espérant avoir pu t'aider ...

[cdrikou]

la Jvm ne crée pas des Objets Java au hasard, rien que pour se faire plaisir ... la jvm n'est pas un être vivant doté d'une intelligence ...

D'autant plus que si tu touche pas à ton apli et que la prise de mémoire continue d'augmenter en effet, il y a ptete un problème, tu dois générer des objet quelque part en continu...
Meme si le pc est bon, si ca se passe comme ça, tout pc a une limite de mémoire quoiqu'il arrive, donc si ca augmente en permanence au bout d'un moment c normal que ça plante...
Bon courage!

[Piolet]

merci de ces conseils, et effectivement je pense que le pb doit venir d'un bout de code...
car visiblement ce sont des String et Hashtable qui se génère, mais franchement je ne comprends pas pkoi...car au début mon apli ne fais rien d'autre que d'ouvrir une frame...
mais au nivo du de la mémoire elle reste a peu pres stable qd je regarde les perds du gestionnaire de tache de windows...sauf que d ke je fais qq chose elle augmente et elle ne doit pas etre libérée asser svt, je v donc tenter de mettre des = null un peu partout

[tileffeleauzed]

Mettre des nulls un peu partout, cela ne sert plus à rien aujourd'hui, et même cela pénalise le ramasse-miettes. Il vaut mieux éviter de la faire, sauf si l'on veut explicitement libérer de la mémoire. Mais si c'est juste pour aider le ramasse miette, c'est nuisible.

Voir sur ce sujet Java theory and practice: Garbage collection and performance.

La seule méthode valable est d'examiner son code pour découvrir où ça bogue. Et, éventuellement, le paquage java.lang.ref lorsque l'on veut finasser. Mais sur ton cas, tant que tu n'as pas trouvé l'explication, cela ne sert à rien.

[Piolet]

l'explication est trouvée, en fait g plusieurs panels dans mon appli et le panel principale est la visualisation d'un emploi du temps avec qq icone qui clignote...ca clignote grace a un Timer, et chaque appel de ce timer ca appelle repaint() et donc ca refait certains calcul qui necessitent la creation de String...d'ou...le fait que des variables soit créer...par contre si je change de panel mon profiler me dit bien que plus ne se passe...donc c plutot positif, par contre la ou je suis décu c que g passer ma journée a mettre des null un peu partout...sur une centaines de classes
et si tu me dis que ca sert a rien je suis un déçu voir meme bcp...
pourtant si je regarde mon gestionnaire de tache avec l'ancien jar de mon appli, j'arrive a la faire monter jusK 50 M de mémoire utilisé, alors qu'avec le jar avec plein de null un peu partout, il lutte pour dépasser les 45M, est-ce le fruit du hasard ou bien ca montre que les null peuvent encore servir malgré l'article que tu as mis???

[narmataru]

Tu peux peut être augmenter la taille de mémoire allouée à la JVM au démarrage en lçant ton application de cette manière :

java -jar -Xms50 -Xmx512 tonAppli.jar

ou -Xms est la taille minimum (de départ) allouée et -Xmx la taille maximum. Si ton appli plante chez ton client sur un truc genre 'out of memory' ça peut résoudre ton problème,
bonne soirée

[tileffeleauzed]

Quels objets mettais-tu à null ? Est ce des variables globales par rapport à une classe ou locales par rapport à une méthode ?

Si ce sont des variables locales, je ne comprends pas : cela ne sert strictement à rien. Si ce sont des variables globales, cela peut te faire gagner de la mémoire, effectivement. Je n'avais pas pensé à ce cas, parce que il est rare que l'on mette des variables globales à null, parce qu'à ce moment là on ne peut plus y accéder depuis l'instance, donc il y a peu de raisons qu'elles soient globales, donc il vaut mieux qu'elles ne le soient pas.

Néanmoins des fois on y est obligé, et alors c'est une bonne chose que de les mettre à null. (je ne sais pas si je suis clair )

[Piolet]

non je mettais des variables locales a des methodes...donc je ne comprends pas non plus pkoi ca a changer qq chose...

pour le coup de la mémoire alloué a la JVM c pas trop la meme chose, car ske tu propose ca peut aider justement si l'erreur est out of memory et dans ce cas la heap de java a plus de place, mais mon erreur provient de la JVM.dll qui visiblement bouffe a un certains moment toute la mémoire RAM, sur un pc a 64 Mo RAM j'ai réussi a faire planté et le fichier de log lié a ce plantage me disait qu'o moment du crach il n'y avait plus que 20Ko de memoire libre sur 64 Mo c chaud qd meme, alors ca confirme qd meme que JAVA a besoin de bcp de mémoire

[Piolet]

je remarque ce matin en fait que les changements des null, n'ont effectivement rien apporté, les tests hiers ont du etre fait dans des conditions qui devaitlaisser disponibles plus de mémoire dans un cas et pas dans l'autre... car la ce matin les 2 (avec et sans null) arrivent a dépasser ( de tres peu) les 60M de Mémoire utilisée