Discussion :

[viscere]

Bonjour,


J'ai une appli qui charge de gros fichiers. J'ai des problèmes de ram à tel point que quand je charge plusieurs de ces gros fichier je me prend une OutOfMemoryError. Pour remédier à ca temporairement, j'ai alloué plus d'espace Ram à l'appli mais bon c pas super... Faut que je revois mon code aussi pour le simplifier. Néanmoins lorsque je charge un fichier et que j'observe la rame utilisée par mon logiciel je constate que la rame augmente mais quans je ferme ce fichier la rame ne diminue pas. Pourtant j'ai bien viré mes fichiers de mes Vecteurs et je mets bien mes objets à null. Y a t il un probleme de garbage collector ou dois je utiliser une fonction qui me perméttrait de libérer la mémoire??

Merci,

Laurent

[adiGuba]

Salut,



As-tu bien fermé tes fichiers avec close() ? Tu as bien 'effacé' toutes les références vers les objets contenant les données des fichiers lus ?

Rien ne garantit que la mémoire sera rendu au système immédiatement. Au contraire le Garbage Collector peut la conserver pour des raisons d'optimisation...

a++

[viscere]

ben j'utilise pour ouvrir mes fichiers :

fichierCourant = new File(filename);

et y a pas de fonction close... donc je met a null.

[adiGuba]

Heu...

La classe File est seulement une représentation d'un fichier, mais ne permet en aucun cas de lire son contenu !!!

Donc soit tu en crée un très grand nombre, soit il y a autre chose qui pose problème...

a++

[KiLVaiDeN]

Pour lire tes fichiers, je te conseille de ne pas les charger totalement en RAM. Tu dois plutot utiliser des flux de lectures bufferisés, qui te permettent de lire ton fichier petit à petit.

Si tu connais la taille "d'un enregistrement", en mémoire tu n'auras donc que cette taille, à quelques chouillas près.

adiGuba parle évidemment des closes sur tes flux : n'oublies-pas que pour cela, tu peux utiliser la clause "finally" du bloc try and catch, qui est toujours executée, quelque soit le résultat dans le bloc try : c'est là qu'il faut placer les closes, dans l'ordre inverse de l'ouverture de tes flux.

A+

[viscere]

ah oui pardon...

Voici ma fonction qui lit le fichier File (fichierCourant)

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
 
public void LireFichier(JTextArea champTexte) throws IOException
    {
 
		champTexte.setText("");
		fichierContenu="";
		BufferedReader raf = null;
		String ligne=null;
 
    try
      {
    	raf = new BufferedReader(new FileReader(fichierCourant.getPath()));
 
 
      while ( (ligne = raf.readLine()) != null )
        {
        fichierContenu = ligne+"\n";
        champTexte.append(fichierContenu);
        }
 
      }
 
   catch (IOException e)
     {
 
     System.out.println("erreur dans: " + e);
     }
   finally {
	   raf.close();
   }
 
    }

j'ai mis close mais la ram ne se libere toujours pas.

[adiGuba]

j'ai mis close mais la ram ne se libere toujours pas.

C'est normal que la RAM ne se libère pas : tu as tout chargé dans ton champ texte !!!!

Il faut le vider ou le détruire pour libérer la mémoire...

a++

[KiLVaiDeN]

Déclare un objet FileReader aussi, au lieu de faire un new FileReader, je pense que ça peut aider le garbage collector.

Code :

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

