JVM szemétgyűjtők

1. Áttekintés

Ebben a gyors bemutatóban bemutatjuk a különböző alapjait JVM Garbage Collection (GC) megvalósítások. Ezenkívül megtudjuk, hogyan lehet engedélyezni egy adott típusú szemétgyűjtést az alkalmazásainkban.

2. A szemétszedés rövid bemutatása

A név alapján úgy néz ki Szemétgyüjtés a szemét megkeresésével és törlésével foglalkozik a memóriából. A valóságban azonban Szemétgyüjtés nyomon követi a JVM halomterületén elérhető minden egyes objektumot, és eltávolítja a fel nem használtakat.

Egyszerű szavakkal: GC két egyszerű lépésben működik, amelyek Mark és Sweep néven ismertek:

  • Mark - itt azonosítja a szemétgyűjtő, hogy mely memóriadarabok vannak használatban, és melyek nem
  • Söprés - ez a lépés eltávolítja a „jelölés” szakaszban azonosított objektumokat

Előnyök:

  • Nincs kézi memória-allokáció / deallocation kezelés, mert a fel nem használt memóriaterületet automatikusan kezeli GC
  • Nincs kezelési költség Lógó mutató
  • Automatikus Memóriaszivárgás menedzsment (GC önmagában nem garantálja a memória szivárgásának teljes bizonyítékú megoldását, ennek jó részéről azonban gondoskodik)

Hátrányok:

  • Mivel JVM nyomon kell követnie az objektum-referencia létrehozását / törlését, ez a tevékenység az eredeti alkalmazás mellett több CPU-energiát igényel. Hatással lehet a nagy memóriát igénylő kérelmek teljesítésére
  • A programozók nem tudják ellenőrizni a már nem szükséges objektumok felszabadítására szánt CPU-idő ütemezését
  • Egyes GC implementációk használata kiszámíthatatlan leállást eredményezhet
  • Az automatizált memóriakezelés nem lesz olyan hatékony, mint a megfelelő kézi memória-allokáció / -allokáció

3. GC megvalósítások

A JVM-nek négy típusa van GC megvalósítások:

  • Soros szemétgyűjtő
  • Párhuzamos szemétgyűjtő
  • CMS szemétgyűjtő
  • G1 szemétgyűjtő

3.1. Soros szemétgyűjtő

Ez a legegyszerűbb GC megvalósítás, mivel alapvetően egyetlen szálon működik. Ennek eredményeként ez GC a megvalósítás fagyasztja az összes alkalmazásszálat. Ezért nem célszerű többszálú alkalmazásokban, például szerverkörnyezetben használni.

Kiváló beszéde volt azonban Twitter mérnökök a QCon 2012-en a Soros szemétgyűjtő - ami jó módszer ennek a gyűjtőnek a jobb megértésére.

A Serial GC a szemétgyűjtő a legtöbb alkalmazás számára, amelyek nem rendelkeznek kis szünetidővel és kliens stílusú gépeken futnak. Engedélyezni Soros szemétgyűjtő, a következő érvet használhatjuk:

java -XX: + UseSerialGC -jar Application.java

3.2. Párhuzamos szemétgyűjtő

Ez az alapértelmezett GC a JVM és néha Átbocsátás-gyűjtőknek hívják. nem úgy mint Soros szemétgyűjtő, ezt több szálat használ a halomterület kezeléséhez. De lefagy más alkalmazásszálakat is előadás közben GC.

Ha ezt használjuk GC, megadhatjuk a maximális szemétszállítást szálak és szünetidő, áteresztőképesség és lábnyom (kupacméret).

A szemétgyűjtő szálak száma a parancssori opcióval szabályozható -XX: ParallelGCThreads =.

A maximális szünetidő cél (kettő közötti különbség [ezredmásodpercekben]) GC) a parancssori opcióval van megadva -XX: MaxGCPauseMillis =.

A maximális átviteli célt (a szemétgyűjtéshez és a szemétszállításon kívül töltött időhöz viszonyítva) a parancssori opció határozza meg -XX: GCTimeRatio =.

Az opcióval megadható a halom maximális lábnyoma (a halom memória mennyisége, amelyre a program futás közben szükséges) -Xmx.

Engedélyezni Párhuzamos szemétgyűjtő, a következő érvet használhatjuk:

java -XX: + UseParallelGC -jar Application.java

