PB Memoire - Coup de Gueule

Bonjour a tous,
je tenais a faire part d'un petit mécontentement sur les "memory leak",
Non pas au fonctionnement de Java mais surtout au méthodes d'apprentissage de JAVA.
En effet, je viens de me rendre compte tout récemment, après développement d'une appli graphique basée sur OpemMap, que j'ai énormément de "memory leak".
Mon coup de gueule, c'est juste le fait que je "croyais" que le GC détruisais tout après fermeture de frame par exemple.
Hors apreè multiples recherches, utilisations de profiler (TPTP), je suis dans l'incapacité de déréférencer totalement les fenêtres filles, et donc elle ne sont jamais totalement détruites en mémoire.
J'arrive tout de même a libérer quelques ressources, après avoir repris tout le code, changé toutes les méthodes de traitement sur des listes, des vecteurs, ( il y avais des références vraiment PARTOUT ), et du coup des OutOfMemory a tous vas quand on es un peu gourmand avec l'appli ..

N'y a-t'il pas moyen de déréférencer totalement une frame ??
Un objet ca j'y arrive, mais la JFrame a tout un tas de références sur les RootPanes, listeners etc, et je n'arrive pas a la vider totalement de la mémoire ..

Je remercirai donc toutes reponses aux personnes qui rebondirait a mon post.

Salut,

Effectivement c'est un problème, on ne parle pas assez de la libération mémoire et je l'ai également appris à mes dépends.
Ce qui m'a permis d'en tirer plusieurs règles :

