Ein Kollege von mir ist überzeugt, dass es in der odp.net ado.net-Implementierung von Oracle ein Speicherleck gibt. Er hat ein Testprogramm geschrieben, um diese Theorie zu testen und macht nach dem Aufruf von dispose an jedem Objekt die folgenden Schritte, um festzustellen, wieviel Speicher freigegeben wird:
%Vor%Der resultierende Leistungswert wird dann mit einem Wert verglichen, der vor der Entsorgung des Objekts abgerufen wurde. Wird dies genaue Ergebnisse liefern?
Ich denke, der beste Weg dazu ist GC.GetTotalMemory(true) . Sie können es aufrufen, bevor Sie das Objekt zuweisen, um aufzuzeichnen, wie viel Speicher dann zugewiesen wurde. Dann erstellst du dein Objekt, vielleicht führst du etwas daran aus, wirfst es ab, stellst sicher, dass es keine Referenzen darauf gibt (wahrscheinlich stelle nur die lokale Variable auf null ) und ruf es dann erneut an.
Beachten Sie, dass der zurückgegebene Wert möglicherweise nicht vollständig exakt ist. Die Methode gibt gemäß der Dokumentation Folgendes zurück:
Eine Zahl, die die beste verfügbare Approximation für die Anzahl der derzeit im verwalteten Speicher zugewiesenen Byte ist.
Danach können Sie die beiden Werte vergleichen. Wenn Sie dies wiederholt tun, können Sie sehen, ob das verwaltete Speicherobjekt tatsächlich ausgelaufen ist.
Natürlich hilft Ihnen das nicht, wenn das Objekt nicht verwalteten Speicher leckt.
Eine andere Option ist die Verwendung eines Speicherprofilers, aber das kann ein Overkill sein, wenn Sie wissen, wo genau der Speicher ausläuft.
Tags und Links memory-leaks .net c# odp.net performancecounter