Dela via

Hantera objektlivslängder via referensräkning

I traditionella objektsystem hanteras livscykeln för objekt – det vill säga problemen med att skapa och ta bort objekt – implicit av språket (eller språkets körtid) eller uttryckligen av applikationsprogrammerare.

I ett utvecklande, decentraliserat konstruerat system som består av återanvända komponenter är det inte längre sant att någon klient, eller ens någon programmerare, alltid "vet" hur man hanterar en komponents livslängd. För en klient med rätt säkerhetsbehörighet är det fortfarande relativt enkelt att skapa objekt via en enkel begäran, men objektborttagning är en helt annan sak. Det är inte nödvändigtvis klart när ett objekt inte längre behövs och bör tas bort. (Läsare som är bekanta med skräpinsamlade programmeringsmiljöer, till exempel Java, kanske inte håller med. Java-objekt sträcker sig dock inte över datorn eller ens processgränser, och därför är skräpinsamlingen begränsad till objekt som lever inom ett enda processutrymme. Dessutom tvingar Java användning av ett enda programmeringsspråk.) Även när den ursprungliga klienten är klar med objektet kan den inte bara stänga av objektet eftersom vissa andra klienter eller klienter fortfarande har en referens till det.

Ett sätt att se till att ett objekt inte längre behövs är att helt och hållet vara beroende av en underliggande kommunikationskanal för att informera systemet när alla anslutningar till ett korsprocess- eller korskanalobjekt har försvunnit. Scheman som använder den här metoden är dock oacceptabla av flera skäl. Ett problem är att det kan kräva en stor skillnad mellan programmeringsmodellen mellan processer/nätverk och programmeringsmodellen för en process. I programmeringsmodellen mellan processer/nätverk skulle kommunikationssystemet tillhandahålla de krokar som krävs för objektlivslängdshantering, medan objekt i programmeringsmodellen för en process är direkt anslutna utan någon mellanliggande kommunikationskanal. Ett annat problem är att det här schemat också kan resultera i ett lager av systembaserad programvara som skulle störa komponentprestanda i processfallet. Dessutom skulle en mekanism som baseras på explicit övervakning inte tendera att skalas mot tusentals eller miljontals objekt.

COM erbjuder en skalbar och distribuerad metod för den här uppsättningen problem. Klienter berättar för ett objekt när de använder det och när de är klara, och objekten tar bort sig själva när de inte längre behövs. Den här metoden kräver att alla objekt räknar referenser till sig själva. Programmeringsspråk som Java, som till sin natur har egna system för livslängdshantering, till exempel skräpinsamling, kan använda COM:s referensräkning för att implementera och använda COM-objekt internt, vilket gör att programmeraren kan undvika att hantera det.

Precis som ett program måste frigöra minne som det har allokerat när minnet inte längre används, ansvarar en klient för ett objekt för att frigöra sina referenser till objektet när objektet inte längre behövs. I ett objektorienterat system kan klienten bara göra detta genom att ge objektet en instruktion för att frigöra sig själv.

Det är viktigt att ett objekt frigörs när det inte längre används. Svårigheten ligger i att avgöra när det är lämpligt att frigöra ett objekt. Det här är enkelt med automatiska variabler (de som allokeras i stacken) – de kan inte användas utanför blocket där de deklareras, så kompilatorn frigör dem när slutet av blocket nås. För COM-objekt, som är dynamiskt allokerade, är det upp till klienterna för ett objekt att bestämma när de inte längre behöver använda objektet, särskilt lokala objekt eller fjärrobjekt som kan användas av flera klienter samtidigt. Objektet måste vänta tills alla klienter är klara med det innan det frigör sig självt. Eftersom COM-objekt manipuleras via gränssnittspekare och kan användas av objekt i olika processer eller på andra datorer, kan systemet inte hålla reda på ett objekts klienter.

COM:s metod för att avgöra när det är lämpligt att frigöra ett objekt är manuell referensräkning. Varje objekt har ett referensantal som spårar hur många klienter som är anslutna till det, det vill sa hur många pekare som finns till något av dess gränssnitt i alla klienter.

Mer information finns i följande avsnitt:

Använda och implementera IUnknown