Problème mémoire Java heap space avec tableau et ArrayList

**tchize_** · 16/06/2010, 11h25

ça représente moins de 1M de caractères, ça ne joue pas. De plus, la mise à null de ta liste va libérer de la mémoire avant l'appel à setText(). A mon avis ta consommation mémoire est ailleurs. Ce code n'est que la victime du fait que, quand on l'appelle, il ne reste déjà presque plus rien.

Ton application ne fait rien d'autre de gourmand? (charger une image de 10 mégapixels par exemple) Eventuellement, tu peux augmenter la mémoire disponible grâce au paramètre -Xmx de la jvm. Tu peux aussi suivre ce lien

http://java.developpez.com/faq/java/...ParApplication

pour déterminer la mémoire disponible avant l'utilisation de ton algorithme et après, historie de voir si c'est le coupable.

**phoenix420** · 16/06/2010, 13h52

Non mon appli charge une image de 5,31Ko donc ce n'est pas grand chose.

Mais elle gère une interface graphique utilisant un GridBagLayout comme layout manager.

Je peux coller mes méthodes pour y voir plus clair sinon ?

**phoenix420** · 16/06/2010, 14h04

Je viens de tester la mémoire utilisée par mon appli grâce au message précédent. Merci.

Pour une recherche qui donne des résultats, j'obtiens ceci par exemple :

Code :

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

1
2
3
4
5
6
premligne2.length() = 40904
 
init = 0(0K)
used = 63674592(62182K)
committed = 66650112(65088K)
max = 66650112(65088K)

Niveau mémoire utilisée comparée à la mémoire max, on peut voir que c'est presque limite quand même ...

Maintenant avec la recherche qui donne trop de résultats :

Code :

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

1
2
3
4
5
premligne2.length = 223264
init = 0(0K)
used = 65056848(63532K)
committed = 66650112(65088K)
max = 66650112(65088K)

**phoenix420** · 16/06/2010, 14h22

J'ai augmenté la mémoire en mettant comme paramètre -Xmx512m mais le problème reste inchangé.

Mais l'erreur semble provenir de l'affectation de mon String de 223264 caractères à mon JScrollPane non ? Un JScrollPane a peut-être une longueur limitée, inférieure à cette longueur là par conséquent ?

**wax78** · 16/06/2010, 15h48

Un String dans un scrollPane, montre un peu ce morceau la ?

Parce que un JscrollPane et un string il manque un truc entre les 2 il me semble

