Seriel GC
Garbage collection forbedrer hukommelseseffektiviteten i Java ved at fjerne ikke-refererede objekter fra bunken og give plads til nyoprettede objekter.
Den virtuelle Java-maskine har otte typer affaldsopsamlere. Lad os overveje hver af dem i detaljer.
Seriel GC er den enkleste GC-implementering. Den er beregnet til små applikationer, der kører i enkelttrådede miljøer. Alle affaldsindsamlingshændelser udføres sekventielt på den samme tråd. Komprimering udføres efter hver affaldsopsamling.
Kørsel af opsamleren resulterer i en "verdensstop"-begivenhed, hvor hele applikationen er suspenderet. Da hele applikationen er frosset under affaldsindsamling, bør du ikke ty til dette i det virkelige liv, hvis du vil holde forsinkelserne så lave som muligt.
JVM-argumentet for at bruge den serielle garbage collector er -XX:+UseSerialGC .
Parallel GC
Den parallelle skraldeopsamler er designet til applikationer med mellemstore til store datasæt, der kører på multithreaded eller multiprocessor hardware. Dette er standard GC-implementeringen og er også kendt som gennemløbsopsamleren.
Flere tråde er bestemt til mindre affaldsindsamling i den unge generation. Den eneste tråd er optaget af hovedaffaldsindsamlingen i den ældre generation.
At køre en parallel GC får også verden til at "stoppe", og applikationen hænger. Denne adfærd er mere passende for et multi-threaded miljø, hvor mange opgaver skal udføres, og lange pauser er acceptable, såsom når du kører et batchjob.
JVM-argumentet for at bruge den parallelle skraldeopsamler er -XX:+UseParallelGC .
CMS GC
Også kendt for os som lav hvile parallel plukker .
Her er der til en lille skraldesamling involveret flere tråde, dette sker gennem samme algoritme som i parallelopsamleren. Hovedaffaldsindsamlingen er multi-threaded, ligesom den gamle parallelle GC, men CMS'et kører sideløbende med applikationsprocesser for at minimere "verdensstop"-hændelser.
På grund af dette bruger CMS-samleren mere CPU end andre samlere. Hvis du har mulighed for at allokere mere CPU for at forbedre ydeevnen, så er et CMS at foretrække frem for en simpel parallel opsamler. CMS GC komprimerer ikke.
JVM-argumentet for at bruge den parallelle mark-sweep garbage collector er -XX:+UseConcMarkSweepGC .
G1 (Affald først) GC
G1GC blev udtænkt som en erstatning for CMS og blev udviklet til multi-threaded applikationer, der er karakteriseret ved store heap-størrelser (større end 4 GB). Det er parallelt og konkurrencedygtigt som et CMS, men under motorhjelmen fungerer det meget anderledes end de gamle skraldesamlere.
Selvom G1 også opererer på generationsbasis, har den ikke separate rum for yngre og ældre generationer. I stedet er hver generation et sæt af regioner, hvilket giver fleksibilitet til at ændre størrelsen på den yngre generation.
G1 opdeler bunken i et sæt lige store områder (afhængigt af bunkens størrelse) og scanner dem i flere tråde. Området under afviklingen af programmet kan gentagne gange blive både gammelt og ungt.
Efter opmærkningsfasen er færdig, ved G1, hvilke områder der indeholder mest skrammel. Hvis brugeren er interesseret i at minimere pauser, kan G1 kun vælge nogle få områder. Hvis pausetiden ikke er vigtig for brugeren, eller hvis pausetidsgrænsen er sat til høj, vil G1 gå over flere områder.
Da G1 GC identificerer regionerne med mest affald og udfører affaldsopsamling på disse regioner først, kaldes det "Garbage First".
Ud over områderne Eden, Survivors og Old Memory, er der to andre typer i G1GC.
- Humongous (Kæmpe) - til genstande af stor størrelse (mere end 50% af bunkens størrelse).
- Tilgængelig - Ubrugt eller ikke-allokeret plads.
JVM-argumentet for at bruge G1-skraldesamleren er -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah er en ny GC udgivet som en del af JDK 12. Den vigtigste fordel ved Shenandoah i forhold til G1 er, at det meste af affaldsindsamlingscyklussen udføres samtidig med applikationstråde. G1 kan kun evakuere heap-områder, når applikationen er suspenderet, mens Shenandoah flytter objekter samtidig med applikationen.
Shenandoah kan komprimere levende objekter, rydde op i skrald og frigøre RAM næsten så snart der er fundet ledig hukommelse. Da alt dette sker på samme tid uden at suspendere applikationen, er Shenandoah mere CPU-intensiv.
ZGC
ZGC er en anden GC udgivet som en del af JDK 11 og forbedret i JDK 12.
Den er beregnet til applikationer, der kræver hastighed og lav latenstid (pauser på mindre end 10 ms) og/eller bruger en meget stor heap (adskillige terabyte).
Hovedmålene for ZGC er lav latenstid, skalerbarhed og brugervenlighed. For at gøre dette tillader det Java-applikationen at fortsætte med at køre på trods af, at affaldsindsamlingsoperationer er i gang. Som standard frigiver ZGC ubrugt hukommelse og returnerer den til operativsystemet.
Således bringer ZGC en betydelig forbedring i forhold til andre traditionelle GC'er ved at give ekstremt lave dødtider (typisk inden for 2ms).
JVM-argumentet for at bruge ZGC-skraldsamleren er -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .