webForumDet fria alternativet

Garbage collection på COM-objekt?

7 svar · 291 visningar · startad av clarkbones

clarkbonesMedlem sedan feb. 20013 023 inlägg
#1

Hej!

Ibland så tvingas man ju använda COM-objekt i en .NET-lösning. Nu undrar jag om även dessa är utsatta för Garbage collection eller om man skall sätta:

MinInstansExempel=Nothing

för att döda instansen?
Rimligtvis borde väl det vara garbage collection på det?

SPiNMedlem sedan mars 20007 896 inlägg
#2

Nu kan jag inte svara ja eller nej på din fråga, men kan däremot ge ett tips på att ändå frigöra minne innan GC'n kommer igång. Den vet man ju aldrig när den kör, så att fria minnet är ändå en bra grej att göra manuellt. :)

JonMedlem sedan juli 20011 304 inlägg
#3

Jag tycker att .NET brukar ha svårt att släppa resurserna automatiskt (till com-objekt).
Använder mig alltid av:

System.Runtime.InteropServices.Marshal.ReleaseComObject(myObject);

När jag är färdig :)

GladhMedlem sedan maj 20012 812 inlägg
#4

Nu kan jag inte svara ja eller nej på din fråga, men kan däremot ge ett tips på att ändå frigöra minne innan GC'n kommer igång. Den vet man ju aldrig när den kör, så att fria minnet är ändå en bra grej att göra manuellt.

Du kan inte manuellt frigöra minnet i .NET (om du inte tvingar GC att köra). Om du sätter ett objekt till NULL/Nothing så betyder inte det att minnet är frigivet. Det betyder endast att du berättar för GC att dun inte vill använda objektet mer, och GC kan ta bort den när den körs. Sedan är det så att Kompilatorn är så smart att den fatta när du inte vill använda ditt objekt mer, så i många fall är det helt menningslöst att sätta ett objekt till NULL/Nothing eftersom kompilatorn ändå gör det till dig.

Så fort du dock börjar använd dig av objekt utanför .NET så blir kravet på dig större att städa upp efter dig, eftersom GC inte är så bra på detta. Generellt kan man säga om ett objekt har en Dispose/Close method så skall den alltid kallas när man är färdig med objektet. Sedan är det den metodens uppgift att städa upp efter sitt objekt.

- Magnus

spangoMedlem sedan juni 20008 205 inlägg
#5

Gladh skrev:

Sedan är det så att Kompilatorn är så smart att den fatta när du inte vill använda ditt objekt mer, så i många fall är det helt menningslöst att sätta ett objekt till NULL/Nothing eftersom kompilatorn ändå gör det till dig.

Egentligen är det inte kompilatorn utan runtimen som listar ut när objekt ligger och dinglar fritt :)

Gladh skrev:

Så fort du dock börjar använd dig av objekt utanför .NET så blir kravet på dig större att städa upp efter dig, eftersom GC inte är så bra på detta. Generellt kan man säga om ett objekt har en Dispose/Close method så skall den alltid kallas när man är färdig med objektet. Sedan är det den metodens uppgift att städa upp efter sitt objekt.

Ett hett tips är finalization. I "finaliseraren" anropar man sånt som behövs för att stänga objekt som inte nödvändigtvis stängs av GC:n (används främst i klasser som interagerar direkt med operativsystemet, typ fil- och nätverkshantering m.m.), så du borde kunna göra ett wrapperobjekt till COM-objektet, som anropar ReleaseComObject i sin finaliserare. Se bara till att inte ha några referenser direkt till COM-objektet som kan leva kvar efter att wrapperklassen samlats upp av GC:n!

GladhMedlem sedan maj 20012 812 inlägg
#6

Är inte finalization en motsvarighet på destructorn?

Om det är det så är det ju inget bra ställe att lägga funktioner för frigivning eftersom objekt så fall kommer att hålla resourser onödigt länge...

Vad man istället bör göra är att anropa Dispose methoden i finalization och ifall ingen har anropa Dispose så körs den methoden när runtimen kallar på finalization. De förutsätter dock att finalization och destructorn är "samma sak", vilket jag har fått för mig.

- M

spangoMedlem sedan juni 20008 205 inlägg
#7

Gladh skrev:

Är inte finalization en motsvarighet på destructorn?

Jo, det är det. I C# är destruktorn en del av finaliseringen.

Gladh skrev:

Om det är det så är det ju inget bra ställe att lägga funktioner för frigivning eftersom objekt så fall kommer att hålla resourser onödigt länge...

Självklart är bättre att fimpa resurser när de inte längre behövs, men det är aldrig fel med en extra liten safeguard som ser till att man inte får minnesläckor. Bl.a. filhantering och liknande är implementerat på det här sättet, d.v.s. att de stängs under finaliseringen om de inte redan stängts.

Gladh skrev:

Vad man istället bör göra är att anropa Dispose methoden i finalization och ifall ingen har anropa Dispose så körs den methoden när runtimen kallar på finalization. De förutsätter dock att finalization och destructorn är "samma sak", vilket jag har fått för mig.

Japp, det låter som en bra lösning. Det var ungefär det jag var ute efter, fast jag är inte så haj på dotnet och COM :)

GladhMedlem sedan maj 20012 812 inlägg
#8

Bra då är vi överrens.

- M

131 ms totalt · 3 externa anrop · v20260731065814-full.30151723
0 ms — hämta forumlista (cache)
0 ms — hämta statistik (cache)
129 ms — hämta tråd, inlägg och bilagor (db)