Fuite mémoire .NET

Bonjour,

Je sais que il y a déja plusieurs sujet sur les fuites mémoire, mais m'a question est en relation au framework .Net.
Jvai peut être poser une question idiote mais, est ce qu'il peut y avoir des fuites mémoires en .Net (c#)?
En utilisant un profiler (Your Kit Profiler 3.0.5 for .net) j'ai pu visualiser le % d'utilisation du GC, qui peut certaines fois atteindre 100%, c grave ?
En mm temps mon programme charge une grosse structure d'idientifiants.
Alors je sais pas si je dois revoir mon code ou pas ...

Merci pour votre aide

Citation:

---

Envoyé par alaks

En mm temps mon programme charge une grosse structure d'idientifiants.

---

c'est à dire ?

Citation:

---

Envoyé par alaks

Jvai peut être poser une question idiote mais, est ce qu'il peut y avoir des fuites mémoires en .Net (c#)?

---

Oui, par exemple si tu crées des objets infiniment en espérant qu'ils soient collectés par le GC mais en gardant une référence ailleurs genre dans une List, donc ils ne seront jamais collectés et la mémoire utilisée ne fera qu'augmenter ...

Citation:

---

Envoyé par smyley

Oui, par exemple si tu crées des objets infiniment en espérant qu'ils soient collectés par le GC mais en gardant une référence ailleurs genre dans une List, donc ils ne seront jamais collectés et la mémoire utilisée ne fera qu'augmenter ...

---

ça sens le vécu ;).

Pour ce qui est de la fuite mémoire, une autre des causes possible est l'utilisation incorrect de ressources non managé ( IE : PInvoke ) et l'oubli d'appeler Dispose sur les objet qui implémente IDisposable ...

Merci pour vos réponses.

Quand je parlais d'identifiants je fait allusion en fait à des string (ex: "00011101", ..).
En fait je rempli plusieurs arbres avec plus millions de string, ces listes me servent de reference pour la comparaison avec des arraylist de string.
Apres tous ce que vous avait dit, l'interface IDisposable est elle hérité de tous objets ? je voulais utilisai la méthode dispose sur une arraylist mais je l'ai pas trouvé ..

Dans la piece jointe , le code de liberation mémoire :
Pièce jointe 28065

Mon arbre a la structure suivante :
Pièce jointe 28066

dois je faire heriter la classe de l'interface IDisposable, destructeur, ...

Citation:

---

Envoyé par alaks

En fait je rempli plusieurs arbres avec plus millions de string

---

hum...t'aurais un autre algo ? :aie:

Citation:

---

Envoyé par dev01

ça sens le vécu ;).

---

:aie:

Citation:

---

Envoyé par dev01

l'oubli d'appeler Dispose sur les objet qui implémente IDisposable ...

---

Il n'est pas nécéssaire d'appeler manuellement Dispose, mais c'est préférable (le GC peut le faire automatiquement).

Citation:

---

Envoyé par alaks

Apres tous ce que vous avait dit, l'interface IDisposable est elle hérité de tous objets ?

---

Non

Citation:

---

Envoyé par The_badger_man

hum...t'aurais un autre algo ? :aie:

---

+1, il y a forcément mieux ...

Citation:

---

Envoyé par smyley

Il n'est pas nécéssaire d'appeler manuellement Dispose, mais c'est préférable (le GC peut le faire automatiquement).

---

Oui et non. Le problème des ressources non managé et donc de dispose c'est que l'on ne sais jamais si ça va fontionner ou non :aie:. Les bests practices sont assez claire la dessus, ou on appelle Dispose() ou on utilise

Code:

---

1 2 3 4 5

using ( MaRessourceDisposable ) {   }

---

mais on ne laisse pas le garbage collector le faire ;).

Dans ce cas, je vais me pencher sur l'interface IDisposable, et faire heriter les classes qui en ont besoin

Citation:

---

Envoyé par smyley

Il n'est pas nécessaire d'appeler manuellement Dispose, mais c'est préférable (le GC peut le faire automatiquement).

---

Faux, le GC n'appellera jamais Dispose. Au mieux il appellera le finaliseur (méthode Finalize(), créée via la syntaxe d'un destructeur de classe en C#), qui, s'il est bien conçu, appellera lui-même Dispose. Mais ce n'est en aucun cas une obligation d'appeller Dispose dans le finaliseur.
Dispose est prévu pour faire de la libération de ressources au plus tôt, de manière explicite, et idéalement pour éviter de passer par les finaliseurs qui sont relativements coûteux pour le GC, car ils imposent une deuxième passe sur l'objet.

ça doit être lié à ma manière de coder alors :aie:

Code:

---

1 2 3 4 5 6 7 8 9 10

class Bidule : IDisposable { ~Bidule() { Dispose(); }   ... }

---

Je pense que c'est nécéssaire dès que l'on gère des ressources non managés ou qu'il est nécéssaire d'effectuer des actions lorsqu'un objet est détruit ...

Citation:

---

Envoyé par smyley

ça doit être lié à ma manière de coder alors :aie:

Code:

---

1 2 3 4 5 6 7 8 9 10

