Az Objektumok új példányainak kódolása című cikkben a különféle módszerekről írtam Új Az objektumok példányai létrehozhatók. Az ellenkező probléma, az objektum eldobása, olyan, ami miatt nem kell aggódnia a VB.NET-ben. A .NET tartalmaz egy úgynevezett technológiát Szemetes (GC), amely általában a színfalak mögött mindent, csendben és hatékonyan gondoskodik. De alkalmanként, általában fájlfolyamok, SQL objektumok vagy grafikus (GDI +) objektumok használatakor (azaz menedzser nélküli források), előfordulhat, hogy át kell vennie az irányítást az objektumok saját kódjában való elhelyezéséhez.
Először is, néhány háttér
Csakúgy, mint a constructor (a Új kulcsszó) létrehoz egy új tárgy, a destructor egy módszer, amelyet akkor hívnak meg, amikor egy objektum megsemmisül. De van egy fogás. Azok a felhasználók, akik a .NET-et készítették, rájöttek, hogy ez egy recept a hibákra, ha két különböző kódrész valójában megsemmisít egy objektumot. Tehát a .NET GC valójában az irányítás alatt áll, és általában ez az egyetlen kód, amely elpusztíthatja az objektum példányát. A GC elpusztít egy objektumot, amikor úgy dönt, hogy korábban nem. Általában, miután egy objektum elhagyja a hatókört, az az
felszabadított a közös nyelv futási ideje (CLR) segítségével. A GC pusztít objektumokat, amikor a CLR-nek több szabad memóriára van szüksége. A lényeg tehát az, hogy nem tudja megjósolni, mikor a GC valóban megsemmisíti az objektumot.(Welllll... Ez igaz közel mindig. Hívhatsz GC.Collect és erőltesse a szemétgyűjtő ciklus, de a hatóságok általánosságban azt mondják, hogy ez a rossz ötlet és teljesen felesleges.)
Például, ha a kód létrehozott egy Vevő objektum, úgy tűnik, hogy ez a kód megsemmisíti újra.
Ügyfél = Semmi
De nem így van. (Az objektum Semmire állítását általában nevezzük, visszahivatkozási valójában ez csak azt jelenti, hogy a változót már nem társítják egy objektummal. Egy idő múlva a GC észreveszi, hogy az objektum megsemmisíthető.
Mellesleg a kezelt objektumokhoz ez egyáltalán nem szükséges. Bár egy objektum, mint például a gomb, diszpozíciós módszert kínál, nem szükséges azt használni, és kevés ember teszi. Például a Windows Forms összetevők hozzáadódnak a nevű tároló objektumhoz alkatrészek. Amikor bezár egy űrlapot, akkor a Dispose módszert automatikusan meghívják. Általában ennek csak azért kell aggódnia, ha nem kezelt objektumokat használ, és akkor is, ha optimalizálja a programot.
Az objektumok birtokában levő erőforrások felszabadításának ajánlott módja a Eldob módszer az objektumra (ha van ilyen), majd az objektumtól való levonás.
Vevő. Eldob() Ügyfél = Semmi
Mivel a GC el fogja pusztítani egy árva objektumot, függetlenül attól, hogy az objektumváltozót Nothing értékre állítja-e vagy sem, ez nem igazán szükséges.
Egy másik ajánlott módszer annak biztosítására, hogy az objektumok megsemmisüljenek, amikor már nincs rá szükség, az az objektumot használó kód beillesztése a használata Blokk. A blokk használata garantálja egy vagy több ilyen erőforrás megsemmisítését, amikor a kódod befejeződik velük.
A GDI + sorozatban a használata A blokkot gyakran használják ezen bosszantó grafikai objektumok kezelésére. Például ...
A myBrush mint LinearGradientBrush _ használata. = Új LinearGradientBrush (_. Nekem. ClientRectangle, _. Szín. Kék szín. Piros, _. LinearGradientMode. Vízszintes) <... tov k ...> Használat befejezése
t is használhatunk automatikusan ártalmatlanítják a blokk végének végrehajtásakor.
A memóriakezelés GC-megközelítése nagy változás a VB6-hoz képest. A COM objektumokat (amelyeket a VB6 használ) megsemmisítették, amikor a referenciák belső számlálója elérte a nullát. De túl könnyű volt hibázni, így a belső pult ki volt kapcsolva. (Mivel a memória le volt kötve, és nem volt más objektumok számára elérhető, amikor ez megtörtént, ezt "memóriaszivárgásnak" hívták.) Ehelyett a GC valóban ellenőrzi, hogy valami utal-e egy objektumra, és elpusztítja azt, amikor már nincs ilyen hivatkozásokat. A GC megközelítésnek jó története van olyan nyelveken, mint a Java, és a .NET egyik legnagyobb fejlesztése.
A következő oldalon áttekinti az IDSposable felületet... a felület, amelyet akkor kell használni, ha a saját kódjában nem kezelt objektumokat kell eldobnia.
Ha saját objektumát kódolja, amely nem kezelt erőforrásokat használ, akkor használja a IDisposable az objektum felülete. A Microsoft ezt megkönnyíti egy kódrészlet beiktatásával, amely megteremti az Ön számára megfelelő mintát.
Kattintson ide az ábra megjelenítéséhez
A visszatéréshez kattintson a böngésző Vissza gombjára
A hozzáadott kód így néz ki (VB.NET 2008):
Class ResourceClass. Azonnal felhasználható eszközök. - Az redundáns hívások észlelésére. Magántulajdonban van, mint logikai = hamis. „ID eldobható. Védett, túlságosan átható hulladéklerakó (_. ByVal boolean-ként ártalmatlanít.) Ha nem Me.megszerezte, akkor. Ha ártalmatlanít, akkor. 'Szabadítson más államot (kezelt objektumokat). Vége If. 'Szabadítsa meg saját államát (nem kezelt tárgyak). 'Állítsa a nagy mezőket nullra. Vége If. Me.disposed = Igaz. Befejezés Sub. #Region "IDisposable Support" 'Ezt a kódot a Visual Basic adta hozzá. 'helyesen hajtsa végre az eldobható mintát. Nyilvános hulladéklerakó () Azonosítható. Eldob. - Ne változtassa meg ezt a kódot. - Helyezze be a tisztító kódot. 'A fentiek szerint ártalmatlanítsa (ByVal mint Boolean). Ártalmatlanítsa (igaz) GC.SuppressFinalize (Me) End Sub. Protected Overrides Sub Finalize () 'Ne változtassa meg ezt a kódot. - Helyezze be a tisztító kódot. 'A fentiek szerint ártalmatlanítsa (ByVal mint Boolean). Ártalmatlanítsa (hamis) MyBase-t. Véglegesítés () Alfejezet vége #End régió. Végkategória
Eldob szinte egy "kényszerített" fejlesztői tervezési minta a .NET-ben. Valójában csak egy helyes módszer van erre, és ez az. Azt gondolhatja, hogy ez a kód valami varázslatos. Nem így van.
Először vegye figyelembe, hogy a belső zászló elhelyezve egyszerűen rövidre zárja az egész dolgot, hogy felhívhassa Ártalmatlanítás (ártalmatlanítás) olyan gyakran, ahogy tetszik.
A kód ...
GC.SuppressFinalize (Me)
... hatékonyabbá teszi a kódot azáltal, hogy elmondja a GC-nek, hogy az objektum már el lett helyezve (a végrehajtási ciklusok szempontjából "drága" művelet). A véglegesítés védett, mert a GC egy objektum megsemmisítésekor automatikusan meghívja. Soha ne hívja a Finalize-t. A logikai ártalmatlanítása megmutatja a kódot, hogy az Ön kódja kezdeményezte-e az objektum elidegenítését (True), vagy a GC megtette-e (a. részeként) Lezárás alatti. Vegye figyelembe, hogy az egyetlen kód, amely a logikai kódot használja ártalmatlanítása jelentése:
Ha ártalmatlanít, akkor. 'Szabadítson más államot (kezelt objektumokat). Vége If
Amikor eldob egy tárgyat, az összes erőforrást meg kell ártalmatlanítani. Amikor a CLR szemetes ha egy tárgyat ártalmatlanít, csak a nem kezelt erőforrásokat kell ártalmatlanítani, mivel a hulladékgyűjtő automatikusan gondoskodik a kezelt erőforrásokról.
Ennek a kódrészletnek az az ötlete, hogy kódot ad hozzá a kezelt és nem kezelt objektumok gondozásához a megadott helyeken.
Amikor egy osztályt származtat a alap osztály amely az IDisposable alkalmazást hajtja végre, akkor az alapvető módszerek egyikét sem kell felülbírálnia, kivéve ha egyéb erőforrásokat használ, amelyeket szintén meg kell ártani. Ha ez megtörténik, a származtatott osztálynak felül kell írnia az alap osztály Dispose (disposing) módszerét a származtatott osztály erőforrásainak kezelésére. De ne felejtsd el meghívni az alap osztály Dispose (disposing) módszerét.
Védett felülbírálja a hulladéklerakást (ByVal hulladékként logikai formában), ha nem Me. Ha ártalmatlanít, akkor. 'Adja hozzá a kódját az ingyenesen kezelt erőforrásokhoz. Vége If. 'Adja hozzá a kódját a nem kezelt erőforrások felszabadításához. Vége If. MyBase. Ártalmatlanítás (ártalmatlanítás) Befejezés Sub
A téma kissé túlnyomó lehet. Az itt található magyarázat célja a ténylegesen zajló események „demistifikálása”, mivel a legtöbb információ, amit megtalál, nem mondja meg neked!