System.runtime.interopservices. Sejf Handle, klasa

  • Artykuł

Ten artykuł zawiera dodatkowe uwagi dotyczące dokumentacji referencyjnej dla tego interfejsu API.

Klasa SafeHandle zapewnia krytyczną finalizację zasobów obsługi, zapobiegając przedwczesnemu odzyskiwaniu dojść przez odzyskiwanie pamięci i odzyskiwaniu przez system operacyjny w celu odwołowania niezamierzonych niezamierzonych obiektów niezarządzanych.

Dlaczego Sejf Handle?

Mimo że przesłonięcia Object.Finalize do metody umożliwiają czyszczenie niezarządzanych zasobów, gdy obiekt jest zbierany na śmieci, w niektórych okolicznościach można sfinalizować obiekty mogą zostać odzyskane przez odzyskiwanie pamięci podczas wykonywania metody w wywołaniu wywołania wywołania platformy. Jeśli finalizator zwalnia dojście przekazane do tego wywołania wywołania platformy, może to prowadzić do obsługi uszkodzenia. Uchwyt można również odzyskać, gdy metoda jest zablokowana podczas wywołania wywołania wywołania platformy, na przykład podczas odczytywania pliku.

Bardziej krytycznie, ponieważ system Windows agresywnie przetwarza uchwyty, uchwyt może zostać poddany recyklingu i wskazać inny zasób, który może zawierać poufne dane. Jest to nazywane atakiem na odtwarzanie i może potencjalnie uszkodzić dane i stanowić zagrożenie bezpieczeństwa.

Co robi Sejf Handle

Klasa SafeHandle upraszcza kilka z tych problemów z okresem istnienia obiektu i jest zintegrowana z wywołaniami platformy, aby zasoby systemu operacyjnego nie wyciekły. Klasa SafeHandle rozwiązuje problemy z okresem istnienia obiektu, przypisując i zwalniając dojścia bez przerw. Zawiera krytyczny finalizator, który gwarantuje, że dojście jest zamknięte i gwarantuje uruchomienie podczas nieoczekiwanych AppDomain zwolnień, nawet w przypadkach, gdy zakłada się, że wywołanie platformy jest w stanie uszkodzonym.

Ponieważ SafeHandle dziedziczy z CriticalFinalizerObjectelementu , wszystkie niekrytyczne finalizatory są wywoływane przed żadnym z finalizatorów krytycznych. Finalizatory są wywoływane na obiektach, które nie są już aktywne podczas tego samego odzyskiwania pamięci. Na przykład FileStream obiekt może uruchomić normalny finalizator, aby opróżnić istniejące buforowane dane bez ryzyka wycieku lub recyklingu uchwytu. Ta bardzo słaba kolejność między finalizatorami krytycznymi i niekrytycznymi nie jest przeznaczona do użytku ogólnego. Istnieje ona przede wszystkim w celu ułatwienia migracji istniejących bibliotek, umożliwiając korzystanie z SafeHandle tych bibliotek bez zmieniania ich semantyki. Ponadto finalizator krytyczny i wszystkie wywołania, takie jak SafeHandle.ReleaseHandle() metoda, muszą znajdować się w ograniczonym regionie wykonywania. Nakłada to ograniczenia dotyczące kodu, który można napisać w grafie wywołań finalizatora.

Operacje wywoływania platformy automatycznie zwiększają liczbę dojść hermetyzowanych przez element SafeHandle i dekrementują je po zakończeniu. Gwarantuje to, że uchwyt nie zostanie nieoczekiwanie poddany recyklingu ani zamknięty.

Własność dojścia bazowego podczas konstruowania SafeHandle obiektów można określić, podając wartość argumentowi ownsHandle w konstruktorze SafeHandle klasy. Określa to, czy SafeHandle obiekt zwolni uchwyt po usunięciu obiektu. Jest to przydatne w przypadku obsługi z osobliwymi wymaganiami istnienia lub korzystania z uchwytu, którego okres istnienia jest kontrolowany przez kogoś innego.

Klasy pochodzące z Sejf Handle

SafeHandle jest abstrakcyjną klasą otoki dla uchwytów systemu operacyjnego. Wyprowadzanie z tej klasy jest trudne. Zamiast tego użyj klas pochodnych w Microsoft.Win32.SafeHandles przestrzeni nazw, które zapewniają bezpieczne dojścia dla następujących elementów: