GC serial
Colectarea gunoiului îmbunătățește eficiența memoriei în Java prin eliminarea obiectelor nereferite din heap și făcând loc obiectelor nou create.
Mașina virtuală Java are opt tipuri de colectoare de gunoi. Să luăm în considerare fiecare dintre ele în detaliu.
Serial GC este cea mai simplă implementare GC. Este destinat aplicațiilor mici care rulează în medii cu un singur thread. Toate evenimentele de colectare a gunoiului sunt executate secvenţial pe acelaşi fir. Compactarea se efectuează după fiecare colectare a gunoiului.
Rularea colectorului are ca rezultat un eveniment de „oprire în lume”, în care întreaga aplicație este suspendată. Întrucât întreaga aplicație este înghețată în timpul colectării gunoiului, nu ar trebui să recurgeți la acest lucru în viața reală dacă doriți să mențineți întârzierile cât mai mici posibil.
Argumentul JVM pentru a utiliza colectorul de gunoi serial este -XX:+UseSerialGC .
GC paralel
Colectorul de gunoi paralel este proiectat pentru aplicații cu seturi de date medii până la mari care rulează pe hardware multiprocesor sau multiprocesor. Aceasta este implementarea GC implicită și este cunoscută și sub numele de colector de debit.
Mai multe fire sunt destinate micilor colectări de gunoi în tânăra generație. Singurul thread este ocupat cu colectarea principală a gunoiului din generația mai veche.
Rularea unui GC paralel face ca lumea să se „oprească” și aplicația se blochează. Acest comportament este mai potrivit pentru un mediu cu mai multe fire de execuție, unde multe sarcini trebuie finalizate și sunt acceptabile pauze lungi, cum ar fi atunci când rulează un job batch.
Argumentul JVM pentru a utiliza colectorul de gunoi paralel este -XX:+UseParallelGC .
CMS GC
De asemenea, cunoscut la noi sub denumirea de selecționer paralel în repaus scăzut .
Aici, pentru o mică colectare de gunoi, sunt implicate mai multe fire de execuție, acest lucru se întâmplă prin același algoritm ca în colectorul paralel. Colectarea principală a gunoiului este multi-threaded, la fel ca vechiul GC paralel, dar CMS rulează concomitent cu procesele de aplicație pentru a minimiza evenimentele de „oprire a lumii”.
Din acest motiv, colectorul CMS consumă mai mult CPU decât alți colectori. Dacă aveți capacitatea de a aloca mai mult CPU pentru a îmbunătăți performanța, atunci un CMS este de preferat unui simplu colector paralel. CMS GC nu compactează.
Argumentul JVM pentru a utiliza colectorul de gunoi paralel mark-sweep este -XX:+UseConcMarkSweepGC .
G1 (Gunoiul mai întâi) GC
G1GC a fost conceput ca un înlocuitor pentru CMS și a fost dezvoltat pentru aplicații cu mai multe fire care se caracterizează prin dimensiuni mari ale heap-ului (mai mare de 4 GB). Este paralel și competitiv ca un CMS, dar sub capotă funcționează foarte diferit față de vechile colectoare de gunoi.
Deși G1 funcționează și pe bază generațională, nu are spații separate pentru generațiile mai tinere și cele mai în vârstă. În schimb, fiecare generație este un set de regiuni, permițând flexibilitate în schimbarea mărimii generației mai tinere.
G1 împarte heap-ul într-un set de regiuni de dimensiuni egale (în funcție de dimensiunea heap-ului) și le scanează în mai multe fire. Zona în timpul execuției programului poate deveni în mod repetat atât bătrân cât și tânăr.
După finalizarea fazei de marcare, G1 știe care zone conțin cele mai multe deșeuri. Dacă utilizatorul este interesat să minimizeze pauzele, G1 poate selecta doar câteva zone. Dacă timpul de pauză nu este important pentru utilizator sau dacă limita de pauză este setată la mare, G1 va trece pe mai multe zone.
Deoarece G1 GC identifică regiunile cu cel mai mare gunoi și efectuează colectarea gunoiului mai întâi în acele regiuni, se numește „Garbage First”.
Pe lângă zonele Eden, Survivors și Old Memory, există alte două tipuri în G1GC.
- Humongous (Uriaș) - pentru obiecte de dimensiuni mari (mai mult de 50% din dimensiunea grămezilor).
- Disponibil - Spațiu neutilizat sau nealocat.
Argumentul JVM pentru a utiliza colectorul de gunoi G1 este -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah este un nou GC lansat ca parte a JDK 12. Avantajul cheie al Shenandoah față de G1 este că cea mai mare parte a ciclului de colectare a gunoiului se face concomitent cu firele de aplicare. G1 poate evacua zonele heap numai atunci când aplicația este suspendată, în timp ce Shenandoah mută obiecte în același timp cu aplicația.
Shenandoah poate compacta obiecte vii, curăța gunoiul și eliberează RAM aproape imediat ce este găsită memoria liberă. Deoarece toate acestea se întâmplă în același timp, fără a suspenda aplicația, Shenandoah consumă mai mult CPU.
ZGC
ZGC este un alt GC lansat ca parte a JDK 11 și îmbunătățit în JDK 12.
Este destinat aplicațiilor care necesită viteză și latență scăzută (pauze mai mici de 10 ms) și/sau utilizează un heap foarte mare (mai mulți terabytes).
Principalele obiective ale ZGC sunt latența scăzută, scalabilitatea și ușurința în utilizare. Pentru a face acest lucru, permite aplicației Java să continue să ruleze, în ciuda faptului că operațiunile de colectare a gunoiului sunt în desfășurare. În mod implicit, ZGC eliberează memoria nefolosită și o returnează sistemului de operare.
Astfel, ZGC aduce o îmbunătățire semnificativă față de alte GC-uri tradiționale, oferind timpi mort extrem de mici (de obicei în 2 ms).
Argumentul JVM pentru a utiliza colectorul de gunoi ZGC este -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION