« Si IBM rachète Sun, quelles conséquences ?3 euros pour le guide de survie Hibernate »

6 commentaires

  1. § yann schwartz Email said on :
    *****
    Très bon article qui présente bien les différentes facettes du problème.

    Pour faire encore plus court, les fuites de mémoire (hors cochonneries dans du code unmanaged) :

    0) Mauvaise durée de vie des objets (voir 2)
    1) IDisposable.Dispose pas appelé (assez facile à traquer dans le source)
    2) Membres statiques à la rue
    3) Evénements sans désabonnement (illustré par ton exemple et le plus classique - et vicieux - en Winforms). A force de rencontrer ce problème j'en suis venu à implémenter dans l'objet qui expose les événements un Dispose qui vire sauvagement tous les délégués qui sont abonnés à cette instance. Bizarrement je n'ai pas vu beaucoup d'usage de cette tactique, je me demande du coup s'il y a pas un vice caché quelque part.

    Ah, sinon, dans windbg,

    !dumpheap -mt [mt] (où mt est la MethodTable qui se trouve sur la première colonne quand on fait un !dumpheap -stat et qui comme son nom l'indique, euh, représente l'identifiant unique de la classe)

    est nettement préférable à
    !dumpheap -type Toto
    qui fait une recherche par sous-chaine sur tous les types du tas (beaucoup, beaucoup plus lent)

    C'était juste pour pinailler, ton article est excellent.
  2. § Florent Email said on :
    *****
    Très bon article, très intéressant !
    Un petit parallèle avec Java et ses outils eut été le bienvenu mais bon :p
  3. § Olivier Email said on :
    *****
    Merci, très intéressant article qui me rappelle récemment une expérience réelle en combinant membre statique et évènement pour lequel on ne se désabonnait pas.

    Genre de petites choses qu'on ne pense pas forcément au moment d'écrire son code. Il faudrait presque des check list de bonnes pratiques accolée sur le mur.

    Un autre lien sur une expérience similaire : http://jclabaut.free.fr/serendipity/index.php?/archives/54-Asp.net-memory-leak-case-study-Asp.net-fuite-memoire.html
  4. § Reno Email said on :
    ****-
    Super Mario !
  5. § Bertrand J Email said on :
    *****
    Très bon article, merci!

    Au passage le bog de Tess Fernandez, une référence pour le dépistage de fuites mémoire: http://blogs.msdn.com/tess/archive/tags/Memory+issues/default.aspx
  6. § Fabrice Email said on :
    *****
    En complément, vous pouvez consulter mon nouvel article publié sur DotNetGuru :
    Détecter et éviter les fuites de mémoire et de ressources dans les applications .NET
    http://dotnetguru.org/modules.php?op=modload&name=News&file=article&sid=1283

    Fabrice

Les commentaires sont fermés pour cet article.

Contact. ©2014 by sami Jaber. blog software / hebergeur / adsense.
Design & icons by N.Design Studio. Skin by Tender Feelings adapted by Sami Jaber/ Evo Factory.