streamalism.org

1. Oversigt

I denne hurtige vejledning viser vi det grundlæggende i forskellige JVM Garbage Collection (GC) implementeringer. Derudover finder vi ud af, hvordan du aktiverer en bestemt type affaldssamling i vores applikationer.

2. Kort introduktion til affaldsindsamling

Fra navnet ser det ud Dagrenovation beskæftiger sig med at finde og slette affaldet fra hukommelsen. I virkeligheden Dagrenovation sporer hvert eneste tilgængelige objekt i JVM-bunkeområdet og fjerner ubrugte.

Med enkle ord, GC fungerer i to enkle trin kendt som Mark og Sweep:

• Marker - det er her affaldssamleren identificerer, hvilke hukommelsesstykker der er i brug, og hvilke der ikke er
• Feje - dette trin fjerner objekter, der er identificeret under "mark" -fasen

Fordele:

• Ingen manuel hukommelsesallokering / deallocation-håndtering, fordi ubrugt hukommelsesplads håndteres automatisk af GC
• Ingen omkostninger ved håndtering Hængende markør
• Automatisk Hukommelsestab ledelse (GC i sig selv kan ikke garantere den fuldt beviste løsning til hukommelse utæt, men det tager sig af en god del af det)

Ulemper:

• Siden JVM skal holde styr på oprettelse / sletning af objektreferencer, denne aktivitet kræver mere CPU-strøm udover den oprindelige applikation. Det kan påvirke udførelsen af ​​anmodninger, der krævede stor hukommelse
• Programmører har ingen kontrol over planlægningen af ​​CPU-tid dedikeret til at frigøre objekter, der ikke længere er nødvendige
• Brug af nogle GC-implementeringer kan resultere i, at applikationen stopper uforudsigeligt
• Automatisk hukommelsesstyring vil ikke være så effektiv som den korrekte manuelle hukommelsesallokering / deallocation

3. GC-implementeringer

JVM har fire typer GC implementeringer:

• Seriel affaldssamler
• Parallel affaldssamler
• CMS skraldespand
• G1 Affaldssamler

3.1. Seriel affaldssamler

Dette er den enkleste GC-implementering, da den grundlæggende fungerer med en enkelt tråd. Som resultat, det her GC implementering fryser alle applikationstråde, når den kører. Derfor er det ikke en god ide at bruge det i applikationer med flere tråde som servermiljøer.

Der var dog en fremragende samtale af Twitter ingeniører på QCon 2012 om præstationen af Seriel affaldssamler - hvilket er en god måde at forstå denne samler bedre på.

Serial GC er den valgte affaldssamler til de fleste applikationer, der ikke har små pausekrav og kører på klientformede maskiner. At muliggøre Seriel affaldssamler, kan vi bruge følgende argument:

java -XX: + UseSerialGC -jar Application.java

3.2. Parallel affaldssamler

Det er standard GC af JVM og undertiden kaldet Throughput Collectors. I modsætning til Seriel affaldssamler, det her bruger flere tråde til styring af bunkerum. Men det fryser også andre applikationstråde under udførelsen GC.

Hvis vi bruger dette GC, kan vi specificere maksimal affaldsindsamling tråde og pausetid, gennemløb og fodaftryk (bunke størrelse).

Antallet af tråde til affaldssamler kan styres med kommandolinjemuligheden -XX: ParallelGCThreads =.

Det maksimale pausetidsmål (mellemrum [i millisekunder] mellem to GC) er specificeret med kommandolinjemuligheden -XX: MaxGCPauseMillis =.

Det maksimale mål for gennemstrømning (målt med hensyn til den tid, der bruges til at indsamle affald i forhold til den tid, der er brugt uden for affaldssamlingen) er specificeret af kommandolinjevalg -XX: GCTimeRatio =.

Det maksimale bunkefodaftryk (den mængde bunkehukommelse, som et program kræver, mens det kører) specificeres ved hjælp af indstillingen -Xmx.

