Problème de fuite de mémoire

Bonjour,

j'ai un problème de fuite de mémoire dans mon programme.
J'ai un thread qui rempli un LinkedList (remplissage excessive atteint le 200000 entré)

j'ai un autre thread qui déclenche periodiquement un traitement sur ces entré. ensuite j'aurais pas besoin de ces entrés

Pour ne pas copié chaque fois le contenu du premier Linked liste dans une autre qui sera utilisé par le deuxième thread.

j'utilise alors je jeu de référence ( qui est fortement le cause de la fuite de mémoire)

Code:

---

1 2 3 4 5

LinkedList < TimeStamp > resultStack; LinkedList < TimeStamp > newEmptyStack = new LinkedList < TimeStamp > (); resultStack = stack; stack=newEmptyStack;

---

l'objet stack ne cesse pas de grossir j'ai fais un heap dump ça taille atteint 200Mo!!

STP est ce que quelqu'un pourrai m'aider ou bien a une idée sur comment détournée se problème

Merci d'avance

Il faudrait plus de code que ça.

Cela dit, je soupçonne très fortement que tu as mis le code cité dans une méthode qui prend stack en argument ; or, réassigner l'objet dans une méthode ne réassigne pas l'objet dans l'appelant (l'appel à la méthode se fait par copie de référence).

plus de code. En particulier, il faut le code qui vide la liste, le code qui la remplit, comment tu trimballe ces listes d'un thread à l'autre et comment tu passe le tout d'une méthode à l'autre.

Citation:

---

Envoyé par tchize_

plus de code. En particulier, il faut le code qui vide la liste,

---

Je vide la liste par cette instruction: je crée un nouvelle liste vide et je l'assigne à l'ansienne liste

Code:

---

1 2 3 4

Vector < TimeStamp > newEmptyStack = new Vector < TimeStamp > (); // ensuite l'ancienne liste stack stack=newEmptyStack;

---

Citation:

---

le code qui la remplit, comment tu trimballe ces listes d'un thread à l'autre et comment tu passe le tout d'une méthode à l'autre.

---

le bout de code initial ce trouve dans une méthode qui donne en retour l'ancienne liste

Code:

---

1 2	resultStack = stack;

---

Citation:

---

Envoyé par Rei Ichido

Il faudrait plus de code que ça.

Cela dit, je soupçonne très fortement que tu as mis le code cité dans une méthode qui prend stack en argument ; or, réassigner l'objet dans une méthode ne réassigne pas l'objet dans l'appelant (l'appel à la méthode se fait par copie de référence).

---

je fais l'appel comme suit :

Code:

---

1 2	for (TimeStamp timeStamp : TimeStampStack.fetchTimeStamps())

---

le code de la méthode fetchTimeStamps est :

Code:

---

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

public static LinkedList < TimeStamp > fetchTimeStamps() { LinkedList < TimeStamp > resultStack; // the new empty stack is created here to be ready-to-use in the // synchronized block   LinkedList < TimeStamp > newEmptyStack = new LinkedList < TimeStamp > (); //resultStack = (LinkedList < TimeStamp >)stack.clone(); resultStack = stack; // if a TS is added here (between these two sync blocks) it belongs // still to the stack being collected stack = newEmptyStack; // if a TS is added at this place it will be collected next time   return resultStack; }

---

Bon, mais puisqu'elle a été affectée à resultStack, cette référence reste accessible. Quand est-ce qu'elle est censée être perdue et collectable par le garbage collector ?

en gros, l'appelant de ta méthode

1) il en fait quoi?
2) est-ce qu'il la vide.

Parce que pour le moment tu n'a montré aucun code qui vidait ta liste ou qui jetais ta liste, juste du code qui la déplace. De plus on vois toujours pas ce que tu en fais de ta liste, comment tu la rempli, et comment tout ça s'agence en pratique. Donc, s'il te plait, pourrais-tu nou poster un code complet qui reproduit ton problème.

Parce que pour le moment c'est un jeu de piste, et on aime pas la rétention d'information qui conduit à des jeux de piste à coup de deux lignes de code par ci, trois lignes par là.

