Sind in .Net 3.5 noch Speicherlecks mit XMLSerialization bekannt?

Dieser Artikel http://blogs.msdn.com/tess/archive/2006/02/15/532804.aspx von Tess Ferrandez beschreibt, warum die Verwendung von XMLSerialization Speicherlecks verursachen kann.Sind in .Net 3.5 noch Speicherlecks mit XMLSerialization bekannt?

Das Leck ist ein Ergebnis davon, wie die Objekte im Speicher als Assemblys instanziiert werden, nicht als Objekte, also nicht als Ziel für den Garbage Collector.

Der Artikel wurde ursprünglich auf der 1.0/1.1 CLR geschrieben, aber die Updates sind unklar über die 2.0 CLR.

Ich verwende XMLSerialization/Deserialization ausführlich in einer Web-App noch in der Beta für UI/Server-Austausch. Die Objekte sind nur DTOs (Objekte mit nur Eigenschaften).

Vielen Dank im Voraus!

Quelle

2009-01-22 dustinson

Es wird weitgehend durch die .NET 2.0 DynamicMethod gelöst. Es gibt jedoch weiterhin einen Fehlermodus, wenn Sie das [XmlRoot] -Attribut nicht verwenden. Überprüfen Sie this article für Details.

Quelle

2009-01-22 13:38:50

Dynamische Methode behebt nicht das Problem von Baugruppen, die aus einer Anwendungsdomäne entladen werden. Es erstellt nur sammelbare Methoden. – JaredPar

Soweit ich in dem Artikel verstanden habe, sagen sie immer noch, dass Sie Speicherlecks haben könnten, wenn Sie einen der "speziellen" Konstruktoren verwenden. – csgero

Link ist für mich kaputt. –

Ich lief in das gleiche Problem mit 2.0, so kann ich bestätigen, dass das Speicherleck immer noch dort existiert, aber ich habe keine Erfahrung mit 3.5. Solange Sie nur die Konstruktoren XmlSerializer (Typ) und XmlSerializer (Typ, defaultNameSpace) verwenden, sollten Sie sicher sein, da die XmlSerializer automatisch zwischengespeichert werden. Wenn Sie einen der anderen Konstruktoren verwenden, müssen Sie einen eigenen Cache erstellen.

Quelle

2009-01-22 13:38:56 csgero

Der Teil, der das Leck verursacht, besteht darin, dass die von der XML-Engine für Serialisierungszwecke generierten Assemblys nicht gesammelt werden. Ab CLR 2.0SP1 (.Net 3.5) ist dies immer noch der Fall. Sobald eine Assembly in einen Prozess geladen wurde, wird sie nicht entfernt, bis die AppDomain, die diese Assembly enthält, ebenfalls entladen wird.

Wenn Sie jedoch am Ende des Artikels bemerken, erwähnt sie eine Möglichkeit, die XML-Engine die Assemblys wiederverwenden, so dass der Speicher nicht außer Kontrolle gerät.

Quelle

2009-01-22 13:41:08 JaredPar

Sind Sie sicher, dass .NET 2.0 SP1 .NET 3.5 bedeutet? – abatishchev

@abatishchev - .NET 3.5 verwendet CLR2.0 SP1 ... also ja – Kev

Vielen Dank. Es scheint, als ob der Schlüssel ist, XmlSerializer (Typ) zu verwenden und zuzulassen, dass die speicherinterne Instanz zwischengespeichert wird. Es scheint, dass, wenn Sie den Klassennamen Aliasnamen der Cache nicht funktioniert und die Lecks ergeben .. Ich muss testen und überwachen, um sicher zu wissen, wenn wir leckfrei sind. -Dustin

Quelle

2009-01-22 18:56:50 dustinson

Sind in .Net 3.5 noch Speicherlecks mit XMLSerialization bekannt?

Antwort

Verwandte Themen