1
2
3
4
5
6
7
8
BufferedReader raf = null;
FileReader fr = null;
		String ligne=null;
 
    try
      {
        fr = new FileReader(fichierCourant.getPath());
    	raf = new BufferedReader();

et dans le finally, tu close d'abord raf, puis rf.

[adiGuba]

Déclare un objet FileReader aussi, au lieu de faire un new FileReader, je pense que ça peut aider le garbage collector.

Non ce n'est pas utile...

De plus le close() du Buffered appellera celui du FileReader...

a++

[viscere]

adiguba quand je ferme un fichier je supprime son ChampTexte associé donc la ram devrait se libérer.

Chui un peu perdu la je sais pas trop quoi faire..

[adiGuba]

adiguba quand je ferme un fichier je supprime son ChampTexte associé donc la ram devrait se libérer.

Comment tu le supprimes ? Tu l'enlève bien de son composant parent ?

Comment tu vérifies la RAM utilisé ? avec la classe Runtime ou un outils système ?
Parce que le GC n'est pas obligé de libérer la mémoire de suite... Par contre il devrait le faire avant de générer une OutOfMemory...

Chui un peu perdu la je sais pas trop quoi faire..

Ben on ne peut pas vraiment t'aider... Tu dois utiliser un profiler pour retrouver l'origine de la consommation de mémoire...

a++

[Gfx]

Je te conseille le Profiler de NetBeans 5.0 qui est gratuit sur netbeans.org. Je l'utilise tout le temps pour ce genre de situation. Lorsque tu supprimes le champ texte, fait un setText("") avant, pour etre sur de degager la String qui doit prendre un maximum de memoire.

[viscere]

En gros mon application peut charger plusieurs fichiers en même temps sous la forme d'onglets. Quand j'ouvre un fichier j'ajoute dans un vecteur ce fichier, dans un autre vecteur le champsTexte obtenu grace à la fonction que j'ai donné. J'ai fait ca pour ne pas lire le contenu des fichiers à chaque fois que je clique sur un onglet. Donc je stock tout ca dans des vecteurs que je vide une fois que le fichier est fermé :

Code :

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

1
2
3
 
                           VectFile.removeElementAt(index);
			   VectChampsTextes.removeElementAt(index);

Cela ne suffit pas apparemment

J'ai rajouté le setText("") avant d'effacer et toujours aucun effet.

Je vérifie la ram à l'arraché... avec le gestionnaire de tache windows...

[Gfx]

Si tu n'enleve pas les champs textes de ton UI tu ne risques pas de liberer la memoire. En outre, inspecter la memoire dans le gestionnaire de tache de Windows ne sert a rien. Cela ne te donne que la taille du heap, pas la quantite de memoire reellement utilisee par ton application. Utilise un profiler.

[viscere]

Ok je vais telecharger un profiler.

Mais ca ne suffit pas Champs.setText("") et remove(Champs) pour enlever les champsTexte de mon UI??

[KiLVaiDeN]

Mais ca ne suffit pas Champs.setText("") et remove(Champs) pour enlever les champsTexte de mon UI??

quand tu utilises "remove" tu n'enlèves peut-être pas toutes les références vers cet objet. De plus, si tu te sers de la String contenu dans ton champs ailleurs, il faut aussi libérer celle-ci..

adiGuba : merci pour la remarque, en effet, je sais bien qu'un close peut en cacher un autre, mais j'ai du mal à me faire à l'idée de laisser cette responsabilité à l'implémentation, et donc en général je préfère, même si c'est redondant, appliquer moi même le close; Que se passe-t-il si lors du close du BufferedReader une exception se produit, est-ce garanti que le FileReader sera close aussi ? Enfin j'imagine que oui.. Mais je t'avoue que j'ai quand même du mal à m'y faire, surtout en pensant au C++...

A+

[adiGuba]

adiGuba : merci pour la remarque, en effet, je sais bien qu'un close peut en cacher un autre, mais j'ai du mal à me faire à l'idée de laisser cette responsabilité à l'implémentation, et donc en général je préfère, même si c'est redondant, appliquer moi même le close;

J'ai fait cela pendant longtemps aussi
Mais maintenant je prèfère de loin limiter la multiplication des références et des appels à la méthode close()...
J'espère bien que les p'tits gars de chez Sun (et d'ailleurs aussi puisque Java ne repose pas essentiellement sur Sun) ont quand même écrit une implémentation bien propre

Mais le principal reste quand même d'utiliser un bloc try/finally pour fermer le flux...

Que se passe-t-il si lors du close du BufferedReader une exception se produit, est-ce garanti que le FileReader sera close aussi ?

En regardant le code de la méthode close() de BufferedReader, on peut voir ceci :

Code :

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

1
2
3
4
5
6
7
8
9
    public void close() throws IOException {
    synchronized (lock) {
        if (in == null)
        return;
        in.close();
        in = null;
        cb = null;
    }
    }

Le seul risque d'exception avant l'appel à close() du reader englobé sont donc bien faible...

a++

[viscere]

Salut,

J 'ai remarqué que lorsque je réduis la fenêtre de mon application, la mémoire utilisée affichée avec les gestionnaire de windows, se vide correctement... Lorsque je ferme mes fichiers chargés je force le garbage collector avec System.gc() et cela n'a aucun effet sur la mémoire alors que quand je réduis la fenêtre c le cas contraire...

Laurent

[Gfx]

Parce que dans ce cas Windows swappe une partie de la memoire utilisee par ton application. Tu verras que cela marche avec presque toutes les applications Windows. Cela ne signifie absolument rien dans ton cas.