streamalism.org

1. Overzicht

In deze korte tutorial laten we de basis van verschillende JVM Garbage Collection (GC) implementaties. Daarnaast zullen we zien hoe u een bepaald type Garbage Collection in onze applicaties kunt inschakelen.

2. Korte introductie tot Garbage Collection

Van de naam, het lijkt erop Garbage Collection behandelt het vinden en verwijderen van afval uit het geheugen. In werkelijkheid Garbage Collection volgt elk object dat beschikbaar is in de JVM-heapruimte en verwijdert ongebruikte objecten.

In eenvoudige bewoordingen, GC werkt in twee eenvoudige stappen die bekend staan ​​als Mark en Sweep:

• Markeer - het is waar de garbage collector identificeert welke stukjes geheugen in gebruik zijn en welke niet
• Vegen - deze stap verwijdert objecten die zijn geïdentificeerd tijdens de "mark" -fase

Voordelen:

• Geen handmatige geheugentoewijzing / deallocation-verwerking omdat ongebruikte geheugenruimte automatisch wordt afgehandeld door GC
• Geen overhead van afhandeling Bungelende wijzer
• Automaat Geheugenlek beheer (GC op zichzelf kan de volledige proof-oplossing voor geheugenlekken niet garanderen, maar het zorgt voor een groot deel ervan)

Nadelen:

• Sinds JVM moet het maken / verwijderen van objectreferenties bijhouden, deze activiteit vereist meer CPU-kracht dan de originele applicatie. Het kan de prestaties beïnvloeden van verzoeken die veel geheugen vereisen
• Programmeurs hebben geen controle over de planning van de CPU-tijd die wordt besteed aan het vrijmaken van objecten die niet langer nodig zijn
• Het gebruik van sommige GC-implementaties kan ertoe leiden dat de applicatie onvoorspelbaar stopt
• Automatisch geheugenbeheer zal niet zo efficiënt zijn als de juiste handmatige geheugentoewijzing / -deallocatie

3. GC-implementaties

JVM heeft vier soorten GC implementaties:

• Seriële Garbage Collector
• Parallelle vuilnisman
• CMS Garbage Collector
• G1 Garbage Collector

3.1. Seriële Garbage Collector

Dit is de eenvoudigste GC-implementatie, omdat deze in feite met een enkele thread werkt. Als resultaat, dit GC implementatie bevriest alle applicatie-threads wanneer deze wordt uitgevoerd. Daarom is het geen goed idee om het te gebruiken in toepassingen met meerdere threads, zoals serveromgevingen.

Er was echter een uitstekend gesprek door Twitter ingenieurs bij QCon 2012 over de prestaties van Seriële Garbage Collector - wat een goede manier is om deze verzamelaar beter te begrijpen.

De Serial GC is de garbage collector bij uitstek voor de meeste toepassingen die geen korte pauzetijdvereisten hebben en op client-style machines draaien. In staat te stellen Seriële Garbage Collectorkunnen we het volgende argument gebruiken:

java -XX: + UseSerialGC -jar Application.java

3.2. Parallelle vuilnisman

Het is de standaard GC van de JVM en ook wel Throughput Collectors genoemd. in tegenstelling tot Seriële Garbage Collector, dit gebruikt meerdere threads voor het beheren van heapruimte. Maar het bevriest ook andere toepassingsthreads tijdens het uitvoeren GC.

Als we dit gebruiken GCkunnen we de maximale garbagecollection specificeren threads en pauzetijd, doorvoer en footprint (hoop grootte).

Het aantal garbage collector-threads kan worden beheerd met de opdrachtregeloptie -XX: ParallelGCThreads =.

Het maximale pauzetijddoel (kloof [in milliseconden] tussen twee GC) wordt gespecificeerd met de opdrachtregeloptie -XX: MaxGCPauseMillis =.

Het maximale doorvoerdoel (gemeten met betrekking tot de tijd besteed aan garbage collection versus de tijd besteed buiten garbage collection) wordt gespecificeerd door de opdrachtregeloptie -XX: GCTimeRatio =.

De maximale heap-footprint (de hoeveelheid heap-geheugen die een programma nodig heeft tijdens het draaien) wordt gespecificeerd met behulp van de optie -Xmx.