Citation:

---

Envoyé par thelvin

Bon, mais puisqu'elle a été affectée à resultStack, cette référence reste accessible. Quand est-ce qu'elle est censée être perdue et collectable par le garbage collector ?

---

Normalement à la sortie de la méthode : fetchTimeStamps() cette référence ne sera perdu et donc collectable.

mais je c pas pourquoi c pa le cas

Citation:

---

Envoyé par tchize_

en gros, l'appelant de ta méthode

1) il en fait quoi?
2) est-ce qu'il la vide.

---

en faite la méthode fetchTimeStamps() est appelé par une autre méthode qui traite les éléments de la liste. normalement aprés le traitement la liste retournée par fetchTimeStamps() ne sera pa référencé et elle doit etre collecté.

la méthode fetchTimeStamps() pour moi elle retourne l'ancienne liste et vide la liste ancienne par la création d'un nouvelle liste vide

Code:

---

1 2 3 4 5

Vector < TimeStamp > newEmptyStack = new Vector < TimeStamp > (); // ensuite l'ancienne liste stack stack=newEmptyStack;

---

c'est comme ça comment je vide ma liste.

pour le remplissage j'ai une méthode ajoute les éléments dans la liste stack.

Pour le code d'ajout et du traitement il est trop long et ne va pas ajouté des information utile.

Une information qui peut etre utile, j'ai deux thread l'un rempli la liste (stack) et l'autre extraire periodiquement les éléments de liste stack et les traite.
de façon statique

Ce qui est important c'est ça (en rouge)

Code:

---

1 2 3 4 5 6 7

resultStack = stack; // if a TS is added here (between these two sync blocks) it belongs // still to the stack being collected stack = newEmptyStack; // if a TS is added at this place it will be collected next time return resultStack;

---

La ligne en noir en s'en fou un peu puisque la référence à stack n'est pas perdue.

Donc si, l'appelant a son importance et personne ne pourra répondre sans ça...

A un moment il doit y avoir une ligne du style :

Code:

---

uneStack = fetchTimeStamps();

---

Et c'est ce qui est fait par la suite avec "uneStack" qui doit poser problème.

Citation:

---

Envoyé par gailuris

Donc si, l'appelant a son importance et personne ne pourra répondre sans ça...

A un moment il doit y avoir une ligne du style :

Code:

---

uneStack = fetchTimeStamps();

---

Et c'est ce qui est fait par la suite avec "uneStack" qui doit poser problème.

---

En fait, il a donné la ligne :

Code:

---

for (TimeStamp timeStamp : TimeStampStack.fetchTimeStamps())

---

Mais bon, puisque comme précisé 2 thread peuvent acceder a la liste, mais qu'on voit pas le code de la 2e, inutile d'aller plus loin...
Pour resumer, si la liste n'est pas detruite, c'est qu'une reference sur celle-ci existe. Donc, soit il faut chercher, soit il faut donner un code minimal qui reproduit le probleme...

Citation:

---

Envoyé par hwoarang

En fait, il a donné la ligne :
...

---

Oups! au temps pour moi :oops:

J'ai pu résoudre le problème de fuite de mémoire.
En fait, la liste est utilisé uniquement dans cette instruction :

Code:

---

1 2	for (TimeStamp timeStamp : TimeStampStack.fetchTimeStamps())

---

à la sortie de cette boucle normalement la liste retourné par l'appel TimeStampStack.fetchTimeStamps() ne sera plus reférencé mais je c pa pourquoi ce n'est pas le cas.

J'ai fais alors :

Code:

---

1 2 3 4 5 6 7

LinkedList<TimeStamp> resultList = TimeStampStack.fetchTimeStamps(); for (TimeStamp timeStamp :resultList ) { ........... } resultList.clear(); resultList=null;

---

Ceci a résolu le problème.

ben elle est toujours référencée ailleurs, simplement.... Probablement dans le thread de remplissage. Mais comme t'as pas voulu donner ton code, on va pas aller plus en détail ;)