JVM søppeloppsamlere

1. Oversikt

I denne raske opplæringen vil vi vise det grunnleggende om forskjellige JVM Garbage Collection (GC) implementeringer. I tillegg vil vi finne ut hvordan du aktiverer en bestemt type søppelinnsamling i applikasjonene våre.

2. Kort introduksjon til søppelinnsamling

Fra navnet ser det ut som Søppelsamling omhandler å finne og slette søpla fra minnet. Imidlertid, i virkeligheten, Søppelsamling sporer hvert eneste tilgjengelig objekt i JVM-heap-området og fjerner ubrukte objekter.

Med enkle ord, GC fungerer i to enkle trinn kjent som Mark og Sweep:

  • Merke - det er her søppeloppsamleren identifiserer hvilke minnestykker som er i bruk og hvilke som ikke er det
  • Feie - Dette trinnet fjerner gjenstander som er identifisert i løpet av "merkefasen"

Fordeler:

  • Ingen manuell minnetildeling / håndtering av deallocation fordi ubrukt minneplass håndteres automatisk av GC
  • Ingen overhead av håndtering Dinglende pekeren
  • Automatisk Hukommelsestap ledelse (GC på egen hånd kan ikke garantere fullstendig løsning for minne lekker, men den tar seg av en god del av det)

Ulemper:

  • Siden JVM må holde rede på oppretting / sletting av objektreferanser, denne aktiviteten krever mer CPU-kraft i tillegg til den opprinnelige applikasjonen. Det kan påvirke ytelsen til forespørsler som krever stort minne
  • Programmerere har ingen kontroll over planlegging av CPU-tid dedikert til å frigjøre objekter som ikke lenger er nødvendig
  • Bruk av noen GC-implementeringer kan føre til at applikasjonen stopper uforutsigbart
  • Automatisk minnehåndtering vil ikke være like effektiv som riktig manuell minnetildeling / deallocation

3. GC-implementeringer

JVM har fire typer GC implementeringer:

  • Seriell søppeloppsamler
  • Parallell søppeloppsamler
  • CMS søppeloppsamler
  • G1 Søppeloppsamler

3.1. Seriell søppeloppsamler

Dette er den enkleste GC-implementeringen, da den i utgangspunktet fungerer med en enkelt tråd. Som et resultat, dette GC implementering fryser alle søknadstråder når den kjører. Derfor er det ikke en god ide å bruke den i applikasjoner med flere tråder som servermiljøer.

Imidlertid var det en utmerket samtale av Twitter ingeniører på QCon 2012 om ytelsen til Seriell søppeloppsamler - som er en god måte å forstå denne samleren bedre.

Serial GC er søppeloppsamleren som er valgt for de fleste applikasjoner som ikke har små krav til pausetid og kjører på klientmaskiner. For å aktivere Seriell søppeloppsamler, kan vi bruke følgende argument:

java -XX: + UseSerialGC -jar Application.java

3.2. Parallell søppeloppsamler

Det er standard GC av JVM og noen ganger kalt Throughput Collectors. I motsetning til Seriell søppeloppsamler, dette bruker flere tråder for å administrere dyngplass. Men det fryser også andre applikasjonstråder mens du utfører GC.

Hvis vi bruker dette GC, kan vi spesifisere maksimal søppeloppsamling tråder og pausetid, gjennomstrømning og fotavtrykk (haugstørrelse).

Antall søppeltråder kan kontrolleres med kommandolinjealternativet -XX: ParallelGCThreads =.

Maksimalt mål for pausetid (gap [i millisekunder] mellom to GC) er spesifisert med kommandolinjealternativet -XX: MaxGCPauseMillis =.

Maksimalt gjennomstrømningsmål (målt med hensyn til tid brukt på søppelinnsamling versus tid brukt utenfor søppelinnsamling) er spesifisert av kommandolinjealternativet -XX: GCTimeRatio =.

Maksimalt heap-fotavtrykk (mengden heapminne som et program krever mens du kjører) spesifiseres ved hjelp av alternativet -Xmx.