- éviter les variables statiques d'objets
- limiter l'utilisation des listeners
- "cleaner" ses objets quand ils offrent une méthode le permettant (JDateChooser#cleanup(), Model#release(), etc.); supprimer les listeners lors d'une fermeture lorsque ceux-ci peuvent empêcher la bonne libération des ressources
- utiliser des WeakReference<T> quand celà peut être une bonne idée ou quand ça s'avère nécessaire
- catcher les RuntimeException

Pas facile de détecter les problèmes quand il y en a un. En général je procède par élimination en réduisant l'écran au minimum puis en rajoutant/testant chaque élément afin d'identifier celui qui pose problème.

L'autre solution c'est de ne jamais "fermer" ses écrans mais de les réutiliser autant que possible (ce que nous ne faisons pas, ou peut-être dans maxi 5% des cas car nous avons besoin de libérer la mémoire des écrans non utilisés).

Bon courage

Merci natha pour ta réponse
Oui je me suis pas mal penché sur le problème du coup , et j'ai fait un pe plus de recherches.
Merci pour tes conseils c'est déja ce que j'essaye de faire .. mais reprendre un projet qui es déja passé dans plusieurs mains, contenant 200 classes environ .. c'est pas facile d'optimiser l'utilisation mémoire ..
Ce que je n'arrive pas à comprendre, après utilisation du profiler d'eclipse, quand j'ouvre une JFrame à partir d'une première JFrame, la seconde n'est jamais détruite .. il reste toujours une référence dessus ..
j'ai beau faire des dispose, finalize, la mettre a null dans le parent .. elle n'est apparement pas détruite par le gc .. Bon pour une simple Frame qui fait qq octets ce n'est pas méchant, mais sur mon projets elle accumulent trop de données ..
Pour le problème que je viens d'évoquer aurai-tu un autre conseil a me donner ?
Merci de ta reponse en tout cas, bonne soirée

Il y a 9 ans quand j'etais a la fac et que nous somme passe lors de la derniee annee du C/C++ au Java c'est clairement devenu d'un coup "casse pas la tete, laisse le GC bosser pour toi" (et je parle bien des profs, pas uniquement des etudiants). Hors une fois sorti du carquant de la fac, il est apparu clairement que les OutOufMemoryException se multiplient a vitesse grand V et qu'il a donc fallu apprendre un peu sur le tas comment limiter tout ca. Et ce n'est pas non-plus du cote des didacticiels et documentations officielles qu'on va forcement trouver des infos ou des indications de bonne pratique. De meme, aucun des livres "serieux" que j'ai ne s'attardent sur le sujet.

Citation:

---

Envoyé par couffi

Pour le problème que je viens d'évoquer aurai-tu un autre conseil a me donner ?

---

Elle est sûrement liée à cause d'un listener que tu mettrais sur un objet de la frame parente. Pour que cette 2nde JFrame se libère correctement, elle ne doit pas avoir de lien fort avec un quelconque élément de la frame parente.
Procède par élimination comme je l'ai suggéré dans mon premier post. Rajoute les portions de code au fur et à mesure tant que la frame se libère bien.

Merci natha je vais essayer ca, j'ai pourtant chercher un peut partout, sur des tutos, sur des exemples .. et je ne vois pas ce qu'il vas pas ..
Le seul listener que j'ai sur la Frame c'est celui qui capture la fermeture de la fenetre, qui es censé la disposer et la finalizer .. Je la met a null dans la frame parent, elle n'as plus de références sur la Frame parente, mais dans le profiler j'ai toujours la "live instance" sur la frame enfant ..
Bon sur mon projet j'ai des références un peut partout, donc je comprend qu'elle reste référencée qqpart .. mais pour une Frame vide .. la je comprend plus rien lol ..

Enfin bon quelque part ces petit soucis ont bien mis en évidence le manque d'information sur la libération des objet a réaliser soit même si on veut que tout soit disopsé correctement.. J'ai évoqué le problème autour de moi avec mes collègues avant de poser la question ici, et eux non plus n'avais pas connaissances de tel soucis .. Disons qu'on a tous été un peut naif sur l'utilisation du GC ^_^
Bonne journée

Citation:

---

Envoyé par bouye

(et je parle bien des profs, pas uniquement des etudiants).

---

Ben oui voila j'ai exactement le même soucis en ce moment, et j'ai l'impression de tout réapprendre depuis que je fais des recherches sur le sujet ^_^
Disons que les methodes d'apprentissages ne sont pas assez poussée sur le fonctionnement de la JVM je pense, sinon il aurait été plus clair que la gestion des références faisais tout de même parti du lot !!!

Voila un exemple tout bete, mais dont j'aimerai avoir votre avis.
Voila donc l'ouverture d'une Frame a partir d'une premiere, je n'ai pas mis de listener sur la 2nd Frame, et pourtant elle ne veux absolument pas se supprimer ...

3 classes :

1ere classe :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

package monPak;   public class Main {   public static void main( String[] args ) { PremFrame maframe = new PremFrame(); maframe.setVisible(true); } }

---

2eme classe

Code:

---

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 28 29 30 31 32

package monPak;   import java.awt.event.ActionEvent; import java.awt.event.ActionListener; import javax.swing.JButton; import javax.swing.JFrame;   public class PremFrame extends JFrame {   private static SecFrame secFrame; PremFrame parent = null; public PremFrame(){ setTitle("PremFrame"); setSize(200,200); setVisible(true); JButton bout = new JButton(); bout.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e) { secFrame = new SecFrame(parent); } }); this.getContentPane().add(bout); setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); parent = this; }   public void fermerSecFrame(){ secFrame = null;   } }

---

3eme Classe

Code:

---

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 28 29 30 31 32 33

package monPak;   import javax.swing.JFrame;   public class SecFrame extends JFrame { PremFrame parent = null;   public SecFrame(PremFrame parent) { this.parent = parent; super.setTitle("2ndFrame"); super.setSize(200,200); super.setVisible(true); this.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE); }   public void dispose() { parent.fermerSecFrame(); parent=null; System.out.println("2ndFrame se dispose"); super.dispose(); }     public void finalize(){ System.out.println("2ndFrame se finalize"); try { super.finalize(); } catch (Throwable e) { e.printStackTrace(); } } }

---

Le profiler me donne comme resultat apres avoir fermé la seconde frame :

Memory Statistics - monPak.Main at Div-proj-b2-3-1 [ PID: 2972 ]
>Package Total Instances Live Instances Collected Total Size (bytes) Active Size (bytes)
[-] monPak 3 3 0 688 688
PremFrame 1 1 0 336 336
PremFrame$1 1 1 0 16 16
SecFrame 1 1 0 336 336


