Szemétgyűjtők típusai Java-ban

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.

JVM argumentum a Shenandoah szemétgyűjtő mellett: -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC .

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 .