Discussion :

[couffi]

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.

[natha]

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

[couffi]

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

[bouye]

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.

[natha]

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.

[couffi]

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

[couffi]

(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 !!!

[couffi]

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 :

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

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 :

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
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 :

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
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.

[natha]

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 :

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

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;
			}
		});
	}
});

[couffi]

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

[couffi]

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

[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.

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 :

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

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

[couffi]

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

[bassim]

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

[natha]

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 !

[couffi]

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

[bassim]

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

[couffi]

[AxanOrg]

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 :

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
 
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..

[tchize_]

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