On voit qu'il y a toujours une live instance sur la secFrame, et sur l'Object References Table :SecFrame Is referenced by 75 object !!!!!!!!!!!!!!!!


Object References Table - monPak.Main at Div-proj-b2-3-1 [ PID: 2972 ] (Filter: New_filter ) >Show Reference By Package Size (bytes) Number of References Details
[-] PremFrame monPak 336
[+] PremFrame monPak 336 Is referenced by 60 object(s).
[+] PremFrame$1 monPak 16
[-] SecFrame monPak 336
[-] SecFrame monPak 336 Is referenced by 75 object(s).
DefaultKeyboardFocusManager$DefaultKeyboardFocusManagerSentEvent monPak 200 Has 5 references to SecFrame.
DefaultKeyboardFocusManager$TypeAheadMarker monPak 48 Has 2 references to SecFrame.
Finalizer monPak 32 Has 1 references to SecFrame.
FocusEvent monPak 384 Has 12 references to SecFrame.
[+] InputMethodContext monPak 64 Is referenced by 2 object(s). Has 1 references to SecFrame.
[+] JRootPane monPak 376 Is referenced by 2 object(s). Has 1 references to SecFrame.
KeyboardFocusManager monPak 0 Has 1 references to SecFrame.
KeyboardFocusManager$HeavyweightFocusRequest monPak 32 Has 2 references to SecFrame.
KeyboardFocusManager$LightweightFocusRequest monPak 32 Has 2 references to SecFrame.
[+] LightweightDispatcher monPak 40 Is referenced by 2 object(s). Has 1 references to SecFrame.
MouseEvent monPak 840 Has 15 references to SecFrame.
PaintEvent monPak 64 Has 2 references to SecFrame.
PropertyChangeEvent monPak 32 Has 1 references to SecFrame.
SequencedEvent monPak 320 Has 8 references to SecFrame.
WeakHashMap$Entry monPak 40 Has 1 references to SecFrame.
[-] WeakReference monPak 120 Is referenced by 2 object(s). Has 5 references to SecFrame.
[+] PremFrame java.lang.ref 336 Is referenced by 60 object(s). Has 1 references to WeakReference.
[+] SecFrame java.lang.ref 336 Is referenced by 75 object(s). Has 1 references to WeakReference.
[+] WFramePeer monPak 96 Is referenced by 2 object(s). Has 1 references to SecFrame.
WindowEvent monPak 480 Has 12 references to SecFrame.
WInputMethod monPak 80 Has 2 references to SecFrame.