class Bidule : IDisposable { ~Bidule() { Dispose(); }   ... }

---

Je pense que c'est nécéssaire dès que l'on gère des ressources non managés ou qu'il est nécéssaire d'effectuer des actions lorsqu'un objet est détruit ...

---

Ton code me pose un problème : L'utilisation des destructeur est déconseillé car ça ralenti le travail du GC ... Or tu l'utilises pour faire une action qui, à mon avis, ne doit pas être faite à la destruction mais bien à la fin de l'utilisation de l'objet. Bref personnellement je supprimerais le destructeur et j'utiliserais la directive using pour être sur que le système appel Dispose

Citation:

---

Envoyé par dev01

Ton code me pose un problème : L'utilisation des destructeur est déconseillé car ça ralenti le travail du GC ... Or tu l'utilises pour faire une action qui, à mon avis, ne doit pas être faite à la destruction mais bien à la fin de l'utilisation de l'objet. Bref personnellement je supprimerais le destructeur et j'utiliserais la directive using pour être sur que le système appel Dispose

---

En l'état ce code est effectivement un problème, mais appeller Dispose dans le finaliseur est plutôt une bonne pratique, à condition de ne pas le faire n'importe comment.

Il suffit de se retirer de la file de finalisation dans le dispose. Si on l'appelle explicitement (via un appel direct ou via la fin du bloc using), la finalisation n'a pas lieu, mais si par quelque moyen que ce soit, le dispose n'est pas appelé explicitement, le nettoyage aura lieu au prix du finaliseur.

cf le MSDN : http://msdn2.microsoft.com/en-us/lib...sfinalize.aspx

Citation:

---

Envoyé par Greybird

En l'état ce code est effectivement un problème, mais appeller Dispose dans le finaliseur est plutôt une bonne pratique, à condition de ne pas le faire n'importe comment.

Il suffit de se retirer de la file de finalisation dans le dispose. Si on l'appelle explicitement (via un appel direct ou via la fin du bloc using), la finalisation n'a pas lieu, mais si par quelque moyen que ce soit, le dispose n'est pas appelé explicitement, le nettoyage aura lieu au prix du finaliseur.

cf le MSDN : http://msdn2.microsoft.com/en-us/lib...sfinalize.aspx

---

:ccool: j'en prend note :)

Citation:

---

Envoyé par dev01

Bref personnellement je supprimerais le destructeur et j'utiliserais la directive using pour être sur que le système appel Dispose

---

Je me permettrais de rajouter une chose: en tant que développeur, tu connais ton code et tu sais donc que ta classe implémente IDisposable. Tu es donc en mesure de savoir que tu peux appeller Dispose.

Mais dans le cas où tu travailles avec d'autres développeurs qui ne font pas de bloc using ou qui n'appelle pas Dispose (car ils n'ont pas vu que c'était possible), passer par le destructeur te permet de t'assurer que le Dispose est appelé ;)

Citation:

---

Envoyé par Thomas Lebrun

Mais dans le cas où tu travailles avec d'autres développeurs qui ne font pas de bloc using ou qui n'appelle pas Dispose (car ils n'ont pas vu que c'était possible), passer par le destructeur te permet de t'assurer que le Dispose est appelé ;)

---

Yep mais je travail avec de bon développeur qui savent lire une documentation que j'ai généré et ils savent donc qu'il faut appeler Dispose sur les objets qu'ils utilisent :aie:

Plus sérieusement, c'est une très bonne remarque, je la rajoute dans mon calepin à bonne remarque :aie:

Citation:

---

Envoyé par dev01

Yep mais je travail avec de bon développeur qui savent lire une documentation que j'ai généré et ils savent donc qu'il faut appeler Dispose sur les objets qu'ils utilisent :aie:

---

:aie::aie: ... une parole sage m'est venue à l'idée :

Citation:

---

any attempt to make any system idiot proof will only challenge God to make a better idiot

---

Donc il y en aura forcément un qui verra pas :aie:

Citation:

---

Envoyé par Thomas Lebrun

Je me permettrais de rajouter une chose: en tant que développeur, tu connais ton code et tu sais donc que ta classe implémente IDisposable. Tu es donc en mesure de savoir que tu peux appeller Dispose.

Mais dans le cas où tu travailles avec d'autres développeurs qui ne font pas de bloc using ou qui n'appelle pas Dispose (car ils n'ont pas vu que c'était possible), passer par le destructeur te permet de t'assurer que le Dispose est appelé ;)

---

L'appel du finalizer tu ne le maitrises pas, si tu laisses charge au GC de libérer tes ressources ça peut donner un programme qui semble fonctionner de manière aléatoire. Par exemple si tu encapsules une ressource native limitée, que tu n'appelles pas explicitement dispose et qu'il n'y a pas de pression sur la mémoire alors ta ressource native ne sera jamais libérée et l'appli peut en manquer (alors que si la mémoire est sous pression le GC est appelé et les finalize aussi)... Vaut-il mieux un programme qui "plante" tout le temps en implémentant pas de finalizer et en demandant un appel explicite au dispose (facile à débuguer en cas de pb) ou un programme qui fonctionnera probablement souvent mais avec un risque de plantage aléatoire (plus dur à débuguer) ?

