Soros GC
A szemétgyűjtés javítja a memória hatékonyságát a Java-ban azáltal, hogy eltávolítja a nem hivatkozott objektumokat a kupacból, és helyet ad az újonnan létrehozott objektumok számára.
A Java virtuális gép nyolcféle szemétgyűjtővel rendelkezik. Tekintsük mindegyiket részletesen.
A soros GC a legegyszerűbb GC megvalósítás. Egyszálú környezetben futó kis alkalmazásokhoz készült. Minden szemétgyűjtési esemény egymás után fut ugyanabban a szálban. A tömörítést minden szemétgyűjtés után végezzük.

A gyűjtő futtatása "világleállás" eseményt eredményez, ahol a teljes alkalmazás felfüggesztésre kerül. Mivel a szemétszállítás során az egész alkalmazás lefagy, a való életben ne folyamodjon ehhez, ha a késéseket a lehető legkisebbre szeretné csökkenteni.
A soros szemétgyűjtő használatára vonatkozó JVM argumentum a -XX:+UseSerialGC .
Párhuzamos GC
A párhuzamos szemétgyűjtőt közepes és nagy adathalmazokkal rendelkező alkalmazásokhoz tervezték, amelyek többszálú vagy többprocesszoros hardveren futnak. Ez az alapértelmezett GC-megvalósítás, és áteresztőképesség-gyűjtőként is ismert.
Több szál kis szemétszállításra hivatott a fiatal generációban. Az egyetlen szál az idősebb generáció fő szemétszállításával van elfoglalva.

Egy párhuzamos GC futtatása a világ „leállását” is okozza, és az alkalmazás lefagy. Ez a viselkedés inkább megfelelő többszálú környezetben, ahol sok feladatot kell végrehajtani, és hosszú szünetek is elfogadhatók, például kötegelt feladat futtatásakor.
A párhuzamos szemétgyűjtő használatához szükséges JVM argumentum a -XX:+UseParallelGC .
CMS GC
Nálunk alacsony nyugalmi párhuzamos picker néven is ismert .
Itt egy kis szemétgyűjtésnél több szál is érintett, ez ugyanazon az algoritmuson keresztül történik, mint a párhuzamos gyűjtőben. A fő szemétgyűjtés többszálú, csakúgy, mint a régi párhuzamos GC, de a CMS az alkalmazási folyamatokkal párhuzamosan fut, hogy minimalizálja a "világmegállás" eseményeket.

Emiatt a CMS-gyűjtő több CPU-t fogyaszt, mint a többi gyűjtő. Ha több CPU-t tud lefoglalni a teljesítmény javítása érdekében, akkor a CMS jobb, mint egy egyszerű párhuzamos gyűjtő. A CMS GC nem tömörít.
A párhuzamos mark-sweep szemétgyűjtő használatára vonatkozó JVM argumentum a -XX:+UseConcMarkSweepGC .
G1 (Garbage first) GC
A G1GC a CMS helyettesítőjeként készült, és olyan többszálas alkalmazásokhoz lett kifejlesztve, amelyeket nagy kupacméret (4 GB-nál nagyobb) jellemez. Párhuzamos és versenyképes, mint egy CMS, de a motorháztető alatt egészen máshogy működik, mint a régi szemétgyűjtők.
Bár a G1 generációs alapon is működik, nem rendelkezik külön terekkel a fiatalabb és idősebb generációk számára. Ehelyett minden generáció régiók halmaza, amely rugalmasságot tesz lehetővé a fiatalabb generáció méretének megváltoztatásában.
A G1 felosztja a kupacot egyforma méretű régiókra (a kupac méretétől függően), és több szálra szkenneli őket. A terület a program végrehajtása során többször is öregedhet és fiatalodhat.
A jelölési fázis befejezése után a G1 tudja, mely területek tartalmazzák a legtöbb szemetet. Ha a felhasználót érdekli a szünetek minimalizálása, a G1 csak néhány területet tud kiválasztani. Ha a szünetidő nem fontos a felhasználó számára, vagy ha a szünet időkorlátja magasra van állítva, a G1 több területet fog át.
Mivel a G1 GC azonosítja azokat a régiókat, ahol a legtöbb szemét található, és először ezeken a területeken végzi el a szemétgyűjtést, ezt "Garbage First"-nek hívják.

Az Eden, Survivors és Old Memory területeken kívül két másik típus is található a G1GC-ben.
- Humongous (Huge) - nagy méretű tárgyakhoz (a kupac méretének több mint 50% -a).
- Elérhető – Fel nem használt vagy ki nem osztott terület.
A G1 szemétgyűjtő használatára vonatkozó JVM argumentum -XX:+UseG1GC .
Shenandoah (Shandara)
A Shenandoah egy új GC, amelyet a JDK 12 részeként adtak ki. A Shenandoah fő előnye a G1-gyel szemben, hogy a szemétgyűjtési ciklus nagy része az alkalmazásszálakkal párhuzamosan zajlik. A G1 csak akkor tudja kiüríteni a halomterületeket, amikor az alkalmazás fel van függesztve, míg a Shenandoah az alkalmazással egy időben mozgatja az objektumokat.
A Shenandoah képes tömöríteni az élő objektumokat, eltakarítani a szemetet és felszabadítani a RAM-ot szinte azonnal, amint szabad memória található. Mivel mindez egyszerre, az alkalmazás felfüggesztése nélkül történik, a Shenandoah CPU-igényesebb.
ZGC
A ZGC egy másik GC, amelyet a JDK 11 részeként adtak ki, és a JDK 12-ben továbbfejlesztettek.
Olyan alkalmazásokhoz készült, amelyek sebességet és alacsony késleltetést igényelnek (10 ms-nál rövidebb szünetek), és/vagy nagyon nagy kupacot (több terabájtot) használnak.
A ZGC fő céljai az alacsony késleltetés, a méretezhetőség és a könnyű használat. Ennek érdekében lehetővé teszi, hogy a Java alkalmazás továbbra is futhasson annak ellenére, hogy a szemétgyűjtési műveletek folyamatban vannak. Alapértelmezés szerint a ZGC felszabadítja a fel nem használt memóriát, és visszaadja az operációs rendszernek.
Így a ZGC jelentős javulást hoz a többi hagyományos GC-hez képest, mivel rendkívül alacsony holtidőt biztosít (általában 2 ms-on belül).

A ZGC szemétgyűjtő használatára vonatkozó JVM argumentum a következő: -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION