dotNETportal.cz

uvítal bych jakýkoliv článek (nejlépe vb.net) na téma uvolňování zdrojů (managed/unmanaged). Chování GC a nějaké to polopatické vysvětlecí co se s objekty děje, kde nastávají problémy a chyby programátora a jak tomu zabránit - mrtvolky v paměti.

Jak používat rozhrani IDisposable.

Jaký je rozdíl mezi dispose a finalize. Co kdy volat a nevolat.

Sám píšu delší dobu pro Compact framework a tohle téma mě velmi dlouho nezajímalo, aplikace typu hello world moc paměti nezaberou. Teď jsem ve stádiu, kdy netuším co a proč volat, četl jsem toho hodně, ale pořád tomu nerozumím. Já si otestoval, kam co napsat, aby mi aplikace nesežrala všechnu paměť, ale moudrý z toho tedy nejsem.

článků by to mohlo být i několik, z pohledu implementace vlastí disposable metody (co do ní napsat, jak uvolňovat...) a z pohledu používání .dispose . Já praktikuji zavírání do try, catch, finally kde ve finally disposuji použité zdroje a potom všechno nastavuji na nothing. s pamětí je to ok, ale je to strašná slohová práce a taky se mi to nezdá po stránce programátorské. takové strašlivě nesystémové a buhví kolik to sežere výkonu.

No, článek na toto téma by se sem určitě hodil, nic pořádného o tom nemáme, jestli budu mít čas, tak ho napíšu.

Abyste měl klidnější spaní, zkusím popsat úplné základy v jednom odstavečku už teď. O drtivou většinu věcí se stará Garbage collector, vy nemusíte většinou řešit vůbec nic. Pokud pracujete se soubory (StreamReader, StreamWriter) nebo s databázemi (SqlConnection), používejte blok using. Ten na těchto objektech automaticky zavolá Dispose, a to i v případě, že z using bloku jakkoliv vyskočíte (výjimka chycená mimo blok, goto, return atd.). Finalize je specialita VB.NET, jedná se o metodu, která se automaticky volá při zániku objektu (destruktor). Volat zvnějšku byste ji nikdy neměl, ony se v .NETu destruktory obecně moc nepoužívají, protože se volají bůhví kdy (až když se objekt ruší, což ale dělá GC a nedá se to moc ovlivnit). Místo nich je právě IDisposable, které umožňuje volat metodu Dispose v okamžiku, kdy přestáváte s objektem pracovat.

Co se týče paměti, GC si ji uvolňuje sám, když ji potřebuje, a moc si do toho kecat nenechá (můžete ho o to požádat zavoláním GC.Collect, ale tuhle metodu potřebují lidé pouze ve speciálních případech a nebo v případě, že píší jako prasata). Většinou platí, že se o to nemusíte starat. Jediné, kdy se o paměť starat musíte, jsou případy, kdy používáte COM objekty - ty musíte většinou uvolňovat explicitně.

Většině lidí se ze začátku nelíbí, že do .NETu nevidí - když píšete v C++, tak tam se naalokuje přesně tolik paměti, kolik chcete, a všechno si děláte sám a máte nad tím 100% kontrolu (což je v mnoha případech na škodu, protože to nemusíte vždy uhlídat). .NET si naalokuje daleko víc paměti, nechává si rezervu, a když mu paměť dojde, zavolá GC atd, prostě se o to stará sám. Mě to také ze začátku trochu vadilo (resp. ze začátku ne, ale až ve chvíli, kdy jsem do .NETu trochu víc proniknul, bál jsem se, jak je všechno pomalé). Ale jakmile jsem pořádně zjistil, jak to uvnitř funguje, tak už se bát přestávám.

Souhlasím až na dvě věci: První věc, Finalize, není specialita VB.NET, nýbrž VB.NETí implementace destruktoru podle CLI specifikace. Například C# má rovněž destruktor, mimořádně debilně pojmenovaný znakem ~. Druhá věc je, že metoda Dispose z rozhraní IDisposable nenahrazuje destruktor, nýbrž slouží výhradně k uvolnění Unmanaged zdrojů spravovaných danou instancí objektu. Pokud se implementuje IDisposable, měl by se zároveň implementovat i destruktor Finalize, ve kterém se uvolní Unmanaged zdroje pomocí zavolání Dispose metody. Význam Dispose metody je také v tom, že pokud již nepotřebujeme s objektem pracovat, můžeme Unmanaged zdroje explicitně uvolnit ihned (a tím zbytečně nezabírat systémové prostředky), aniž bychom čekali až se uráčí Garbage Collector...

děkuji za odpověd.

byl jsem zvyklý hlídat si paměť a když jsem se dozvěděl, že .Net má "něco" co se o to postará automaticky, hodil jsem piplání s pamětí za hlavu a užíval si programování.

Skončilo to tak, že jsem napsal "obří" aplikaci, která masivně pracuje s grafikou (coredll) a tam jsem narazil. Stačilo v aplikaci hodinku klikat a veškerá dostupná pamět zmizela (cca 30MB) a potom aplikace padla na outofmemory exception. Tak jsem se dostal poprvé trošku pod pokličku .netu a zjistil jsem, že obsahuje plno zajímavostí.

pokusem jsem dospěl ke konstrukci, která chová korektně v paměti:

Dim gr As Graphics = Nothing
Try
 gr = Graphics.FromImage("aa.bmp")
Catch ex As Exception
'todo
Finally
If Not gr Is Nothing Then gr.Dispose()
gr = Nothing
End Try

Ještě mě napadá obyčejný datový typ string. Četl jsem, že při každé modifikaci stringu, vznikne kopie v paměti a původní se nastaví ke smazání GC. GC se pouští občas, takže by se mohlo stát, že i tady bude problém s pamětí. Když nechci použít stringbuilder, jak se takového chování vyvarovat? Po použití nastavuji string proměnou na nothing (nebo bych měl na string.empty?), ale netuším jestli to je nějak prospěšné.