Y a-t-il encore des fuites de mémoire connues avec XMLSerialization dans .Net 3.5?

L'article http://blogs.msdn.com/tess/archive/2006/02/15/532804.aspx de Tess Ferrandez explique pourquoi l'utilisation de XMLSerialization peut provoquer des fuites de mémoire.Y a-t-il encore des fuites de mémoire connues avec XMLSerialization dans .Net 3.5?

La fuite est le résultat de la manière dont les objets sont instanciés dans la mémoire en tant qu'assemblages, et non en tant qu'objets, qui ne sont donc pas ciblés par le récupérateur de place.

L'article a été écrit à l'origine sur le CLR 1.0/1.1, mais les mises à jour ne sont pas claires sur le 2.0 CLR. J'utilise intensivement XMLSerialization/Deserialization dans une application Web encore en version bêta pour les échanges UI/serveur. Les objets sont juste des DTO (objets avec seulement des propriétés).

Merci d'avance!

Source

2009-01-22 dustinson

Il est largement résolu par le .NET 2.0 DynamicMethod. Cependant, il existe toujours un mode de défaillance si vous n'utilisez pas l'attribut [XmlRoot]. Consultez this article pour plus de détails.

Source

2009-01-22 13:38:50

La méthode dynamique ne résout pas le problème des assemblys déchargés d'un AppDomain. Il crée uniquement des méthodes collectables. – JaredPar

Pour autant que j'ai compris dans l'article, ils disent encore que vous pourriez avoir des fuites de mémoire si vous utilisez l'un des constructeurs "spéciaux". – csgero

Le lien est cassé pour moi. –

J'ai rencontré le même problème avec la version 2.0, donc je peux confirmer que la fuite de mémoire existe toujours, mais je n'ai aucune expérience avec la version 3.5. Tant que vous utilisez uniquement les constructeurs XmlSerializer (type) et XmlSerializer (type, defaultNameSpace), vous devriez être sûr, car XmlSerializers sera automatiquement mis en cache. Si vous utilisez l'un des autres constructeurs, vous devrez créer votre propre cache.

Source

2009-01-22 13:38:56 csgero

La partie qui cause réellement la fuite est que les assemblages générés par le moteur XML à des fins de sérialisation ne sont jamais collectés. À partir de CLR 2.0SP1 (.Net 3.5) c'est toujours le cas. Une fois qu'un assembly est chargé dans un processus, il ne sera pas supprimé jusqu'à ce que l'AppDomain contenant cet assembly soit également déchargé.

Si vous remarquez au bas de l'article, elle mentionne un moyen de faire en sorte que le moteur XML réutilise les assemblages pour que la mémoire ne devienne pas incontrôlable.

Source

2009-01-22 13:41:08 JaredPar

Etes-vous sûr que .NET 2.0 SP1 signifie .NET 3.5? – abatishchev

@abatishchev - .NET 3.5 utilise CLR2.0 SP1 ... donc oui – Kev

Merci. Il semble que la clé consiste à utiliser XmlSerializer (type) et permettre à l'instance en mémoire de rester en mémoire cache. Il semble que si vous alias le nom de la classe, le cache ne fonctionne pas et les fuites s'ensuivent. Je vais devoir tester et surveiller pour savoir avec certitude si nous sommes sans fuite. -Dustin

Source

2009-01-22 18:56:50 dustinson

Y a-t-il encore des fuites de mémoire connues avec XMLSerialization dans .Net 3.5?

Répondre

Questions connexes