/ / Windows 7 x64 z aplikacją x86 .NET wyrzuci pamięć, chyba że zrobię GC.Collect - .net, windows-7, wycieki pamięci, zbieranie śmieci

Windows 7 x64 z aplikacją x86 .NET wyrzuci pamięć, chyba że zrobię GC.Collect - .net, windows-7, wycieki pamięci, zbieranie śmieci

Znalazłem rozwiązanie, ale zachowanie jest dość niepokojące i myślę, że pytam tutaj, czy ktoś jeszcze to widział.

Zasadniczo ten sam plik binarny, który został przypięty do zbudowania w x86 (wyjaśni, dlaczego poniżej) działa w systemie x64 Windows 7, wycieknie, chyba że wymuszam GC.Collect ()

Wytłumaczyć:

  1. Aplikacja wykonuje wiele rendering bitmap (> 60 na / sek)
  2. Istnieje zewnętrzna biblioteka dll C ++ (zarządzane C ++)
  3. Istnieją dwa wątki (worker i ui)
  4. Odświeżanie interfejsu użytkownika (statystyki)
  5. To zachowanie dzieje się tylko na tym komputerze, Windows 7 x86 działa dobrze.

Aplikacja wzrośnie do ponad 1,5 G i ostatecznie wyrzuci wyjątek braku pamięci. Im szybciej (1) działa szybciej wyjątek.

Dla osób gotowych do zrobienia (2) w celu spowodowania wycieku, testowałem usunięcie go i wyciek pozostał plus pamięć zostanie wydana dobrze, jeśli zrobię GC.Collect (), która w moich książkach jest problemem .NET.

Dziękuję Ci.

Odpowiedzi:

0 dla odpowiedzi № 1

OK, bo to, co jest warte, tutaj jest moim haczykiem.

widziałem dokładnie ten sam problem, którego doświadczasz. To było z powrotem w .NET 2.0, ale pracowałem z dużymi obrazami i chociaż Zwaliłbym obrazy, zużycie pamięci wzrosłoby - aż do ręcznego wywołania GC.Collect().

Co jeszcze było podobne? Hosting! Moja aplikacja była niezarządzanym plikiem EXE, który byłby użyteczny COM aby utworzyć obiekt, na który wystawiona była klasa .NET COM. To spowodowałoby, że niezarządzany EXE hostowałby CLR.

W systemie Windows X64 zostaną załadowane aplikacje X32 ŁAŁ (Windows na windows) tryb, który jest podobnym hostingu, który moim zdaniem może wykazują podobne problemy. Wydaje się GC nie może w pełni zrozumieć zużycia pamięci, gdy znajduje się w środowisku hostowanym.


0 dla odpowiedzi nr 2

Czy prawidłowo rozmieszczasz swoje mapy bitowe - i wszystkie inne dostępne zasoby, w tym obiekty GDI +?

using(Bitmap bitmap = ...)
{
... do your stuff
}

Musisz spojrzeć na swoją aplikację, aby znaleźćproblem - wyraźnie 1,5 GB jest nadmierne w przypadku aplikacji 32-bitowej. Fakt, że uzyskujesz inne zachowanie na różnych komputerach z innym systemem operacyjnym, nie oznacza, że ​​powinieneś obwiniać system operacyjny.


0 dla odpowiedzi № 3

Możesz starać się nie polegać tak bardzo na śmieciarzu. Jeśli przepisujesz swój kod remisu, aby wyczyścić nieużywane zasoby, prawdopodobnie nie dojdziesz do opisanego scenariusza.

Image.Dispose ()

Uwaga Zawsze dzwoń Usuń przed sobą zwolnij swójostatnie odniesienie do Obraz. W przeciwnym razie są to zasoby używanie nie zostanie uwolnione do czasu garbage collector wywołuje Image Metoda finalizacji obiektu.


0 dla odpowiedzi nr 4

Musisz .Wyrzuć () mapy bitowe, gdy przestaniesz ich używać. GC ostatecznie zbierze tę pamięć (gdy uruchomi finalizator), nawet jeśli nie wywołasz jawnie .Dispose () - ale GC nie jest magicznym lekiem na nadmierne przydzielanie pamięci, jeśli robisz to szybciej, niż GC zbieraj je, korzystając z zasobów, które bezpośrednio kontrolują GC (zasoby niezarządzane są dokładnie takie) - wtedy mechanizm GC nie może ci pomóc.

Dzwoniąc do GC.Collect (0) zmuszasz GC do przetwarzania drzewa obiektów i wywoływania wszystkich finalizatorów, jeśli go nie nazwiesz, GC będzie działał, kiedy myśli, że to czas, i wtedy jest za późno (z powodu wysoka stopa alokacji).