In Java is geheugenbeheer het proces van toewijzing en verwijdering van objecten, ook wel geheugenbeheer genoemd. Java doet automatisch geheugenbeheer. Java maakt gebruik van een automatisch geheugenbeheersysteem genaamd a vuilnisman . We zijn dus niet verplicht om geheugenbeheerlogica in onze applicatie te implementeren. Java-geheugenbeheer bestaat uit twee hoofdonderdelen:

JVM-geheugenstructuur Werking van de vuilnisman

JVM-geheugenstructuur

JVM creëert verschillende runtime-gegevensgebieden op een hoop. Deze gebieden worden gebruikt tijdens de uitvoering van het programma. De geheugengebieden worden vernietigd wanneer JVM wordt afgesloten, terwijl de gegevensgebieden worden vernietigd wanneer de thread wordt afgesloten.

Methodegebied

Method Area is een deel van het heapgeheugen dat door alle threads wordt gedeeld. Het wordt gemaakt wanneer de JVM opstart. Het wordt gebruikt om de klassenstructuur, superklassenaam, interfacenaam en constructors op te slaan. De JVM slaat de volgende soorten informatie op in het methodegebied:

• Een volledig gekwalificeerde naam van een type (bijvoorbeeld: String)
• De modifiers van het type
• De directe superklassenaam van het type
• Een gestructureerde lijst met de volledig gekwalificeerde namen van superinterfaces.

Hoopgebied

Heap slaat de werkelijke objecten op. Het wordt gemaakt wanneer de JVM opstart. De gebruiker kan de heap indien nodig beheren. Het kan een vaste of dynamische grootte hebben. Wanneer u een nieuw trefwoord gebruikt, maakt de JVM een exemplaar voor het object in een heap. Terwijl de referentie van dat object in de stapel wordt opgeslagen. Er bestaat slechts één heap voor elk actief JVM-proces. Wanneer de hoop vol raakt, wordt het afval verzameld. Bijvoorbeeld:

 StringBuilder sb= new StringBuilder(); 

Met de bovenstaande instructie wordt een object van de klasse StringBuilder gemaakt. Het object wordt toegewezen aan de heap en de referentie sb wordt toegewezen aan de stapel. Heap is verdeeld in de volgende delen:

• Jonge generatie
• Overlevende ruimte
• Oude generatie
• Permanente generatie
• Codecache

Referentietype

Er zijn vier soorten verwijzingen: Sterk , Zwak , Zacht , En Fantoomreferentie . Het verschil tussen de typen referenties is dat de objecten op de hoop waarnaar ze verwijzen, op grond van de verschillende criteria in aanmerking komen voor afvalinzameling.

Sterke referentie: Het is heel eenvoudig omdat we het gebruiken in onze dagelijkse programmering. Elk object waaraan een sterke referentie is gekoppeld, komt niet in aanmerking voor afvalinzameling. We kunnen een sterke referentie creëren door de volgende verklaring te gebruiken:

de string omkeren in Java

 StringBuilder sb= new StringBuilder(); 

Zwakke referentie: Het overleeft niet na het volgende afvalinzamelingsproces. Indien wij niet zeker weten wanneer de gegevens opnieuw worden opgevraagd. In deze toestand kunnen we er een zwakke verwijzing naar maken. In het geval dat de garbage collector het object vernietigt. Wanneer we opnieuw proberen dat object op te halen, krijgen we een nulwaarde. Het is gedefinieerd in java.lang.ref.WeakReference klas. We kunnen een zwakke referentie maken door de volgende verklaring te gebruiken:

 WeakReference reference = new WeakReference(new StringBuilder()); 

Zachte referentie: Het wordt verzameld wanneer de applicatie weinig geheugen heeft. De afvalverzamelaar verzamelt de zacht bereikbare voorwerpen niet. Alle zachte referentieobjecten worden verzameld voordat er een OutOfMemoryError wordt gegenereerd. We kunnen een zachte referentie maken door de volgende verklaring te gebruiken:

 SoftReference reference = new SoftReference(new StringBuilder()); 

Fantoomreferentie: Het is verkrijgbaar binnen java.lang.ref pakket. Het is gedefinieerd in java.lang.ref.PhantomReference klas. Het object dat alleen een fantoomreferentie heeft die ernaar wijst, kan worden verzameld wanneer de garbage collector dat wil. We kunnen een fantoomreferentie maken door de volgende instructie te gebruiken:

 PhantomReference reference = new PhantomReference(new StringBuilder()); 

Stapelgebied

