Seriële GC
Garbage collection verbetert de geheugenefficiëntie in Java door niet-verwezen objecten uit de hoop te verwijderen en ruimte te maken voor nieuw gemaakte objecten.
De virtuele Java-machine heeft acht soorten vuilnisophalers. Laten we ze allemaal in detail bekijken.
Seriële GC is de eenvoudigste GC-implementatie. Het is bedoeld voor kleine applicaties die draaien in single-threaded omgevingen. Alle garbage collection-gebeurtenissen worden achtereenvolgens op dezelfde thread uitgevoerd. Verdichting wordt uitgevoerd na elke afvalinzameling.
Het uitvoeren van de collector resulteert in een "wereldstop"-gebeurtenis, waarbij de hele toepassing wordt opgeschort. Aangezien de hele applicatie vastloopt tijdens het ophalen van afval, moet u hier in het echte leven geen gebruik van maken als u de vertragingen zo laag mogelijk wilt houden.
Het JVM-argument om de seriële vuilnisman te gebruiken is -XX:+UseSerialGC .
Parallelle GC
De parallelle garbage collector is ontworpen voor toepassingen met middelgrote tot grote datasets die draaien op hardware met meerdere threads of meerdere processors. Dit is de standaard GC-implementatie en wordt ook wel de doorvoercollector genoemd.
Verschillende draden zijn bestemd voor kleine afvalinzameling in de jonge generatie. De enige draad is bezig met de belangrijkste afvalinzameling in de oudere generatie.
Het uitvoeren van een parallelle GC zorgt er ook voor dat de wereld "stopt" en dat de applicatie vastloopt. Dit gedrag is geschikter voor een omgeving met meerdere threads waar veel taken moeten worden voltooid en lange pauzes acceptabel zijn, zoals bij het uitvoeren van een batchtaak.
Het JVM-argument om de parallelle afvalverzamelaar te gebruiken is -XX:+UseParallelGC .
CMS GC
Bij ons ook wel bekend als de low rest parallel picker .
Hier zijn voor een kleine afvalverzameling meerdere threads betrokken, dit gebeurt via hetzelfde algoritme als in de parallelle verzamelaar. De belangrijkste opschoning is multi-threaded, net als de oude parallelle GC, maar het CMS draait gelijktijdig met toepassingsprocessen om 'wereldstop'-gebeurtenissen te minimaliseren.
Hierdoor verbruikt het CMS-verzamelprogramma meer CPU dan andere verzamelprogramma's. Als u meer CPU kunt toewijzen om de prestaties te verbeteren, verdient een CMS de voorkeur boven een eenvoudige parallelle verzamelaar. De CMS GC comprimeert niet.
Het JVM-argument om de parallelle mark-sweep-garbagecollector te gebruiken is -XX:+UseConcMarkSweepGC .
G1 (Vuilnis eerst) GC
G1GC is bedacht als vervanging voor CMS en is ontwikkeld voor multithreaded toepassingen die worden gekenmerkt door grote heapgroottes (meer dan 4 GB). Het is parallel en competitief als een CMS, maar onder de motorkap werkt het heel anders dan de oude vuilnismannen.
Hoewel G1 ook op generatiebasis werkt, heeft het geen aparte ruimtes voor jongere en oudere generaties. In plaats daarvan is elke generatie een reeks regio's, waardoor flexibiliteit mogelijk is bij het veranderen van de grootte van de jongere generatie.
G1 splitst de heap op in een reeks gebieden van gelijke grootte (afhankelijk van de grootte van de heap) en scant deze in meerdere threads. Het gebied tijdens de uitvoering van het programma kan herhaaldelijk zowel oud als jong worden.
Nadat de opmaakfase is voltooid, weet G1 welke gebieden de meeste rommel bevatten. Als de gebruiker geïnteresseerd is in het minimaliseren van pauzes, kan G1 slechts enkele gebieden selecteren. Als de pauzetijd niet belangrijk is voor de gebruiker, of als de pauzetijdlimiet te hoog is ingesteld, zal G1 meer gebieden bestrijken.
Aangezien de G1 GC de regio's met de meeste afval identificeert en eerst de afvalinzameling op die regio's uitvoert, wordt dit "Garbage First" genoemd.
Naast de gebieden Eden, Survivors en Old Memory zijn er nog twee andere typen in G1GC.
- Gigantisch (enorm) - voor objecten van grote omvang (meer dan 50% van de hoopgrootte).
- Beschikbaar - Ongebruikte of niet-toegewezen ruimte.
Het JVM-argument om de G1-garbagecollector te gebruiken is -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah is een nieuwe GC die is uitgebracht als onderdeel van JDK 12. Het belangrijkste voordeel van Shenandoah ten opzichte van G1 is dat het grootste deel van de afvalinzamelingscyclus gelijktijdig met applicatiethreads wordt uitgevoerd. G1 kan heap-gebieden alleen evacueren wanneer de applicatie is onderbroken, terwijl Shenandoah objecten tegelijk met de applicatie verplaatst.
Shenandoah kan levende objecten comprimeren, afval opruimen en RAM vrijmaken bijna zodra er vrij geheugen is gevonden. Omdat dit allemaal tegelijkertijd gebeurt, zonder de applicatie te onderbreken, is Shenandoah CPU-intensiever.
ZGC
ZGC is een andere GC die is uitgebracht als onderdeel van JDK 11 en is verbeterd in JDK 12.
Het is bedoeld voor toepassingen die snelheid en lage latentie (pauzes van minder dan 10 ms) vereisen en/of een zeer grote heap (meerdere terabytes) gebruiken.
De belangrijkste doelen van ZGC zijn lage latentie, schaalbaarheid en gebruiksgemak. Om dit te doen, kan de Java-toepassing blijven draaien ondanks het feit dat er afval wordt opgehaald. ZGC geeft standaard ongebruikt geheugen vrij en geeft het terug aan het besturingssysteem.
De ZGC biedt dus een aanzienlijke verbetering ten opzichte van andere traditionele GC's door extreem lage dode tijden te bieden (meestal binnen 2 ms).
Het JVM-argument om de ZGC-garbagecollector te gebruiken is -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .