6
votes

C # - Méthode de tentative programmatique de vérifier la fuite de mémoire en bloc de code

J'essaie de voir à quel point il est possible de tenter de déterminer avec précision qu'il existe une fuite de mémoire potentielle dans un bloc de code géré de manière programmatique. La raison de ce faire serait d'isoler un bloc de code qui semble fuite de la mémoire et d'utiliser ensuite un profileur standard pour déterminer davantage la cause réelle de la fuite. Dans mon cas de rentabilisation particulière, je chargerais une classe de 3ème partie qui étend une des miennes à la vérifier pour les fuites.

L'approche qui vient à l'esprit est quelque chose comme ceci:

  • attendez que GC fonctionne.
  • Obtenez la mémoire allouée actuelle du GC.
  • [Lancez le bloc de code géré.]
  • attendez que GC fonctionne.
  • Obtenez la mémoire allouée actuelle du GC et soustrayez de la mémoire allouée enregistrée avant d'exécuter le bloc de code. Est-il correct que la différence devrait être théoriquement (près) 0 si tous les objets alloués dans le bloc de code qui fonctionnaient étaient déréférencés de manière appropriée et collectée?

    Certes, le problème immédiat avec c'est qu'il y aura probablement d'attendre ... et d'attendre ... et d'attendre que le GC non déterministe fonctionne. Si nous ignorons cet aspect, le calcul permettant de déterminer si le bloc de code a fui toute mémoire peut faire varier sauvagement et ne serait pas nécessairement précis, car certains éléments n'ont peut-être pas été collectés à l'époque.

    Ce qui précède semble-t-il que ma meilleure option d'essayer de déterminer quelque peu avec précision si un bloc de code est la mémoire de la mémoire? Ou y a-t-il d'autres méthodes de travail utilisées dans la vie réelle? Merci.


1 commentaires

FYI Vous pouvez forcer la collecte des ordures en appelant gc.collect ()


3 Réponses :


6
votes

Personnellement, je n'oserais jamais faire du profil de mémoire seul. Je craignai que je n'ai pas la connaissance complète et que cela prendrait du temps sans fin pour le faire.

Au lieu de cela, j'ai utilisé des profileurs de mémoire avec succès tels que la mémoire des fourmis de la porte rouge Profiler .


3 commentaires

Redgate la société ne fait-il pas payer de frais pour le réflecteur après la promesse qu'il serait toujours libre. Tromper moi une fois redgate, honte sur toi, te tromper deux fois .....


@Im j'en étais presque sûr de ce commentaire viendra :-) Néanmoins que le profileur de mémoire des fourmis est un outil superbe pour moi, donc je vais continuer à utiliser ILSPY et toujours acheter des produits de la porte rouge.


:-) Je ne faisais que demi de plaisanter sur Redgate, je peux regarder leur profileur. Mais l'entreprise de réflecteur a vraiment laissé un mauvais goût dans ma bouche. Et ce n'est pas sur l'argent, c'était juste le principe de la façon dont ils allaient à ce sujet. J'utilise maintenant ILSPY aussi bien, c'est bien, ce qui est de plus que ce qui m'aidait à apprendre git aussi :-)



1
votes

Lorsque vous utilisez des fourmis, le profileur est génial, cela ne vous aide pas si votre problème n'est vu que dans la production.

Tess Ferrandez a une série de Labs qui démontrent comment déboguer les problèmes de production , y compris des fuites de mémoire. Ils se concentrent sur ASP.NET mais il peut également être utilisé pour d'autres types d'applications.


1 commentaires

Celui-ci de ses articles fait référence aux problèmes de mémoire. Super!



0
votes

Vous avez vraiment besoin d'un profileur de mémoire comme celui-ci : avec cela, vous pouvez:

  • Démarrez votre application, prenez une instantanée de mémoire (manuellement ou de votre code)
  • [Bloc de gestion du code géré]
  • Prenez un autre instantané de mémoire
  • Comparez les deux instantanés et voyez quels nouveaux objets sont maintenant sur le tas géré

    Je crois que cela fait exactement ce que vous voulez faire, seulement beaucoup moins douloureux. Il possède également des filtres utiles tels que "Afficher les objets qui sont conservés en vie par des délégués". Il peut également analyser des décharges de mémoire à partir d'un système de production.


0 commentaires