For å aktivere Parallell søppeloppsamler, kan vi bruke følgende argument:

java -XX: + UseParallelGC -jar Application.java

3.3. CMS søppeloppsamler

De Samtidig Mark Sweep (CMS) implementering bruker flere søppeloppsamlertråder for søppeloppsamling. Den er designet for applikasjoner som foretrekker kortere søppelpauser, og som har råd til å dele prosessorressurser med søppeloppsamleren mens applikasjonen kjører.

Enkelt sagt, applikasjoner som bruker denne typen GC reagerer i gjennomsnitt langsommere, men slutter ikke å svare for å utføre søppeloppsamling.

Et raskt poeng å merke seg her er at siden dette GC er samtidig, en påkalling av eksplisitt søppelinnsamling som bruk System.gc () mens den samtidige prosessen fungerer, vil det resultere i Samtidig modus feil / avbrudd.

Hvis mer enn 98% av den totale tiden blir brukt på CMS søppeloppsamling og mindre enn 2% av dyngen gjenvinnes, deretter en OutOfMemoryError blir kastet av CMSsamler. Om nødvendig kan denne funksjonen deaktiveres ved å legge til alternativet -XX: -BrukGCOverheadLimit til kommandolinjen.

Denne samleren har også en modus kjent som en inkrementell modus som avvikles i Java SE 8 og kan fjernes i en fremtidig større utgivelse.

For å aktivere CMS søppeloppsamler, kan vi bruke følgende flagg:

java -XX: + UseParNewGC -jar Application.java

Fra og med Java 9 er CMS søppeloppsamleren avviklet. Derfor skriver JVM ut en advarsel hvis vi prøver å bruke den:

>> java -XX: + UseConcMarkSweepGC - versjon Java HotSpot (TM) 64-biters server-VM-advarsel: Alternativ UseConcMarkSweepGC ble avviklet i versjon 9.0 og vil trolig bli fjernet i en fremtidig versjon. java versjon "9.0.1"

Videre droppet Java 14 CMS-støtten fullstendig:

>> java -XX: + UseConcMarkSweepGC - versjon OpenJDK 64-biters server-advarsel: Ignorer alternativet UseConcMarkSweepGC; støtte ble fjernet i 14.0 openjdk 14 2020-03-17

3.4. G1 Søppeloppsamler

G1 (Garbage First) Søppeloppsamler er designet for applikasjoner som kjører på flerprosessormaskiner med stor minneplass. Den er tilgjengelig siden JDK7 oppdatering 4 og i senere utgivelser.

G1 samler vil erstatte CMS samler siden det er mer ytelseseffektivt.

I motsetning til andre samlere, G1 samler partisjonerer haugen i et sett med like store haugregioner, hver et sammenhengende utvalg av virtuelt minne. Når du utfører søppelinnsamling, G1 viser en samtidig global merkingsfase (dvs. fase 1 kjent som Merking) for å bestemme levetiden til gjenstander gjennom dyngen.

Etter at merkefasen er fullført, G1 vet hvilke regioner som stort sett er tomme. Den samler seg først i disse områdene, noe som vanligvis gir en betydelig mengde ledig plass (dvs. fase 2 kjent som Feiende). Det er grunnen til at denne metoden for søppeloppsamling kalles Garbage-First.

For å aktivere G1 Søppeloppsamler, kan vi bruke følgende argument:

java -XX: + UseG1GC -jar Application.java

3.5. Java 8 Endringer

Java 8u20 har introdusert en til JVM parameter for å redusere unødvendig bruk av minne ved å opprette for mange forekomster av det samme String. Dette optimaliserer haugeminnet ved å fjerne duplikat String verdier til en global singel røye [] array.

Denne parameteren kan aktiveres ved å legge til -XX: + UseStringDeduplication som en JVM parameter.

4. Konklusjon

I denne raske opplæringen så vi på de forskjellige JVM søppel samling implementeringer og brukssaker.

Mer detaljert dokumentasjon finner du her.


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