In staat te stellen Parallelle vuilnismankunnen we het volgende argument gebruiken:

java -XX: + UseParallelGC -jar Application.java

3.3. CMS Garbage Collector

De Gelijktijdige Mark Sweep (CMS) implementatie gebruikt meerdere garbage collector-threads voor garbage collection. Het is ontworpen voor applicaties die de voorkeur geven aan kortere garbage collection-pauzes, en die het zich kunnen veroorloven processorbronnen te delen met de garbage collector terwijl de applicatie wordt uitgevoerd.

Simpel gezegd, applicaties die dit type GC gebruiken, reageren gemiddeld langzamer, maar stoppen niet met reageren om garbage collection uit te voeren.

Een snel punt om op te merken is dat sinds dit GC is gelijktijdig, een aanroep van expliciete garbage collection zoals using Systeem.gc () terwijl het gelijktijdige proces werkt, zal resulteren in Storing / onderbreking van gelijktijdige modus.

Als meer dan 98% van de totale tijd in CMS garbage collection en minder dan 2% van de hoop wordt teruggewonnen, dan is een Onvoldoende geheugen fout wordt gegooid door de CMSverzamelaar. Indien nodig kan deze functie worden uitgeschakeld door de optie toe te voegen -XX: -GebruikGCOverheadLimit naar de opdrachtregel.

Deze verzamelaar heeft ook een modus die bekend staat als een incrementele modus, die wordt gedeprecieerd in Java SE 8 en mogelijk wordt verwijderd in een toekomstige grote release.

Om het CMS Garbage Collectorkunnen we de volgende vlag gebruiken:

java -XX: + UseParNewGC -jar Application.java

Vanaf Java 9 is de CMS-garbagecollector verouderd. Daarom drukt JVM een waarschuwingsbericht af als we het proberen te gebruiken:

>> java -XX: + UseConcMarkSweepGC --version Java HotSpot (TM) 64-bits server VM-waarschuwing: optie UseConcMarkSweepGC is verouderd in versie 9.0 en zal waarschijnlijk in een toekomstige release worden verwijderd. Java-versie "9.0.1"

Bovendien heeft Java 14 de CMS-ondersteuning volledig laten vallen:

>> java -XX: + UseConcMarkSweepGC --version OpenJDK 64-Bit Server VM waarschuwing: Negeer optie UseConcMarkSweepGC; ondersteuning is verwijderd in 14.0 openjdk 14 2020-03-17

3.4. G1 Garbage Collector

G1 (Garbage First) Garbage Collector is ontworpen voor toepassingen die worden uitgevoerd op machines met meerdere processors met een grote geheugenruimte. Het is beschikbaar sinds JDK7-update 4 en in latere releases.

G1 collector zal de CMS verzamelaar omdat het efficiënter is qua prestaties

In tegenstelling tot andere verzamelaars, G1 collector verdeelt de heap in een set heapregio's van gelijke grootte, elk een aaneengesloten reeks virtueel geheugen. Bij het uitvoeren van afvalinzamelingen, G1 toont een gelijktijdige globale markeringsfase (d.w.z. fase 1 bekend als Markering) om de levendigheid van objecten in de hoop te bepalen.

Nadat de markeringsfase is voltooid, G1 weet welke regio's grotendeels leeg zijn. Het verzamelt zich eerst in deze gebieden, wat meestal een aanzienlijke hoeveelheid vrije ruimte oplevert (d.w.z. fase 2 bekend als Vegen). Daarom wordt deze methode van garbagecollection Garbage-First genoemd.

Om het G1 Garbage Collectorkunnen we het volgende argument gebruiken:

java -XX: + UseG1GC -jar Application.java

3.5. Wijzigingen in Java 8

Java 8u20 heeft er nog een geïntroduceerd JVM parameter voor het verminderen van onnodig geheugengebruik door te veel exemplaren van hetzelfde te maken Draad. Dit optimaliseert het heap-geheugen door duplicaat te verwijderen Draad waarden tot een globale single char [] array.

Deze parameter kan worden ingeschakeld door toe te voegen -XX: + UseStringDeduplication als een JVM parameter.

4. Conclusie

In deze korte tutorial hebben we de verschillende JVM Garbage Collection implementaties en hun use cases.

Meer gedetailleerde documentatie is hier te vinden.