L'application que je écoute souffre de manière spectaculaire d'une fuite de mémoire. À peu près, le modèle d'objet entier reste en mémoire lorsqu'un utilisateur ferme un projet chargé. La façon dont je sais que c'est parce que la fermeture d'un projet dans mon application effets à peine effets à la mémoire de l'utilisation de la mémoire dans le gestionnaire de tâches, puis d'ouvrir un nouveau projet le rend presque double à chaque fois. J'ai téléchargé la mémoire Dottrace de Jetbrain 3.5 mais il n'y a que peu (aucune) instructions d'utilisation. J'ai un peu compris comment l'utiliser et cela montre que tout le modèle d'objet est toujours en mémoire lorsque je prends un instantané après la fermeture d'un projet. Trawling à travers mon code de projet, je ne vois aucune raison de cela. Est-ce que quelqu'un connaît quelque chose en particulier qui provoque normalement des fuites de mémoire en C # ou de tout outil ou techniques de suivi du problème. C'est tout bien et bon avoir une application qui montre que tout mon modèle d'objet est toujours chargé en mémoire, mais cela ne me montre pas quel objet ou variable le stocke. Merci d'avance.
3 Réponses :
Probablement la cause la plus courante des fuites de mémoire gérées est des gestionnaires d'événements désinscrits.
Il existe un certain nombre d'outils utiles pour suivre des erreurs comme celle-ci. Personnellement, j'aime profileur de mémoire des fourmis et WINDBG / SOS. Vous voulez savoir ce qui est enracinant les graphiques d'objet. Avec Windbg / SOS, il y a une commande check Tess 'Blog pour les guides sur la procédure de dépannage Problèmes de mémoire utilisant WINDBG / SOS. ! GCroot , qui vous indiquera les racines d'un objet donné.
Premièrement, recherchez si la fuite pourrait être due à l'enregistrement des gestionnaires d'événements, car il s'agit de l'un des moyens les plus faciles de raconter accidentellement vos objets. Par exemple, si vous avez une classe 'Bob' qui ajoute l'une de ses méthodes 'OnsomeEvent' en tant que délégué à un événement qui est soulevé par un composant de longue date de votre système (par exemple, «usersettingsManager») puis des objets de classe 'Bob 'Ne sera pas collecté car ils sont maintenus vivants en raison d'être un gestionnaire d'événements (c.-à-d. Les rappels événementiels ne sont pas des références faibles).
Comme alternative aux outils commerciaux, il y a une extension au débogueur Windows appelée SOS (fils de grève) que vous pouvez utiliser pour déboguer des applications gérées. Cependant, ce n'est pas le gros coeur tel qu'il s'agit d'un outil de ligne de commande de bas niveau, qui nécessite beaucoup d'apprentissage initial. Cependant, il est très puissant et ne luttera pas tant avec des processus plus importants (en termes de consommation de tas) comme les outils commerciaux.
En termes de profileurs commerciaux, j'ai eu de bonnes expériences avec le profileur de la mémoire des fourmis de Redgate (mais j'ai eu des collègues qui la détestaient) afin que cela vaut la peine d'être testé.
Vous devriez utiliser Deleaker - cela vous aidera avec des fuites de mémoire