2012-05-02 10 views
8

Mój współpracownik jest przekonany, że w implementacji adware.net odp.net jest wyciek pamięci. Pisze program testowy, aby przetestować tę teorię i robi co następuje po wywołaniu wyrzucać na każdego obiektu w celu ustalenia, ile pamięci jest zwolniona:GC.Collect() i PerformanceCounter

PerformanceCounter p = new PerformanceCounter("Memory", "Available Bytes"); 

GC.Collect(); 
GC.WaitForPendingFinalizers(); 

float mem = p.NextValue(); 

Uzyskaną wartość wydajność jest następnie porównywana z wartością pobranej przed wyrzuceniem przedmiotu. Czy da to dokładne wyniki?

+10

Nie, to nie działa menedżer pamięci. Po kłopotach z przydzieleniem wirtualnego obszaru pamięci, umieszcza zwolnione bloki z powrotem na liście wolnych bloków, gotowe do ponownego użycia później. –

+0

Czy próbowałeś używać ProcessExplorer do monitorowania pamięci .NET i użycia pamięci systemowej w twoim procesie? Nie podano, jaki rodzaj pamięci jest nieszczelny ... – GregC

+0

Nie wiemy, jaki rodzaj pamięci jest nieszczelny, co jest jednym z powodów testu, aby potwierdzić, że wystąpił problem. Moje pytanie dotyczy potwierdzenia, czy test jest ważny. – zaq

Odpowiedz

2

Myślę, że najlepszym sposobem na to jest użycie GC.GetTotalMemory(true). Możesz wywołać to przed przydzieleniem obiektu, aby zarejestrować ilość przydzielonej pamięci. Następnie tworzymy obiekt, wykonujemy na nim pewną operację, pozbywamy go, upewniamy się, że nie ma żadnych odniesień do niego (prawdopodobnie po prostu ustawiając zmienną lokalną na null), a następnie wywołujemy ją ponownie.

Przechowywać w potędze że zwrócona wartość może nie być w pełni dokładne, za dokumentacji, metoda zwróci:

numer, który jest najlepszym przybliżeniem liczby bajtów obecnie przypisane w zarządzanej pamięci .

Następnie można porównać dwie wartości. Jeśli robisz to wielokrotnie, możesz zobaczyć, czy obiekt faktycznie przecieka zarządzanej pamięci.

Oczywiście to nie pomoże, jeśli obiekt wycieknie z niezarządzanej pamięci.

Inną opcją jest użycie profilera pamięci, ale może to być przesada, jeśli wiesz, gdzie dokładnie wycieka pamięć.

+0

Dzięki za pomysł, jak lepiej uzyskać wyniki. Czy to oznacza, że ​​jest coś nie tak z podejściem, które napisałem? Dlaczego to jest lepsze podejście? – zaq

+2

Tak, twoje podejście jest złe, przeczytaj komentarz Hansa Passanta. Gdy CLR zbiera śmieci, zwykle nie zwraca pamięci z powrotem do systemu, więc możesz nie zauważyć żadnej zmiany w dostępnych bajtach, nawet jeśli pamięć została faktycznie zwolniona. – svick

Powiązane problemy