3.3. CMS szemétgyűjtő

A Egyidejű Mark Sweep (CMS) A megvalósítás több szemétgyűjtő szálat használ a szemétszállításhoz. Olyan alkalmazásokhoz készült, amelyek a rövidebb hulladékgyűjtési szüneteket részesítik előnyben, és amelyek megengedhetik maguknak, hogy az alkalmazás futása közben megosszák a processzor erőforrásait a szemétgyűjtővel.

Egyszerűen fogalmazva, az ilyen típusú GC-t használó alkalmazások átlagosan lassabban reagálnak, de nem állnak le a reagálással a szemétszállítás érdekében.

Itt meg kell jegyezni, hogy mivel ez GC párhuzamos, egy kifejezett szemétgyűjtés, például a System.gc () amíg az egyidejű folyamat működik, azt eredményezi Egyidejű üzemmód meghibásodás / megszakítás.

Ha a teljes idő több mint 98% -át töltjük CMS szemétszállítás és a halom kevesebb mint 2% -a kerül visszanyerésre, majd egy OutOfMemoryError dobja a CMSgyűjtő. Szükség esetén ezt a funkciót ki lehet kapcsolni az opció hozzáadásával -XX: -UseGCOverheadLimit a parancssorba.

Ennek a gyűjtőnek van egy inkrementális módjának is ismert üzemmódja, amelyet a Java SE 8 alkalmazásban elavulnak, és egy későbbi nagyobb kiadásban eltávolíthatják.

A CMS szemétgyűjtő, a következő zászlót használhatjuk:

java -XX: + UseParNewGC -jar Application.java

A Java 9-től kezdve a CMS szemétgyűjtője elavult. Ezért a JVM figyelmeztető üzenetet nyomtat, ha megpróbáljuk használni:

>> java -XX: + UseConcMarkSweepGC --verzió Java HotSpot (TM) 64 bites kiszolgáló virtuális gép figyelmeztetése: A UseConcMarkSweepGC opció elavult a 9.0 verzióban, és valószínűleg egy későbbi kiadásban eltávolítja. java verzió: "9.0.1"

Sőt, a Java 14 teljesen elvetette a CMS támogatást:

>> java -XX: + UseConcMarkSweepGC - verzió OpenJDK 64 bites kiszolgáló virtuális gép figyelmeztetése: A UseConcMarkSweepGC opció figyelmen kívül hagyása; a támogatást eltávolították a 14.0 openjdk 14 2020-03-17-ből

3.4. G1 szemétgyűjtő

G1 (Először szemét) Szemétgyűjtő nagy memóriaterületű, többprocesszoros gépeken futó alkalmazásokhoz készült. Azóta elérhető JDK7 4. frissítés és későbbi kiadásokban.

G1 gyűjtő helyettesíti a CMS gyűjtő, mivel sokkal hatékonyabb.

Más gyűjtőktől eltérően G1 A gyűjtő felosztja a kupacot egyforma méretű kupacrégiókra, amelyek mindegyike a virtuális memória összefüggő tartománya. A szemétszállítás során G1 egyidejű globális jelölési fázist mutat (azaz az 1. fázist, amelyet úgy hívnak, hogy Jelzés) hogy meghatározzuk a tárgyak életképességét az egész kupacban.

A jelölési szakasz befejezése után G1 tudja, mely régiók többnyire üresek. Először ezeken a területeken gyűlik össze, ami általában jelentős mennyiségű szabad teret eredményez (vagyis a 2. fázist, amely néven ismert Söprés). Ezért hívják ezt a szemétszedési módszert Garbage-First-nek.

A G1 szemétgyűjtő, a következő érvet használhatjuk:

java -XX: + UseG1GC -jar Application.java

3.5. Java 8 változások

Java 8u20 bevezett még egyet JVM paraméter a memória felesleges használatának csökkentésére, túl sok példány létrehozásával Húr. Ez optimalizálja a kupac memóriát az ismétlődések eltávolításával Húr értékeket globális szingliként char [] sor.

Ez a paraméter hozzáadással engedélyezhető -XX: + UseStringDeduplication mint a JVM paraméter.

4. Következtetés

Ebben a gyors bemutatóban megnéztük a másikat JVM szemétgyűjtemény megvalósítások és azok felhasználási esetei.

Részletesebb dokumentáció itt található.


$config[zx-auto] not found$config[zx-overlay] not found