Citation:

---

Envoyé par Sphax

Par exemple si tu encapsules une ressource native limitée, que tu n'appelles pas explicitement dispose et qu'il n'y a pas de pression sur la mémoire alors ta ressource native ne sera jamais libérée et l'appli peut en manquer

---

C'est pour celà qu'on a inventé GC.AddMemoryPressure.

Citation:

---

Envoyé par dev01

Plus sérieusement, c'est une très bonne remarque, je la rajoute dans mon calepin à bonne remarque :aie:

---

:yaisse2:

Mais bon, je suis assez d'accord avec toi: normalement, on doit toujours lire la doc ;)

Citation:

---

Envoyé par smyley

C'est pour celà qu'on a inventé GC.AddMemoryPressure.

---

Je ne vois pas le rapport. Cette méthode est faite pour informer le GC que tu as alloué beaucoup de mémoire non managée c'est tout. Ou alors tu veux l'utiliser de manière artificielle dés que tu utilises une ressource non managée pour forcer plus souvent le GC à tourner ? Mauvaise idée à mon avis.

Wow ca a bien avancé depuis la derniere fois.
Mais j'avoue que je suis un peu perdu, alors vaudrait 'il mieux faire un destructeur, appelé dispose et supprimé l'objet de la liste des elements a finaliser, ou laisser le GC faire tout, tout seul ? :D

Petite question : dans une structure en liste chainée (d'objets), pour éviter les fuites mémoire il faudrai mettre tous les objets de la liste a null, ou seulement la réference de la liste chainée ?


Merci

Citation:

---

Envoyé par alaks

Wow ca a bien avancé depuis la derniere fois.
Mais j'avoue que je suis un peu perdu, alors vaudrait 'il mieux faire un destructeur, appelé dispose et supprimé l'objet de la liste des elements a finaliser, ou laisser le GC faire tout, tout seul ? :D

Petite question : dans une structure en liste chainée (d'objets), pour éviter les fuites mémoire il faudrai mettre tous les objets de la liste a null, ou seulement la réference de la liste chainée ?


Merci

---

Laisser faire le GC seul, c'est à dire implémenter un finilazer sans implémenter dispose est une trés mauvaise idée. Si tu encapsules des ressources natives il FAUT implémenter dispose, la question est: faut-il aussi faire un finalizer ? Je crois que c'est préconisé par MS, moi je ne suis pas sur de l'utilité (voir mes réponses précédentes) sauf peut être dans des cas très particuliers.

Pour ta structure en liste chaînée, le GC est qd même intelligent, il recherche l'ensemble des références "atteignables" et supprime les autres. Des éléments d'une liste null (donc non atteignable) sont également non atteignables et seront collectés.

Citation:

---

Envoyé par alaks

Petite question : dans une structure en liste chainée (d'objets), pour éviter les fuites mémoire il faudrai mettre tous les objets de la liste a null, ou seulement la réference de la liste chainée ?

---

Si ta liste chainé est 100 % .NET alors tu n'as rien à faire, le GC s'occupe de tout :) .

Citation:

---

Envoyé par Sphax

Je ne vois pas le rapport. Cette méthode est faite pour informer le GC que tu as alloué beaucoup de mémoire non managée c'est tout. Ou alors tu veux l'utiliser de manière artificielle dés que tu utilises une ressource non managée pour forcer plus souvent le GC à tourner ? Mauvaise idée à mon avis.

---

Mal utilisé, c'est une mauvaise idée, mais tu ne devrais pas sous estimer cette solution. Il vaut mieux avoir des Collect un peut plus souvent plutôt que d'avoir une application qui utilise 300 Mo sans jamais s'arrêter simplement parce qu'elle contient 80 Mo de données managées et le reste non managé.

Citation:

---

Envoyé par smyley

Mal utilisé, c'est une mauvaise idée, mais tu ne devrais pas sous estimer cette solution. Il vaut mieux avoir des Collect un peut plus souvent plutôt que d'avoir une application qui utilise 300 Mo sans jamais s'arrêter simplement parce qu'elle contient 80 Mo de données managées et le reste non managé.

---

Non mais on se comprend pas là. Bien sûr que si tu a des classes qui "encapsulent" beaucoup de mémoire non managée alors il faut utiliser cette méthode, c'est fait pour ça ! Maintenant qd on parle de ressources non managées c'est aussi souvent des handles (ouverture de fichiers, mutex etc...) et dans ce cas tu ne vas pas utiliser AddMemoryPressure pour artificiellement générer des collectes...

Globalement ce que je veux dire c'est que l'appel des finalizer est lié à la gestion de la mémoire, que c'est non déterministe et surtout sans lien direct souvent avec la ressource que tu gères (tu peux ouvrir plein de handle sans jamais générer de garbage collection et inversement, ce n'est pas lié). A partir de là pour moi l'intérêt et plus que limité, contrairement aux destructeurs du C++ qui sont déterministes, ils sont appelés dés qu'on sort du scope de l'objet.