Merci d'utiliser les balises [ CODE ] pour mettre en forme le code !
(lire les règles du forum tant qu'à faire ;)).

Je pense que la solution c'est de virer ta méthode fermerSecFrame() et de faire plutôt :

Code:

---

1 2 3 4 5 6 7 8 9 10

bout.addActionListener(new ActionListener(){ public void actionPerformed(ActionEvent e) { secFrame = new SecFrame(parent); secFrame.addWindowListener(new WindowAdapter() { public void windowClosed(WindowEvent e) { secFrame = null; } }); } });

---

Ah ok merci pour l'info des balises je ne savais pas comment on faisais justement ..
Je te remercie pour l'info sur le code, je me casse vraiment la tête avec ca en ce moment .. et dire que ca fait plus de 3 ans que je fais du dev Java et ce n'est que maintenant que je me rend compte de toutes ces subtilités ..
Vive les Profiler lol
Bonne apres midi
Cdlt

Bon ben je ne comprend pas pourquoi, j'ai eu beau tout essayer pour déréférencer totalement la seconde JFrame .. mais rien a faire il y a toujours une live instance sur cet objet ..
Donc soit c'est mon profiler qui ne fonctionne pas correctement ..
Soit c'est la JVM qui ne la dispose pas complètement car elle n'as pas un réel besoin de libérer la mémoire ..
J'ai pourtant chercher partout, je n'arrive pas à trouver d'infos sur le sujet.
La je suis dans le flou total .. Si je n'arrives pas à disposer complètement une Frame vide .. alors mon projet avec OpenMap c'est même pas la peine ..
Je veux bien prendre toutes infos à ce sujet la si vous avez quelque chose.
cdlt bonne journée

Ce n'est pas parce que tu fermes la fenêtre qu'il va forcément la libérer tout de suite. Ca peut prendre du temps et il faut qu'il ait besoin de la mémoire utilisée par cette fenêtre.

Essaie de faire un bouton qui déclenche une boucle qui fait 10x System.gc() de suite. Clique sur ce bouton après avoir fermé ta seconde frame.
Tu peux également lancer ton programme avec ces paramètres :

Code:

---

-XX:MinHeapFreeRatio=10 -XX:MaxHeapFreeRatio=25 -Xmx32m

---

Citation:

---

Envoyé par natha

Ce n'est pas parce que tu fermes la fenêtre qu'il va forcément la libérer tout de suite. Ca peut prendre du temps et il faut qu'il ait besoin de la mémoire utilisée par cette fenêtre.

---

Salut
Ben oui en effet c'est ce que j'en ai deduis. J'ai arreté de chercher a liberer absolument mes frames, mais par contre je me suis attelé desuite a la destructions de références dans des hashtables un peu gourmande, et la je gagne quand meme 20 a 30 MO de libération ^_^
Donc pour le delestage total des classes JFrames meme.. Bah meme si elle ne sont jamais totalement detruites, ce ne sera pas trop grave a mon gout.
Bonne soirée

Citation:

---

Envoyé par couffi

Salut
Ben oui en effet c'est ce que j'en ai deduis. J'ai arreté de chercher a liberer absolument mes frames, mais par contre je me suis attelé desuite a la destructions de références dans des hashtables un peu gourmande, et la je gagne quand meme 20 a 30 MO de libération ^_^
Donc pour le delestage total des classes JFrames meme.. Bah meme si elle ne sont jamais totalement detruites, ce ne sera pas trop grave a mon gout.
Bonne soirée

---

20 à 30 Mo, c'est énorme ! tu mets quoi dans tes hashTable
Une JFrame même avec beaucoup de composants ne prends pas autant de mémoire

Citation:

---

Envoyé par bassim

20 à 30 Mo, c'est énorme ! tu mets quoi dans tes hashTable
Une JFrame même avec beaucoup de composants ne prends pas autant de mémoire

---

Je plussoie sur cette remarque. C'est énorme !

Ben deja la plus grosse contiens environs 12000 enregistrements, lié ensuite à des objets graphiques , liés a openMap ..
Les autres sont beaucoup moins importantes, mais il y en as pas mal.
Donc avec le profiler, j'ai bien réussi a ce que tout les objets passent par le GC, la mémoire est bien libérée de ce coté là, apres le reste des composants Graphiques qui ne se libèrent pas ca reste correct, enfin tant qu'on ouvre pas 10 ou 15 fois ces fenetres d'affilé.
Mais je suis sur le coup, je vais m'occuper de tout ces objets quite a repasser les 200 classes :-p lol
Bonne soirée

Citation:

---

Envoyé par natha

Je plussoie sur cette remarque. C'est énorme !

---

Il faut dire qu'entre ma première phrase et la deuxième y avait aucun lien :oops:

:king:

Bonjour,
je découvre moi aussi que les fuites mémoires existent aussi sous JAVA.. (en C++ on pouvait oublier de supprimer ces objets, mais au moins lorsqu'on les supprimaient, c'était clair.)

J'ai donc un gros souci de fuite mémoire sur une petite appli, la fenêtre qui pose problème est chargée d'afficher une liste active de JPanel (c'est à dire que comme j'ai besoin que chaque élément contiennent des contrôles sélectionnables/editables, je n'ai pas pu passer par une JList, et j'ai juste un JPanel qui contient pleins de JPanel (~ 500 au max pour l'instant).

Autant dire que lorsque j'affiche mes éléments, j'instancie de nombreuse fois la classe chargée de l'affichage d'un élément.
Et j'ai constaté que lorsque je ferme et réouvre ma fenêtre, et lorsque je vide et recharge ma liste, l'utilisation mémoire ne fait qu'augmenter.

J'ai cherché à utiliser un profiler, et le plus indiqué semble être TPTP (bonjour la galère pour installer les libs natives sous linux.. mais j'ai fini par y arriver..).
Je lance donc un profile sur la mémoire, et je vois bien que le nombre d'instance ne diminue pas lorsque je ferme/rouvre ma fenêtre ou vide/recharge ma liste.

Ayant repéré la classe la plus gourmande en mémoire (et donc le nombre d'instances est suppérieur au total attendu), j'aurais aimé pouvoir lister les instances, et mieux encore, les objects qui pointent sur ces instances.
Car c'est bien aux objets qui réfèrent (à tort) ces instances que je doit m'attaquer pour corriger mon bug, n'est-ce pas ?

Seulement voilà.. Malgré la jolie doc de TPTP qui n'est pas à jour puisqu'elle montre des procédures et screenshots d'une ancienne version (qui ne semble plus compatible avec la 1.6); Je ne suis pas parvenu à tracer de liste des références sur mes objets.
Sur l'écran "Object References" de TPTP, les colones "Number of References" et "Détails" restent vides.
J'ai cherché d'autres profiler mais je n'ai réussi à en faire fonctionner aucun qui propose cette fonctionnalité, pourtant il semble (à en croire la doc) que les versions plus anciennes de TPTP le proposait, ainsi que d'autres outils (qui ne fonctionnent plus depuis la 1.6 et la nouvelle "JVMTI").

Je me pose plusieurs questions:
Quelqu'un arrive t'il à résoudre ces soucis de fuites mémoire efficacement en java 1.6, et avec quels outils ? quelles méthodes de recherche ?

Il est dit que dès lors qu'une référence existe sur un objet, celui-ci n'est pas collectable par le GC. Et ce y compris si 2 objets se référencent entre eux, mais ne sont eux-même référencé par aucuns autres.
Qu'en est t'il des variables "final" ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

void maMethodeDeMaClasseA() { final Object monObjFinal = new Object(); this.monAttributDeMaClasseAQuiAdmetUnListenerXXX.addXXXListener(new XXXListener() { void onCeciCela(Event e) { // Que se passe t'il si j'utilise une reference final dans mon inner class ? System.out.println("Obj: "+monObjFinal.toString());   // Que se passe t'il si j'utilise un attribut de l'instance contenante dans mon inner class !? System.out.println("monAttributDeMaClasseA: "+monAttributDeMaClasseA.toString());   // Que se passe t'il si j'utilise une méthode de mon instance contenante dans mon inner class !!? maMethodeDeMaClasseA(); } }); }

---

Dans cet exemple, on ne créé pas directement une référence sur ma classe A dans la classe XXXListener anonyme, mais on y utilise quand même monAttributDeMaClasseA.. Celà suffit t'il à provoquer une situation ou les deux objets (instance de MaClasseA et instance de mon XXXListener anonyme) seront incollectables ? Et avec monObjFinal ?

J'ai lu qqpart que l'implémentation du GarbageCollector était de toute manière laissé libre, il existe donc différents algo de GarbageCollector suivant la JVM utilisée.. on est pas rendu.. :arf:

je précise, accessoirement, il existe des profiler graphique plus pratique pour localiser les memoryleak. Là, t'as juste les références, faut encore chercher où ces références sont stockées, qui les références, etc. Donc çà fait vite un long chemin. Certains profilers avancés, remontent automatiquement le chemin vers un dénominateur commun et c'est souvent là que çà fait tilt :)

Dans ton code, je vois pas de leak. C'est pas parce que le gc n'a pas nettoyé la mémoire qu'elle n'est pas nettoyable (d'ailleurs un bon profiler devrais la libérer obligatoirement avant de faire son rapport)

Perso j'utilise jprofiler (payant mais pas trop cher), il m'a déjà rendu de bon service sur des webapps dans un conteneur tomcat :)

Citation:

---

Envoyé par AxanOrg

Il est dit que dès lors qu'une référence existe sur un objet, celui-ci n'est pas collectable par le GC. Et ce y compris si 2 objets se référencent entre eux, mais ne sont eux-même référencé par aucuns autres.

---

C'est faut. Le garbage collector n'a aucun problème avec les références cyclique. Il faut qu'il existe un chemin de hard références depuis une zone non nettoyable (stack, classes, threads, frames visibles, sockets réseau actives, etc). deux objets qui se référencent mutuellement sans être référencé ailleurs seront nettoyés.

Citation:

---

Envoyé par AxanOrg

Qu'en est t'il des variables "final" ?

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

void maMethodeDeMaClasseA() { final Object monObjFinal = new Object(); this.monAttributDeMaClasseAQuiAdmetUnListenerXXX.addXXXListener(new XXXListener() { void onCeciCela(Event e) { // Que se passe t'il si j'utilise une reference final dans mon inner class ? System.out.println("Obj: "+monObjFinal.toString());   // Que se passe t'il si j'utilise un attribut de l'instance contenante dans mon inner class !? System.out.println("monAttributDeMaClasseA: "+monAttributDeMaClasseA.toString());   // Que se passe t'il si j'utilise une méthode de mon instance contenante dans mon inner class !!? maMethodeDeMaClasseA(); } }); }

---

---

En lui même le mot clé final n'a pas beaucoup d'influence. Ce qui en as, c'est ce que tu fait de la variable après. Dans ton cas, tu la référence depuis une inner class, celle-ci lors de sa construction recevra alors copie de la référence. Tant que l'instance de cette inner class ne sera pas collectable, à la fois l'instance de ta classe entourante ne le sera pas (l'inner class référence d'office l'instance de la outer class, sauf si elle est static), et l'instance de Object ne le sera pas.

Le listener sera garbage collectable lorsque monAttributDeMaClasseAQuiAdmetUnListenerXXX le sera. Celui là même, a priori, le sera quand MaClasseA le sera (sauf si tu référence aussi l'attribute ailleurs). Donc tout se résumera, a priori, au déréférencement de ton instance de MaClasseA

Bonjour, je suis confronté au même problème que vous, dans una application d'environ 50 classes, qui gère une BDD en client serveur.

Au début, j'était directment à plus de 60Mo de mémoire utilisée dès l'éxécution du programme.

En fait ca venait des images... j'en avait une 20aines, icones, fonds...

Et la je passe directement à 1Mo!!!!

Par contre, le problème que je n'ai pas encore résolu, c'est en rapport avec les communications BDD.

La au début c'était la cata, avec 5000 ou 1000 lignes d'une table à récupérer et un algorithme pas au point (ex : un Resultset déclaré sur une classe et pas dans la méthode), j'avais des fuites de mémoire de fou!!!!
Je montait en 10 secondes à 500Mo.

En optimisant, j'en suis à 50-100 Mo max (+ les images)

Mais je constate que petit à petit, centaine de kilo octet par centaine de kilo octets, la mémoire utilisée augmente, et je ne comprends pas pourquoi...

LE garbage collector n'y fait rien.

Mais je pense que la JVM est concue de tele facon que la mémoire n'es tpas vidée instantanément au cas ou on doivent se resservir des infos, même si la classe est "dispose" ou finalize. Moi en tous cas si je l'avais concu j'aurais fait comme ca, pour gagner du temps, ca permet de pas réecrire la ram tt le temps.

Mais bon, ca n'explique pas pourquoi la mémire, utilisée augmente petit à petit.

Est ce que ca peut venir d'un objet statique, duquel je me resservirai plusieurs fois, et donc que son allocation mémoire soit toujours de plus en plus grande?

Effectivement même si le GC collecte les objets, il ne rend pas forcément la mémoire à l'OS (donc on ne vois pas forcément la mémoire utilisée diminuer dans le gestionnaire des taches).

Les références static ne posent soucis que si l'objet qu'elle référence a une durée de vie plus courte que la référence elle même. Dans ce cas la référence empèche de collecter l'objet pourant devenu inutile.

Dans mon cas j'avais fait le tri parmis mes classes pour voir lesquelles utilisaient des listener, et j'ai remplacé les références sur les listener par des WeakReference. Je n'ai pas très bien compris comment utiliser les WeakReference, car dans mon cas elles se trouvaient aussitôt créé, aussitôt collectées.. mais en tout cas j'ai pu observer que mon soucis me fuite mémoire venait bien des classes en questions et du fait des références maintenues sur les listeners.

Si qq'un peut m'expliquer simplement comment devrait t'on utiliser les WeakReference dans ce cas:

j'ai l'habitude de souvent créer les listener en tant que classe anonyme en même temps que je les enregistre.

Code:

---

1 2	monObjetListenable.addXXXListener(new MonInterfaceListener() {/*implementation classe anonyme..*/});

---

Si bien que personne d'autre que monObjetListenable ne garde de référence sur mon listener (et effectivement, aucun autre objet n'en a besoin).
Cependant si je le référence avec une WeakReference, alors celle-ci est aussitôt collectée (normal) et je perd aussitôt mon listener..
Je ne saisie pas trop comment on est sensé utiliser les WeakReference dans ce cas là ?

normalement, si tu utilise des weakreferences comme listeners, t'es censé garder une référence après l'appel, pour éviter son gc. On utilise typiquement dans ce genre de situation:

Code:

---

1 2 3 4 5 6

public class MaClasse extends UnTruc implements UnListener{   //....   unObject.addXXXXListener(this); }

---

tant que l'instance de MaClasse sera utilisée, "unObjet" la notifiera de changements qui surviennent.

Citation:

---

Envoyé par natha

- éviter les variables statiques d'objets
...
- catcher les RuntimeException

---

Je ne suis pas d'accord avec ses deux la.
- L'utilisation des variables static fournit des objects qui vont etre réutilisé souvent, Il preferable d'avoir un object constant pour tout le monde que N instance d'objet. Bien sur il ne faut pas en abuser. mais ce n'est pas une mauvaise pratique en soi.

- Si on en vient a catcher les runtime exceptions c'est qu'il a de gros soucis avec le fonctionnement de l'application, ca ressemble plus a un patch de derniere minute qu'une vrai pratique. La question que je me pose aussi, c'est "Ou peux tu bien utiliser ce catch efficacement ?". Le faire au moment d'une methode qu'on sait volumineux en cout memoire ? c'est inutile, la methode pourrais tres bien marcher et faire un OutOfMemory si une toute petite methode qui suit.

Je rajoute quelques conseil :
- Utiliser des classes immutables. ces classes peuvent etre utilisé beaucoup plus souvent qu'on ne le pense et permet d'avoir des objets dont le comportement et parfaitement previsible et donc simplifi grandement les divers soucis qu'on peut se faire avec la gestion memoire.
- Essayer d'utiliser d'avantage les fabrique/service, ces objets sont generalement des singletons thread safe qui on un cout memoire permanent mais faible comparé a la creation de N instances.
- Eviter de creer des objets inutiles pour les methodes.
Par exemple vous avez une liste et vous voulez la remplir avec d'autres listes venant d'autres objects.
Plutot que d'avoir une methode :

Code:

---

List<Truc> getTrucs();

---

utilisez plutot une methode du genre :

Code:

---

void fillTrucs(List<Truc> malist);

---

L'objet voit qu'on lui fournit une liste a remplir, il n'aura pas besoin d'en créé une.
L'idéale est d'avoir ceci :

Code:

---

List<Truc> getTrucs(List<Truc> maList);

---

L'objet créera une list si on passe une liste null, sinon il remplira celle fournie.
Il y a plein de petite choses du genre qui permettent de grapiller pas mal d'espace memoire et enormement de performances.

Citation:

---

- L'utilisation des variables static fournit des objects qui vont etre réutilisé souvent

---

C'est justement parceque rien ne le garantie que je disais qu'elles sont à éviter.
Si l'on est sûr à 100% que l'objet référencé en static sera de longue durée de vie, pas de soucis, mais il faut éviter d'utiliser des variables static sans être sûr de la durée de vie des objets qu'elles référenceront.

Concernant l'utilisation de singlethon plutôt que l'instantiation de plusieurs objets, je ne vois pas où est le problème, ou du moins, c'est hors-sujet si l'on parle des FUITES mémoire.
Du moment que les objets sont de courte durée de vie, et qu'une fois inutilisés ils sont correctement collectés, celà ne pose pas de problème d'espace mémoire que d'en créer massivement (même si ça n'est peut être pas le plus optimisé, mais d'un point de vue 'FUITE MEMOIRE' ça ne pose aucun soucis).
La question est justement, comment s'assurer que nos objets soient correctement collectés, qu'elles sont les bonnes pratiques à avoir.
Je n'ai pas le sentiment d'avoir reçu de réponse satisfaisante (claire, exhaustive, fiable) pour l'instant.

Citation:

---

Envoyé par eclesia

- Eviter de creer des objets inutiles pour les methodes.
Par exemple vous avez une liste et vous voulez la remplir avec d'autres listes venant d'autres objects.
Plutot que d'avoir une methode :

Code:

---

List<Truc> getTrucs();

---

utilisez plutot une methode du genre :

Code:

---

void fillTrucs(List<Truc> malist);

---

L'objet voit qu'on lui fournit une liste a remplir, il n'aura pas besoin d'en créé une.
L'idéale est d'avoir ceci :

Code:

---

List<Truc> getTrucs(List<Truc> maList);

---

L'objet créera une list si on passe une liste null, sinon il remplira celle fournie.

---

Autant je suis d'accord sur éviter des créer de gros objets inutiles, autant je ne suis pas d'accord avec ton exemple :D. Il comporte à mon sens plusieurs problèmes:

1) Notation non 'javabean', ce qui implique que la méthode sera inutilisable dans des contexte type Expression Language (entre autres)
2) non intuitif (on a tendance à rechercher dans l'api un getter , pas un filler), mais çà c'est une question de convention sur le projet j'imagine aussi
3) aucun gain en instantiation. Ce que tu gagne en ne faisant pas un new ArrayList(taille), tu le perd sur le redimensionnement d'array que fait une arraylist lorsque sont tableau est plein.
4) Une ArrayList occupe peu de mémoire par rapport à la mémoire qu'occupe les objets qu'elle contient.

Citation:

---

Envoyé par tchize_

Autant je suis d'accord sur éviter des créer de gros objets inutiles, autant je ne suis pas d'accord avec ton exemple :D. Il comporte à mon sens plusieurs problèmes:

1) Notation non 'javabean', ce qui implique que la méthode sera inutilisable dans des contexte type Expression Language (entre autres)
2) non intuitif (on a tendance à rechercher dans l'api un getter , pas un filler), mais çà c'est une question de convention sur le projet j'imagine aussi
3) aucun gain en instantiation. Ce que tu gagne en ne faisant pas un new ArrayList(taille), tu le perd sur le redimensionnement d'array que fait une arraylist lorsque sont tableau est plein.
4) Une ArrayList occupe peu de mémoire par rapport à la mémoire qu'occupe les objets qu'elle contient.

---

1) Il n'y a aucune obligation d'etre 100% javaBean... si un get/set ne se prete pas a le methode que l'on veut avoir, alors je ne vais pas me forcer a en mettre un get.
2) la javadoc est la pour ca.
3) Si son tableau n'est pas plein ou si des valeurs sont deja presente on y gagne.
4) peut etre peu de memoire, mais un peu de memoire quand meme.

C'est vrai que le "fillTruc" on le voit jamais (c'etait juste a titre d'exemple).
On peut trouver beaucoup d'exemple dans les classes Java2D et autre relative au math.
Exemple : AffineTransform
Methode :

Code:

---

1 2 3

public Point2D inverseTransform(Point2D ptSrc, Point2D ptDst) Inverse transforms the specified ptSrc and stores the result in ptDst.

---

Ce que je voulais dire dans tout ca, c'est qu'il y beaucoup de facon de reduire le nombres de references qui se baladent. Moins de references c'est moins de boulot pour le GC, moins de risques de fuite memoire et tres souvent un gain en performance.