Meer over de vuilnisman

Hoi! In de laatste les maakten we voor het eerst kennis met Java's ingebouwde afvalverzamelaar en kregen we een globaal idee van hoe het werkt. Het werkt op de achtergrond terwijl uw programma wordt uitgevoerd en verzamelt onnodige objecten die later worden verwijderd. Zo maakt het geheugen vrij dat kan worden gebruikt om in de toekomst nieuwe objecten te maken. In deze les gaan we dieper in op hoe het werkt. Hoe en wanneer wordt een object bijvoorbeeld overbodig? En hoe komt de vuilnisman daar achter? Dit zijn vragen die we tijdens de les van vandaag zullen beantwoorden :) De les zal meer een overzicht zijn: je hoeft deze stof niet uit je hoofd te leren. De bedoeling is vooral om je visie te verruimen over hoe het geheugen en de vuilnisman werken, dus lees gewoon door en vind iets nieuws voor jezelf :) Aan de slag! Het eerste dat u moet onthouden, is dat de vuilnisman parallel met uw programma werkt. Het maakt geen deel uit van je programma. Hij werkt apart (in de vorige les vergeleken we dit met een robotstofzuiger) Maar dat was niet altijd zo. Garbage collection werd vroeger uitgevoerd op dezelfde thread als je programma. Volgens een bepaald schema (eens in de paar minuten) zou de vuilnisman controleren op de aanwezigheid van ongewenste objecten in het programma. Het probleem was dat het programma zou blijven hangen (niet uitvoeren) tijdens deze controle en afvalinzameling. Stel je voor dat je op je werk in je kantoor zit. Maar dan komt de schoonmaakster binnen om de vloeren te wassen. Ze jaagt je 5 minuten weg van je computer en jij wacht tot ze klaar is met schoonmaken. Gedurende deze tijd kunt u niet werken. Dat is ongeveer hoe vuilnisophaaldienst vroeger werkte :) Dit mechanisme is later gewijzigd en nu draait de vuilnisophaaldienst op de achtergrond, het werk van het programma zelf niet belemmeren. Je weet al dat een object sterft als het geen referenties meer heeft. In werkelijkheid,de vuilnisman telt geen objectreferenties . Ten eerste kan dit lang duren. Ten tweede is het niet erg effectief. Objecten kunnen immers naar elkaar verwijzen! De figuur toont een voorbeeld waarbij 3 objecten naar elkaar verwijzen, maar niemand anders verwijst ernaar. Met andere woorden, de rest van het programma heeft ze niet nodig. Als de vuilnisman alleen de referenties zou tellen, zouden deze 3 objecten niet worden verzameld en zou het geheugen niet worden vrijgegeven (er zijn verwijzingen naar!). We kunnen dit vergelijken met een ruimtevaartuig. Tijdens de vlucht besluiten de astronauten de lijst met reserveonderdelen die beschikbaar zijn voor reparatie te controleren. Ze vinden onder meer een stuur en pedalen uit een gewone auto. Het is duidelijk dat ze hier niet nodig zijn en onnodig ruimte innemen (hoewel deze twee delen aan elkaar gerelateerd zijn en enkele functies hebben). Maar in het ruimtevaartuig zijn ze nutteloos afval dat moet worden weggegooid. Dienovereenkomstig werd in Java de beslissing genomen om afval in te zamelen, niet op basis van referentietellingen,bereikbaar en onbereikbaar . Hoe bepalen we of een object bereikbaar is? Het is allemaal gewoonweg ingenieus. Een object is bereikbaar als ernaar wordt verwezen door een ander bereikbaar object. Zo krijgen we een "keten van bereikbaarheid". Het begint wanneer het programma start en gaat door voor de duur van het programma. Het ziet er ongeveer zo uit: De pijl in de afbeelding geeft de uitvoerbare code van ons programma aan. De code (bijvoorbeeld de main()methode) maakt verwijzingen naar objecten. Deze objecten kunnen verwijzen naar andere objecten, die objecten naar weer andere, enzovoort. Dit vormt een referentieketen. Als u een keten kunt volgen van een object naar de "rootreferentie" (degene die rechtstreeks in uitvoerbare code is gemaakt), wordt deze als bereikbaar beschouwd. Dergelijke objecten zijn op de afbeelding zwart gemarkeerd. Maar een object is onbereikbaar als het uit deze keten valt, dwz geen van de variabelen in de code die op dat moment wordt uitgevoerd, verwijst ernaar, en het kan niet worden bereikt via de "referentieketen". In ons programma zijn twee van dergelijke objecten rood gemarkeerd. Merk op dat deze "rode" objecten naar elkaar verwijzen. Maar zoals we al eerder zeiden, de moderne vuilnisman van Java telt geen referenties. Het bepaalt of een object bereikbaar of onbereikbaar is. Als gevolg hiervan zal het de twee rode objecten in de figuur grijpen. Laten we nu het hele proces van begin tot eind bekijken. Daarbij zullen we ook zien hoe het geheugen in Java is gerangschikt :) Alle Java-objecten worden opgeslagen in een speciaal geheugengebied dat de heap wordt genoemd . In alledaagse taal is een hoop meestal een berg items, waar alles door elkaar loopt. Maar dat is niet wat de heap is in Java. De structuur is zeer logisch en redelijk. Op een gegeven moment ontdekten Java-programmeurs dat al hun objecten in twee typen konden worden verdeeld: eenvoudige objecten en "objecten met een lange levensduur".. "Langlevende objecten" zijn objecten die vele rondes van afvalinzameling hebben overleefd. Ze leven meestal tot het einde van het programma. Uiteindelijk is de hele berg, waar alle objecten zijn opgeslagen, opgedeeld in verschillende delen. Het eerste deel heeft een mooie naam: eden(uit de bijbelse "Garden of Eden"). Deze naam is passend, want hier komen objecten terecht nadat ze zijn gemaakt. Dit is het deel van het geheugen waar nieuwe objecten worden gemaakt als we het sleutelwoord nieuw gebruiken. Er kunnen veel objecten worden gemaakt. Wanneer dit gebied geen ruimte meer heeft, begint een eerste "snelle" afvalinzameling. We moeten zeggen dat de vuilnisman erg slim is. Het kiest een algoritme op basis van het feit of de hoop meer afval of meer levende objecten heeft. Als bijna alle objecten afval zijn, markeert de verzamelaar de levende objecten en verplaatst ze naar een ander geheugengebied. Dan is het huidige gebied volledig leeggemaakt. Als er niet veel afval is en de hoop voornamelijk uit levende voorwerpen bestaat, markeert de ophaler het afval, ruimt het op en pakt de andere voorwerpen bij elkaar. We zeiden "een overlevingsruimte . Een overlevingsruimte is op zijn beurt verdeeld in generaties . Elk object behoort tot een bepaalde generatie, afhankelijk van het aantal rondes van afvalinzameling dat het heeft overleefd. Als een object één ophaalronde heeft overleefd, bevindt het zich in "Generatie 1"; indien 5, dan "Generatie 5". Eden en een overlevingsruimte vormen samen een gebied dat de jonge generatie wordt genoemd . Naast de jonge generatie heeft de hoop nog een geheugengebied dat de oude generatie wordt genoemd. Dit is precies het gebied waar langlevende voorwerpen terechtkomen die vele rondes van afvalinzameling hebben overleefd. Het heeft voordelen om ze gescheiden te houden van alle andere. Volledige opschoning wordt alleen uitgevoerd als de oude generatie vol is, dwz er zijn zoveel objecten met een lange levensduur in het programma dat er onvoldoende geheugen is. Dit proces omvat meer dan één geheugengebied. Over het algemeen gaat het om alle objecten die door de Java-machine zijn gemaakt. Dit kost natuurlijk veel meer tijd en middelen. Dit is precies de beslissing die is genomen om langlevende objecten apart op te slaan. "Snelle afvalinzameling" wordt uitgevoerd wanneer andere gebieden onvoldoende ruimte hebben. Dit betreft slechts één gebied, wat het sneller en efficiënter maakt. Eindelijk, wanneer zelfs het gebied voor objecten met een lange levensduur volledig is gevuld, volledige afvalinzameling wordt geactiveerd. De verzamelaar gebruikt dus alleen het "zwaarste" gereedschap als het onmogelijk is om het te vermijden. Hier is een visuele weergave van de heapstructuur en de afvalinzameling: