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ó.