(C'est pas un textpane ou quoi plutot?)

**phoenix420** · 16/06/2010, 16h46

En fait je construis un String avec StringBuilder, puis je le convertis en String et je l'affecte au texte de mon JScrollPane. Cela donne un résultat qui me convient très bien. Par exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
Gène - - - mRNA
---------------------------------------
BC102012 - - - BC102012
CR601056 - - - CR601056
LOC643837 - - - AK091100
FLJ00074 - - - AK024480
PLA2G2D - - - NM_012400
NBPF3 - - - NM_032264
RP11-293F5.5 - - - AK095602
LUZP1 - - - NM_033631
LYPLA2 - - - CR614434
LYPLA2 - - - CR605682

**tchize_** · 16/06/2010, 19h14

Envoyé par phoenix420

Je viens de tester la mémoire utilisée par mon appli grâce au message précédent. Merci.

Pour une recherche qui donne des résultats, j'obtiens ceci par exemple :

Tu peux nous donner les valeurs que tu as avant de faire la recherche (avant d'ouvrir le fichier). C'est pas normal de consommer autant de mémoire pour si peu de travail.

**phoenix420** · 17/06/2010, 07h15

Ok ! Je ferai ça.

Là je reviens lundi je posterai une réponse lundi.

Merci.

**phoenix420** · 21/06/2010, 09h40

I'm back.

Je viens de tester l'utilisation de la mémoire avant d'effectuer une quelconque action avec mon programme. J'ai juste lancé mon programme, ce qui a pour effet de seulement ouvrir mon interface graphique.

Voilà les résultats :

Code :

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

1
2
3
4
init = 0(0K)
used = 1178072(1150K)
committed = 2031616(1984K)
max = 66650112(65088K)

Faut-il que je vide la mémoire dès que l'interface s'est ouverte ?

**tchize_** · 21/06/2010, 10h15

ça ne fait que 2M, il faut savoir où passent les 60M restant. Ce que j'aimerais moi, c'est que tu me donne la mémoire disponible juste avant ta boucle

Code :

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

while ((ligne2=kr.readLine())!=null)

et juste après. Donc dans la ligne au dessus tu fait l'output et la mémoire dispo et jsute après tu le refait (avant l'appel à setText). Ce copier/coller du bout de code c'est la méthode plus rapide pour trouver quel bout de ton code mange la mémoire

**phoenix420** · 21/06/2010, 10h42

Ok.

Donc pour une recherche qui fonctionne (hsa-mir-134) j'obtiens ceci :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
AVANT

init = 0(0K)
used = 62283584(60823K)
committed = 66650112(65088K)
max = 66650112(65088K)

APRES

init = 0(0K)
used = 63594760(62104K)
committed = 66650112(65088K)
max = 66650112(65088K)

et pour une recherche ne donnant pas de résultats car retournant trop d'occurences :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
AVANT 
 
init = 0(0K)
used = 62283808(60824K)
committed = 66650112(65088K)
max = 66650112(65088K)
 
APRES
 
init = 0(0K)
used = 64607840(63093K)
committed = 66650112(65088K)
max = 66650112(65088K)

**tchize_** · 21/06/2010, 10h45

on vois donc qu'avant même de commencer ta recherche, tu a consommé toute la mémoire. Ce qui implique que, avant le while, mais après l'affichage de l'interface, tu as un grand consommateur, reste à trouver où est celui-ci. Est-ce que, par hasard, tu ne chargerais pas tous le fichier en mémoire avant de faire la recherche? Ton reader, tu le construit comment?

**phoenix420** · 21/06/2010, 10h52

Ah ça vient peut-être de là en effet ...

Quand j'utilise un fichier texte pour le lire, je le fais comme ceci :

Code :

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

1
2
3
InputStream ips=new FileInputStream(datamicrorna); 
InputStreamReader ipsr=new InputStreamReader(ips);
BufferedReader br=new BufferedReader(ipsr);

avec datamicrorna par exemple un String qui est mon chemin d'accès à mon fichier.
Mais je ne fais pas de "br.close" après c'est vrai ...
Mais à quel moment dois-je le faire ?
Car toutes mes lignes qui suivent utilisent mon fichier texte pour les calculs etc.

**phoenix420** · 21/06/2010, 14h08

Rectification : br.close() ne ferme que la lecture du fichier, désolé.

Peut-on vider la mémoire cache pour gagner en mémoire ?

**adiGuba** · 21/06/2010, 14h11

Envoyé par phoenix420

Rectification : br.close() ne ferme que la lecture du fichier, désolé.

Heu... Il FAUT fermer ses fichiers, et avec un try/finally pour chaque fichier !!!

Si tu manipules beaucoup de fichier cela peut être très problématique...

Envoyé par phoenix420

Peut-on vider la mémoire cache pour gagner en mémoire ?

Qu'est-ce que tu appelles la "mémoire cache" exactement ???

a++

**tchize_** · 21/06/2010, 14h28

de toutes façons, ce n'est pas un handle oublié qui va consommer 60M dans le cas présent, puisqu'il s'agit d'un fichier sur le disque. A moins, que tu n'aie activé le retour en arrière dans le fichier. On peut voir tous le code depuis l'ouverture jusque la fermeture?

**phoenix420** · 21/06/2010, 14h34

Ok... On ne m'a pas appris à utiliser les blocs try/finally ....
J'utilise un bloc try/catch mais j'ai vu que normalement un bloc try/finally doit être inclus dedans.

Quand je parlais de vider la "mémoire cache" je ne sais pas trop, je pensais à effacer tout ce qui n'est plus utile pour récupérer de la mémoire et éviter mon problème de heap space. Je ne sais pas trop comment fonctionne la mémoire sous Java.

Pour mieux comprendre mon problème, voilà la méthode que j'ai programmée :

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
public static void listegenescibles() 
	{
	listlignespredictions = new ArrayList<String>();
	listlignesmrna = new ArrayList<String>();
		
	//lecture du fichier texte	
    	try
    	{
	InputStream iii = new FileInputStream(humanpredictions); 
	InputStreamReader jjj = new InputStreamReader(iii);
	BufferedReader kr = new BufferedReader(jjj);
	
	String ligne2=kr.readLine();
		
	StyledDocument doc = genes.getStyledDocument();
	MutableAttributeSet center = new SimpleAttributeSet();		
	StyleConstants.setAlignment(center, StyleConstants.ALIGN_CENTER);
	doc.setParagraphAttributes(0, 0, center, true);
	
	
	StringBuilder premligne = new StringBuilder(1000);
        premligne.append("Gène - - - mRNA\n---------------------------------------\n");

        ArrayList<String> listetest = new ArrayList<String>();
        while ((ligne2=kr.readLine())!=null)
		{
		String[] tabdonneespredictions = ligne2.split("\t", 0);		
		tabdonneespredictions[4]=tabdonneespredictions[4].toLowerCase();
			
		if (tabdonneespredictions[4].regionMatches(0, recherche, 0, longrecherche))
			{
			String occurence = tabdonneespredictions[2] +" - - - " +tabdonneespredictions[1] +"\n";
			if (!listetest.contains(occurence))
				{
				listetest.add(occurence);
				premligne.append(occurence);
				}
			}
	        }
        
	listetest=null;
	premligne.append("* * * * * * * * * * * * * * * * *");
		
		
	kr.close();
		
        genes.setText(premligne.toString()); // l'erreur s'affiche au niveau de cette ligne de code
	
    	}
	catch (Exception e1)
		{
		System.out.println(e1.toString());
		}
}

**tchize_** · 21/06/2010, 14h40

la mémoire fonctionne avec un garbage collector, qui prend bien soin de la vider quand tu en as besoin, donc ne te soucie pas de ça, il fait sont travail. Le mieux que tu as à faire, c'est de remonter progressivement avec le bout de code qui affiche la mémoire disponible, jusqu'à trouver l'endroit où ça chute. La ligne où a ton erreur importe peu, on a déjà déterminé que le problème de base c'est qu'il reste très peu de mémoire avant même de faire le travail. A toi de remonter avant pour voir ce qui consomme. Ta méthode, mis à part qu'elle ne fait pas le close dans un finally, n'a pas de gros problèmes. Donc ce n'est pas d'elle, je pense que viens le problème, mais d'autre chose avant. Reste à déterminer quoi, il faut remonter à l'appelant puis à l'appelant de l'appelant, etc jusqu'à trouver le coupable qui a mangé 60M avant que tu même que tu n démarre ta recherche dans le fichier

**phoenix420** · 21/06/2010, 15h00

Bien !

J'ai remonté mon code avec le bout de code permettant de voir l'état de la mémoire, et j'ai trouvé ce qui me prend rapidement de la mémoire après éxecution :

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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
public static void donneesmirna()
{ 
     recherche = saisiemirna.getText().toLowerCase();
     longrecherche = recherche.length();
        
     //lecture du fichier texte	
     try
         {
        	InputStream ips=new FileInputStream(datamicrorna); 
    	InputStreamReader ipsr=new InputStreamReader(ips);
             BufferedReader br=new BufferedReader(ipsr);
			
	try
    	 {		
	String ligne;
			
	while ((ligne=br.readLine())!=null)
		{
		listlignesmirbase.add(ligne);
		}
			

		System.out.println("MEMOIRE");
		MemoryMXBean memoryBean2 = ManagementFactory.getMemoryMXBean();
		System.out.println(memoryBean2.getHeapMemoryUsage());
			
		String[] tabdonneesmirbase = (String[])listlignesmirbase.toArray(new String[listlignesmirbase.size()]);
			
		int posID = 0;
		int pos1dbleslash;
			
		// j'initialise posID, la position de l'ID d'intérêt
		while(!tabdonneesmirbase[posID].regionMatches(5, recherche , 0, longrecherche))
	   		{
	   		posID++;
	   		}
			
		// j'initialise la position de la fin de la "fiche descriptive" du microRNA d'intérêt
   		pos1dbleslash=posID;
   			
		while(!tabdonneesmirbase[pos1dbleslash].regionMatches(0, "//" , 0, 2))
   			{
   			pos1dbleslash++;
   			}


....... etc