A szabad társadalom memória kezelése java gyenge és puha referenciák

Szemétgyűjtő modern nyelvek célja, hogy enyhíti a programozó kapcsolatos aggodalmak memória kezelése. Ebben a tanulmányban Két esetet ellenőrzés automatikus memória felszabadítása.

Természetesen a valóság ennél sokkal bonyolultabb: a tárgyak vannak osztva generáció mechanizmust használnak „jelű kártyák” és mások. De a mi szempontunkból elég ez a fogalom:

Azok linkek jelennek meg a képet - a szokásos. Ezek kialakítva idején a hozzárendelése az objektum egy változó:

Egyes feladatok, ez a megközelítés tűnik túl rugalmatlan.

néha lehet, akkor van értelme, hogy mentse a tárgyat, még akkor is, ha a kapcsolat marad számára? Vagy fordítva -, hogy távolítsa el, még akkor is, ha ez elérhető a gyökér készletet? Vagy talán néhány tárgy van értelme, hogy elpusztítsa egyszerre, és valamilyen műveletet végeznek, mielőtt a pusztulástól?

1. feladat: a veszélyeztetett dobozokat

Megérkeztem a raktár fél doboz, és meg kell rendelni az egyes postafiók számát. Erre a seb hash táblát, amelyben a kulcsok - utalás a dobozok és az érték - számuk. Valami ehhez hasonló:

A felvételkor a raktárba, a doboz a táblázatba:

Ebben az esetben a probléma merül fel, amikor a szállítási dobozt a raktárból, a memória mennyiségét, mert nem szabadul fel, mert a hash tábla utalást tartalmaz a doboz és a virtuális gép azt hiszi, hogy „élő”.

Kérdés: Hogy tudom módosítani a hash táblát úgy, hogy a memória felszabadul szállítását követően a dobozban?

Egy lehetséges megoldás:

Ez a probléma - az egyik lehetőség elég gyakori probléma: ha az érték „átlagos” élettartama (azaz, él tovább, mint a módszer, amely memóriát, de kevesebb van benne, mint az alkalmazás), c tárgy kapcsolódó metaadatokat, és ez a kapcsolat tárolja a szótárban. Ennek eredményeként egyes harmadik tárgya szükséges egy bizonyos ponton, hogy tiszta a nem kívánt bejegyzéseket a szótárban. Ha ez a harmadik tárgya véletlenül elfelejti, hogy tisztítsa meg a szótárban, memóriavesztés történik.

Jó lenne, ha a bejegyzések ebben a szótárban, nem veszik figyelembe kiszámításakor elérhetőség a tárgy - azaz, ha a szemétgyűjtő elpusztítják tárgyak mezőbe. amikor rá mutató hivatkozás csak a szótárban.

Gyenge kapcsolatok jönnek létre, mint ez:

Abban az esetben, boxRef tárgy marad az egyetlen élő kapocs a tárgy mezőbe. doboz objektum el lesz távolítva a szemétgyűjtő:

Visszatérve a példa: ha bejegyzéseket a hash jel tárgy „box” class hogy lezárja egy gyenge láncszem, akkor oldja meg a problémát, memóriavesztés. Azonban ez létre fog hozni egy másik probléma: foglalkozni a hash jel, írjuk be a rekordot, amely váratlanul alkalmazni a null - tevékenysége nem a legkellemesebb. Éppen ezért a mi címke legyen elég okos ahhoz, hogy törölje a bejegyzést magát, amint a tárgyat eltávolítják, hogy hivatkozik gombot.

Végrehajtása egy ilyen tábla - ez nagyon érdekes, de egy kicsit túlmutat ezt a cikket. Az általunk használt standard osztályú WeakHashMap. Az egyik lehetséges megvalósítási megtalálható az Apache Harmony aki belépett, mint egy osztály könyvtár Android.

2. célkitűzés: a helyes utat OutOfMemoryError

Tudni kell konvertálni pár (száz? Ezer?) Kép. Ehhez, akkor itt a következő kódot:

Az ötlet a pre-puffert kiosztani a fájl normálisnak tűnik: memória kiosztás minden egyes új képet lelassíthatja az alkalmazást. Azonban egy új probléma merül fel: mi van, ha az alkalmazás memóriája kevés? Ezután, talán, ésszerű, hogy elhanyagolja a puffert és visszatérni a memória rendszer.

K: Hogyan tudom módosítani a kódot úgy, hogy az alkalmazás tárolja a puffer van elég memória és kiszabadította, ha a memóriát a rendszer véget ér?

Egy lehetséges megoldás

Itt kell, hogy végezzen az ellenkező viselkedése gyenge kapcsolatok. Azt akarjuk, hogy a szemétgyűjtő, jelezve, hogy egy bizonyos típusú objektumokat, hogy a memóriában, amíg csak lehetséges, anélkül, hogy OutOfMemoryError.

Ezt úgy lehet elérni, a „soft linkek”. Úgy működik, mint a következő: ha egy tárgy keresztül érhető el egy szett lágy kapcsolatok ( „. Myagkodostizhim» lágyan elérhető, lásd a képen), a virtuális gép megpróbálja tartani ezt az objektumot a memóriában, amíg csak lehetséges.

Minden, ami szükséges a mi feladatunk -, hogy lezárja a lágy puffer link.

Így puha linkeken egyfajta cache-t. De ez, persze, jelenleg nem cache-t. Ha az alkalmazás nem egy teljes cache, majd az egyik csak szimbolikus hivatkozások kicsi, végre kell hajtani caching stratégiák lehető függetlenül a szabad memória mennyisége. Ezért szimbolikus hivatkozások néha „caching a szegények.”