Kiedy powinienem zaimplementować IDispose w klasie, a nie w destruktorze? Przeczytałem ten artykuł , ale nadal nie rozumiem.
Zakładam, że jeśli zaimplementuję IDispose na obiekcie, mogę wyraźnie go „zniszczyć”, zamiast czekać, aż zrobi to garbage collector. Czy to jest poprawne?
Czy to oznacza, że zawsze powinienem jawnie wywoływać metodę Dispose na obiekcie? Jakie są typowe tego przykłady?
Odpowiedzi:
Finalizator (aka destructor) jest częścią garbage collector (GC) - jest nieokreślony, kiedy (a nawet jeśli) tak się dzieje, ponieważ GC dzieje się głównie w wyniku presji pamięci (tj. Potrzebuje więcej miejsca). Finalizatory są zwykle używane tylko do czyszczenia niezarządzanych zasobów, ponieważ zasoby zarządzane będą miały własną kolekcję / utylizację.
Stąd IDisposablejest używany do deterministycznego czyszczenia obiektów, czyli teraz. Nie gromadzi pamięci obiektu (która nadal należy do GC) - ale służy na przykład do zamykania plików, połączeń z bazami danych itp.
Istnieje wiele wcześniejszych tematów na ten temat:
Na koniec należy zauważyć, że nierzadko zdarza się, że IDisposableobiekt ma również finalizator; w tym przypadku Dispose()zwykle wywołuje GC.SuppressFinalize(this), co oznacza, że GC nie uruchamia finalizatora - po prostu wyrzuca pamięć (znacznie taniej). Finalizator nadal działa, jeśli zapomnisz o Dispose()obiekcie.
Rolą tej Finalize()metody jest zapewnienie, że obiekt .NET może wyczyścić niezarządzane zasoby podczas zbierania elementów bezużytecznych . Jednak obiekty, takie jak połączenia z bazami danych lub programy obsługi plików, powinny zostać zwolnione tak szybko, jak to możliwe, zamiast polegać na usuwaniu elementów bezużytecznych. W tym celu należy zaimplementować IDisposableinterfejs i zwolnić zasoby w Dispose()metodzie.
W witrynie MSDN jest bardzo dobry opis :
Głównym zastosowaniem tego interfejsu jest zwalnianie niezarządzanych zasobów . Moduł odśmiecania pamięci automatycznie zwalnia pamięć przydzieloną do zarządzanego obiektu, gdy ten obiekt nie jest już używany. Jednak nie można przewidzieć, kiedy nastąpi wyrzucanie elementów bezużytecznych . Ponadto moduł odśmiecania pamięci nie ma wiedzy o niezarządzanych zasobach, takich jak uchwyty okien lub otwarte pliki i strumienie.
Użyj metody Dispose tego interfejsu, aby jawnie zwolnić niezarządzane zasoby w połączeniu z modułem wyrzucania elementów bezużytecznych. Konsument obiektu może wywołać tę metodę, gdy obiekt nie jest już potrzebne.
Jedyną rzeczą, która powinna znajdować się w destruktorze C #, jest ta linia:
Dispose(False);Otóż to. W tej metodzie nie powinno być niczego innego.
Twoje pytanie, czy zawsze powinieneś dzwonić, Disposejest zwykle gorącą debatą. Zobacz ten blog, aby poznać ciekawą perspektywę szanowanych osób w społeczności .NET.
Osobiście uważam, że stanowisko Jeffreya Richtera, że sprawdzanie Disposenie jest obowiązkowe, jest niesamowicie słabe. Podaje dwa przykłady na uzasadnienie swojej opinii.
W pierwszym przykładzie mówi, że wywoływanie Disposekontrolek Windows Forms jest żmudne i niepotrzebne w głównych scenariuszach. Jednak nie wspomina, że Disposefaktycznie jest wywoływana automatycznie przez kontenery kontrolne w tych głównych scenariuszach.
W drugim przykładzie stwierdza, że programista może błędnie założyć, że instancja from IAsyncResult.WaitHandlepowinna zostać agresywnie usunięta, nie zdając sobie sprawy, że właściwość leniwie inicjuje uchwyt oczekiwania, co skutkuje niepotrzebnym spadkiem wydajności. Ale problem z tym przykładem polega na tym, że IAsyncResultsam w sobie nie jest zgodny z opublikowanymi przez Microsoft wytycznymi dotyczącymi postępowania z IDisposableobiektami. Oznacza to, że jeśli klasa zawiera odniesienie do IDisposabletypu, to sama klasa powinna implementować IDisposable. Gdyby postępowano IAsyncResultzgodnie z tą zasadą, wówczas jego własna Disposemetoda mogłaby podjąć decyzję dotyczącą tego, którego z jej członków należy usunąć.
Więc jeśli ktoś nie ma bardziej przekonujących argumentów, pozostanę w obozie „zawsze wzywaj utylizację” ze zrozumieniem, że będą pewne przypadki poboczne, które wynikną głównie ze złych wyborów projektowych.
To naprawdę proste. Wiem, że udzielono odpowiedzi, ale spróbuję ponownie, ale postaram się, aby było to tak proste, jak to tylko możliwe.
Generalnie nigdy nie należy używać destruktora. To tylko run .net chce, żeby działał. Będzie działać tylko po cyklu zbierania śmieci. W rzeczywistości może nigdy nie zostać uruchomiona podczas cyklu życia aplikacji. Z tego powodu nigdy nie należy umieszczać żadnego kodu w destruktorze, który „musi” zostać uruchomiony. Nie można również polegać na tym, że jakiekolwiek istniejące obiekty w klasie będą istniały podczas jej uruchamiania (mogły już zostać wyczyszczone, ponieważ kolejność działania destruktorów nie jest gwarantowana).
IDisposible powinno być używane zawsze, gdy masz obiekt, który tworzy zasoby wymagające oczyszczenia (np. Uchwyty plików i grafiki). W rzeczywistości wielu twierdzi, że wszystko, co umieścisz w destruktorze, powinno być umieszczone w IDisposable z powodów wymienionych powyżej.
Większość klas wywołuje metodę dispose, gdy finalizator jest wykonywany, ale jest to po prostu zabezpieczenie i nigdy nie powinno się na nim polegać. Powinieneś jawnie pozbyć się wszystkiego, co implementuje IDisposable, kiedy skończysz z tym. Jeśli zaimplementujesz IDisposable, powinieneś wywołać dispose w finalizerze. Przykład można znaleźć pod adresem http://msdn.microsoft.com/en-us/library/system.idisposable.aspx .
Oto kolejny świetny artykuł, który usuwa część mgły otaczającej IDisposable, GC i dispose.
usingkonstrukcji.