Problème de Ram/Detruire Objets

Version imprimable

18/07/2006, 10h25
viscere

Problème de Ram/Detruire Objets

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
18/07/2006, 10h39
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++
18/07/2006, 10h49
viscere

ben j'utilise pour ouvrir mes fichiers :

fichierCourant = new File(filename);

et y a pas de fonction close... donc je met a null.
18/07/2006, 10h53
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++
18/07/2006, 10h59
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+

ah oui pardon...

Voici ma fonction qui lit le fichier File (fichierCourant)

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

18/07/2006, 12h17
adiGuba

Citation:

Envoyé par viscere

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++
18/07/2006, 12h18
KiLVaiDeN
Déclare un objet FileReader aussi, au lieu de faire un new FileReader, je pense que ça peut aider le garbage collector.
Code:

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.
18/07/2006, 12h20
adiGuba

Citation:

Envoyé par KiLVaiDeN

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++
18/07/2006, 13h22
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..
18/07/2006, 13h32
adiGuba

Citation:

Envoyé par viscere

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

Citation:

Envoyé par viscere

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++
18/07/2006, 13h36
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.
18/07/2006, 13h57
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:

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...
18/07/2006, 14h26
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.
18/07/2006, 14h35
viscere

Ok je vais telecharger un profiler.

Mais ca ne suffit pas Champs.setText("") et remove(Champs) pour enlever les champsTexte de mon UI??
18/07/2006, 15h06
KiLVaiDeN

Citation:

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++... :aie:

A+ ;)
18/07/2006, 15h34
adiGuba
Citation:

Envoyé par KiLVaiDeN

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

Citation:

Envoyé par KiLVaiDeN

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:

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++
24/07/2006, 11h25
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
24/07/2006, 20h15
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.