At muliggøre Parallel affaldssamler, kan vi bruge følgende argument:

java -XX: + UseParallelGC -jar Application.java

3.3. CMS skraldespand

Det Samtidig mærkesveje (CMS) implementering bruger flere tråde til affaldssamler til affaldssamling. Det er designet til applikationer, der foretrækker kortere affaldsindsamlingspauser, og som har råd til at dele processorressourcer med affaldssamleren, mens applikationen kører.

Kort sagt, applikationer, der bruger denne type GC, reagerer i gennemsnit langsommere, men stopper ikke med at reagere for at udføre skraldopsamling.

Et hurtigt punkt at bemærke her er, at siden dette GC er samtidig, en påkaldelse af eksplicit affaldsindsamling som f.eks. brug System.gc () mens den samtidige proces fungerer, vil det resultere i Samtidig tilstand fejl / afbrydelse.

Hvis mere end 98% af den samlede tid bruges på CMS affaldsindsamling og mindre end 2% af dyngen genvindes, derefter en OutOfMemoryError kastes af CMSsamler. Om nødvendigt kan denne funktion deaktiveres ved at tilføje indstillingen -XX: -UseGCOverheadLimit til kommandolinjen.

Denne samler har også en tilstand, der kendes som en inkrementel tilstand, der udfases i Java SE 8 og kan fjernes i en fremtidig større udgivelse.

For at aktivere CMS skraldespand, kan vi bruge følgende flag:

java -XX: + UseParNewGC -jar Application.java

Fra og med Java 9 er CMS-affaldssamleren blevet udfaset. Derfor udskriver JVM en advarselsmeddelelse, hvis vi prøver at bruge den:

>> java -XX: + UseConcMarkSweepGC - version Java HotSpot (TM) 64-bit server-VM-advarsel: Option UseConcMarkSweepGC blev udfaset i version 9.0 og vil sandsynligvis blive fjernet i en fremtidig frigivelse. java version "9.0.1"

Desuden droppede Java 14 CMS-understøttelsen fuldstændigt:

>> java -XX: + UseConcMarkSweepGC - version OpenJDK 64-bit Server VM advarsel: Ignorer indstilling UseConcMarkSweepGC; support blev fjernet i 14.0 openjdk 14 2020-03-17

3.4. G1 Affaldssamler

G1 (Garbage First) Garbage Collector er designet til applikationer, der kører på multi-processor maskiner med stor hukommelsesplads. Det er tilgængeligt siden JDK7 opdatering 4 og i senere udgivelser.

G1 samler vil erstatte CMS samler, da den er mere effektiv.

I modsætning til andre samlere, G1 samler partitioner bunken i et sæt bunkeregioner af samme størrelse, hver et sammenhængende udvalg af virtuel hukommelse. Når du udfører affaldssamling, G1 viser en samtidig global markeringsfase (dvs. fase 1 kendt som Mærkning) for at bestemme genstandenes livskraft gennem bunken.

Når mærkefasen er afsluttet, G1 ved, hvilke regioner der for det meste er tomme. Det samles først i disse områder, hvilket normalt giver en betydelig mængde ledig plads (dvs. fase 2 kendt som Fejer). Det er grunden til, at denne metode til affaldsopsamling kaldes Garbage-First.

For at aktivere G1 Affaldssamler, kan vi bruge følgende argument:

java -XX: + UseG1GC -jar Application.java

3.5. Java 8 ændringer

Java 8u20 har introduceret en mere JVM parameter til at reducere den unødvendige brug af hukommelse ved at oprette for mange forekomster af det samme Snor. Dette optimerer bunkehukommelsen ved at fjerne duplikat Snor værdier til en global single char [] array.

Denne parameter kan aktiveres ved at tilføje -XX: + UseStringDeduplication som en JVM parameter.

4. Konklusion

I denne hurtige vejledning kiggede vi på de forskellige JVM Garbage Collection implementeringer og deres brugssager.

Mere detaljeret dokumentation kan findes her.