Stack Area wordt gegenereerd wanneer er een thread wordt gemaakt. Het kan een vaste of dynamische grootte hebben. Het stapelgeheugen wordt per thread toegewezen. Het wordt gebruikt om gegevens en gedeeltelijke resultaten op te slaan. Het bevat verwijzingen naar heap-objecten. Het bevat ook de waarde zelf in plaats van een verwijzing naar een object uit de heap. De variabelen die in de stapel zijn opgeslagen, hebben een bepaalde zichtbaarheid, genaamd scope.

Stapelframe: Stackframe is een datastructuur die de gegevens van de thread bevat. Thread-gegevens vertegenwoordigen de status van de thread in de huidige methode.

• Het wordt gebruikt om gedeeltelijke resultaten en gegevens op te slaan. Het voert ook dynamische koppelingen uit, retourneert waarden door methoden en verzenduitzonderingen.
• Wanneer een methode wordt aangeroepen, wordt er een nieuw frame gemaakt. Het vernietigt het frame wanneer de aanroep van de methode is voltooid.
• Elk frame bevat een eigen Local Variable Array (LVA), Operand Stack (OS) en Frame Data (FD).
• De grootten van LVA, OS en FD bepaald tijdens het compileren.
• Slechts één frame (het frame voor de uitvoeringsmethode) is actief op elk punt in een gegeven controlethread. Dit frame wordt het huidige frame genoemd en de methode ervan staat bekend als de huidige methode. De klasse van de methode wordt de huidige klasse genoemd.
• Het frame stopt de huidige methode als de methode een andere methode aanroept of als de methode wordt voltooid.
• Het frame dat door een thread wordt gemaakt, is lokaal voor die thread en er kan door geen enkele andere thread naar worden verwezen.

Native Method Stack

Het is ook bekend als C-stack. Het is een stapel voor native code geschreven in een andere taal dan Java. Java Native Interface (JNI) roept de native stack aan. De prestaties van de native stack zijn afhankelijk van het besturingssysteem.

PC-registraties

Aan elke thread is een programmateller (PC)-register gekoppeld. PC-register slaat het retouradres of een native pointer op. Het bevat ook het adres van de JVM-instructies die momenteel worden uitgevoerd.

Werkzaamheden van een vuilnisman

Overzicht afvalverzamelaar

Wanneer een programma in Java wordt uitgevoerd, gebruikt het geheugen op verschillende manieren. De hoop is een deel van het geheugen waarin objecten leven. Het is het enige deel van het geheugen dat betrokken is bij het afvalinzamelingsproces. Het wordt ook wel een verzamelbare afvalhoop genoemd. Alle afvalinzameling zorgt ervoor dat de hoop zoveel mogelijk vrije ruimte heeft. De functie van de garbage collector is het vinden en verwijderen van de objecten die niet kunnen worden bereikt.

string java-indexof

Objecttoewijzing

Wanneer een object wordt toegewezen, controleert de JRockit JVM de grootte van het object. Er wordt onderscheid gemaakt tussen kleine en grote objecten. Het kleine en grote formaat is afhankelijk van de JVM-versie, de heapgrootte, de strategie voor het verzamelen van afval en het gebruikte platform. De grootte van een object ligt doorgaans tussen 2 en 128 KB.

De kleine objecten worden opgeslagen in Thread Local Area (TLA), een vrij deel van de heap. TLA synchroniseert niet met andere threads. Wanneer de TLA vol raakt, wordt er om een ​​nieuwe TLA gevraagd.

Aan de andere kant worden grote objecten die niet in de TLA passen, direct in de heap geplaatst. Als een thread de jonge ruimte gebruikt, wordt deze direct in de oude ruimte opgeslagen. Het grote object vereist meer synchronisatie tussen de threads.

Wat doet Java Garbage Collector?

JVM bestuurt de garbage collector. JVM beslist wanneer de garbagecollection moet worden uitgevoerd. We kunnen ook een verzoek indienen bij de JVM om de garbage collector uit te voeren. Maar er is onder geen enkele voorwaarde garantie dat de JVM hieraan zal voldoen. JVM voert de garbage collector uit als het merkt dat het geheugen bijna leeg is. Wanneer een Java-programma om de garbage collector vraagt, willigt de JVM het verzoek meestal op korte termijn in. Het zorgt er niet voor dat de verzoeken worden geaccepteerd.

Het punt om te begrijpen is dat ' wanneer een object in aanmerking komt voor garbagecollection? '

Elk Java-programma heeft meer dan één thread. Elke thread heeft zijn uitvoeringsstapel. Er is een thread die in het Java-programma kan worden uitgevoerd en die een main() -methode is. Nu kunnen we zeggen dat een object in aanmerking komt voor garbagecollection als er geen live thread toegang toe heeft. De vuilnisophaler beschouwt dat object als in aanmerking komend voor verwijdering. Als een programma een referentievariabele heeft die naar een object verwijst, die referentievariabele beschikbaar is voor live thread, wordt dit object aangeroepen bereikbaar .

