Zarządzanie cyklem życia obiektów za pomocą zliczania odwołań

W tradycyjnych systemach obiektów cykl życia obiektów — czyli problemy związane z tworzeniem i usuwaniem obiektów — są obsługiwane niejawnie przez język (lub czas wykonywania języka) lub jawnie przez programistów aplikacji.

W ewoluującym, zdecentralizowanie skonstruowanym systemie składającym się z ponownie użytych składników nie ma już prawdy, że każdy klient, a nawet każdy programista, zawsze "wie", jak radzić sobie z okresem istnienia składnika. W przypadku klienta z odpowiednimi uprawnieniami zabezpieczeń nadal jest stosunkowo łatwo tworzyć obiekty za pomocą prostego żądania, ale usunięcie obiektu jest w całości kwestią inną. Niekoniecznie jest jasne, gdy obiekt nie jest już potrzebny i powinien zostać usunięty. (Czytelnicy zaznajomieni ze środowiskami programowania zawierającymi automatyczne zarządzanie pamięcią, takimi jak Java, mogą się nie zgadzać; jednak obiekty Java nie przekraczają granic maszyn ani procesów, a zatem odzyskiwanie pamięci jest ograniczone do obiektów żyjących w przestrzeni jednoprocesowej. Ponadto język Java wymusza użycie jednego języka programowania). Nawet jeśli oryginalny klient skończy korzystanie z obiektu, nie może po prostu zamknąć obiektu, ponieważ niektórzy inni klienci nadal mogą mieć do niego odwołanie.

Jednym ze sposobów zapewnienia, że obiekt nie jest już potrzebny, jest całkowicie zależeć od bazowego kanału komunikacyjnego w celu informowania systemu o zniknięciu wszystkich połączeń z obiektem między procesami lub między kanałami. Jednak schematy korzystające z tej metody są niedopuszczalne z kilku powodów. Jednym z problemów jest to, że może to wymagać poważnej różnicy między modelem programowania między procesami/sieciami a modelem programowania jednoprocesowego. W modelu programowania między procesami/między sieciami system komunikacyjny zapewnia punkty zaczepienia niezbędne do zarządzania okresem istnienia obiektów, podczas gdy w modelu programowania jednoprocesowego obiekty są bezpośrednio połączone bez żadnego pośredniczącego kanału komunikacyjnego. Innym problemem jest to, że ten schemat może również spowodować warstwę oprogramowania dostarczonego przez system, które zakłócałoby wydajność składników w przypadku procesu. Ponadto mechanizm oparty na jawnym monitorowaniu nie będzie miał tendencji do skalowania w kierunku wielu tysięcy lub milionów obiektów.

Model COM oferuje skalowalne i rozproszone podejście do tego zestawu problemów. Klienci informują obiekt, kiedy go używają i kiedy kończą, a obiekty usuwają się same, gdy nie są już potrzebne. To podejście nakazuje, aby wszystkie obiekty liczyły odwołania do siebie. Języki programowania, takie jak Java, które z natury mają własne schematy zarządzania czasem życia, takie jak zbieranie śmieci, mogą używać zliczania odwołań w modelu COM do implementowania obiektów COM i używania ich wewnętrznie, co pozwala programiście uniknąć radzenia sobie z nimi.

Podobnie jak aplikacja musi zwolnić pamięć przydzieloną po tym, jak pamięć nie jest już używana, klient obiektu jest odpowiedzialny za zwolnienie odwołań do obiektu, gdy ten obiekt nie jest już potrzebny. W systemie zorientowanym obiektowo klient może to zrobić tylko, dając obiektowi instrukcję, aby uwolnić się.

Ważne jest, aby obiekt został zdealokowany, gdy nie jest już używany. Trudności polegają na określeniu, kiedy należy cofnąć przydział obiektu. Jest to łatwe w przypadku zmiennych automatycznych (przydzielonych na stos) — nie można ich używać poza blokiem, w którym są deklarowane, więc kompilator cofa ich przydział po osiągnięciu końca bloku. W przypadku obiektów COM, które są przydzielane dynamicznie, należy do klientów obiektu, aby zdecydować, kiedy nie muszą już używać obiektu — zwłaszcza obiektów lokalnych lub zdalnych, które mogą być używane przez wielu klientów w tym samym czasie. Obiekt musi poczekać, aż wszyscy klienci zakończą z nim pracę, zanim sam się zwolni. Ponieważ obiekty COM są manipulowane za pośrednictwem wskaźników interfejsu i mogą być używane przez obiekty w różnych procesach lub na innych maszynach, system nie może śledzić klientów obiektu.

Metoda modelu COM określania, kiedy należy zwolnić zasoby obiektu, to ręczne liczenie odwołań. Każdy obiekt utrzymuje licznik odwołań, który śledzi liczbę klientów połączonych z nim — to znaczy, ile wskaźników wskazuje na jego interfejsy w jakimkolwiek kliencie.

Aby uzyskać więcej informacji, zobacz następujące tematy:

• implementowanie zliczania odwołań
• reguły zarządzania licznikami referencji

Tematy pokrewne

używanie i implementowanie IUnknown