Hier rijst de vraag dat ' Kan een Java-applicatie onvoldoende geheugen hebben? '

statisch in c

Het antwoord is ja. Het garbage collection-systeem probeert objecten uit het geheugen te verwijderen wanneer ze niet in gebruik zijn. Als u echter veel live-objecten onderhoudt, garandeert garbagecollection niet dat er voldoende geheugen is. Alleen het beschikbare geheugen wordt effectief beheerd.

Soorten afvalinzameling

Er zijn vijf soorten afvalinzameling:

Seriële GC:Het maakt gebruik van de mark-and-sweeps-benadering voor jonge en oude generaties, namelijk kleine en grote GC.Parallelle GC:Het is vergelijkbaar met seriële GC, behalve dat het N (het aantal CPU-kernen in het systeem) threads voortbrengt voor het verzamelen van afval van de jonge generatie.Parallelle oude GC:Het is vergelijkbaar met parallelle GC, behalve dat het voor beide generaties meerdere threads gebruikt.Gelijktijdige Mark Sweep (CMS)-collector:Het doet de afvalinzameling voor de oude generatie. U kunt het aantal threads in de CMS-verzamelaar beperken met behulp van XX:ParalleCMMSThreads=JVM-optie . Het is ook bekend als Concurrent Low Pause Collector.G1 afvalverzamelaar:Het werd geïntroduceerd in Java 7. Het doel is om de CMS-verzamelaar te vervangen. Het is een parallelle, gelijktijdige en CMS-verzamelaar. Er is geen ruimte voor jonge en oude generaties. Het verdeelt de hoop in meerdere even grote hopen. Het verzamelt eerst de regio's met minder live gegevens.

Markeer en veeg algoritme

JRockit JVM gebruikt het mark- en sweep-algoritme voor het uitvoeren van de garbage collection. Het bevat twee fasen, de markeerfase en de sweepfase.

Markeer fase: Objecten die toegankelijk zijn via de threads, systeemeigen handvatten en andere GC-hoofdbronnen worden gemarkeerd als live. Elke objectboom heeft meer dan één hoofdobject. GC root is altijd bereikbaar. Dus elk object dat een garbage collection root in de root heeft. Het identificeert en markeert alle objecten die in gebruik zijn, en de overige kunnen als afval worden beschouwd.

Sweep-fase: In deze fase wordt de hoop doorkruist om de opening tussen de levende objecten te vinden. Deze hiaten worden vastgelegd in de vrije lijst en zijn beschikbaar voor nieuwe objecttoewijzing.

Er zijn twee verbeterde versies van mark en sweep:

Gelijktijdig markeren en vegen Parallelle Markering en Sweep

Gelijktijdig markeren en vegen

Hierdoor kunnen de threads blijven draaien tijdens een groot deel van de garbagecollection. Er zijn de volgende soorten markering:

Initiële markering:Het identificeert de rootset van levende objecten. Dit gebeurt terwijl threads zijn gepauzeerd.Gelijktijdige markering:Bij deze markering wordt de referentie uit de rootset gevolgd. Het vindt en markeert de rest van de levende objecten op een hoop. Het wordt gedaan terwijl de draad loopt.Markering voorreiniging:Het identificeert de wijzigingen die zijn aangebracht door gelijktijdige markering. Andere levende objecten gemarkeerd en gevonden. Het wordt gedaan terwijl de threads actief zijn.Eindmarkering:Het identificeert de wijzigingen die zijn aangebracht door de markering voor het reinigen. Andere levende objecten gemarkeerd en gevonden. Dit gebeurt terwijl threads zijn gepauzeerd.

Parallelle Markering en Sweep

Het gebruikt alle beschikbare CPU's in het systeem om de garbage collection zo snel mogelijk uit te voeren. Het wordt ook wel de parallelle afvalverzamelaar genoemd. Threads worden niet uitgevoerd wanneer de parallelle garbagecollection wordt uitgevoerd.

cache npm wissen

Voordelen van Mark en Sweep

• Het is een terugkerend proces.
• Het is een oneindige lus.
• Er zijn geen extra overheadkosten toegestaan ​​tijdens de uitvoering van een algoritme.

Nadelen van Mark en Sweep

• Het stopt de normale uitvoering van het programma terwijl het algoritme voor het verzamelen van afval wordt uitgevoerd.
• Het draait meerdere keren op een programma.