Seriell GC
Søppelsamling forbedrer minneeffektiviteten i Java ved å fjerne ikke-refererte objekter fra haugen og gi plass til nyopprettede objekter.
Den virtuelle Java-maskinen har åtte typer søppelsamlere. La oss vurdere hver av dem i detalj.
Seriell GC er den enkleste GC-implementeringen. Den er beregnet for små applikasjoner som kjører i enkelt-trådede miljøer. Alle søppelinnsamlingshendelser utføres sekvensielt på samme tråd. Komprimering utføres etter hver søppeloppsamling.
Kjøring av samleren resulterer i en "verdensstopp"-hendelse, der hele applikasjonen er suspendert. Siden hele applikasjonen fryses under søppelhenting, bør du ikke ty til dette i det virkelige liv hvis du vil holde forsinkelsene så lave som mulig.
JVM-argumentet for å bruke den serielle søppelsamleren er -XX:+UseSerialGC .
Parallell GC
Den parallelle søppelsamleren er designet for applikasjoner med middels til store datasett som kjører på flertråds- eller multiprosessormaskinvare. Dette er standard GC-implementering og er også kjent som gjennomstrømningssamleren.
Flere tråder er tiltenkt små søppelhenting i den unge generasjonen. Den eneste tråden er opptatt med hovedsøppelhentingen i den eldre generasjonen.
Å kjøre en parallell GC får også verden til å "stoppe" og applikasjonen henger. Denne virkemåten er mer passende for et flertrådsmiljø der mange oppgaver må fullføres og lange pauser er akseptable, for eksempel når du kjører en batchjobb.
JVM-argumentet for å bruke den parallelle søppelsamleren er -XX:+UseParallelGC .
CMS GC
Også kjent for oss som lav hvile parallellplukker .
Her er det for en liten søppelsamling flere tråder involvert, dette skjer gjennom samme algoritme som i parallellsamleren. Hovedsøppelsamlingen er flertrådet, akkurat som den gamle parallelle GC, men CMS kjører samtidig med søknadsprosesser for å minimere "verdensstopp"-hendelser.
På grunn av dette bruker CMS-samleren mer CPU enn andre samlere. Hvis du har muligheten til å allokere mer CPU for å forbedre ytelsen, er et CMS å foretrekke fremfor en enkel parallellsamler. CMS GC komprimerer ikke.
JVM-argumentet for å bruke den parallelle mark-sweep søppelsamleren er -XX:+UseConcMarkSweepGC .
G1 (Søppel først) GC
G1GC ble tenkt som en erstatning for CMS og ble utviklet for flertrådede applikasjoner som er preget av store haugstørrelser (større enn 4 GB). Den er parallell og konkurransedyktig som et CMS, men under panseret fungerer den veldig annerledes enn de gamle søppelsamlerne.
Selv om G1 også opererer på generasjonsbasis, har den ikke separate rom for yngre og eldre generasjoner. I stedet er hver generasjon et sett med regioner, noe som gir fleksibilitet når det gjelder å endre størrelsen på den yngre generasjonen.
G1 deler haugen i et sett med like store områder (avhengig av størrelsen på haugen) og skanner dem inn i flere tråder. Området under gjennomføringen av programmet kan gjentatte ganger bli både gammelt og ungt.
Etter at markup-fasen er fullført, vet G1 hvilke områder som inneholder mest søppel. Hvis brukeren er interessert i å minimere pauser, kan G1 bare velge noen få områder. Hvis pausetiden ikke er viktig for brukeren, eller hvis pausetidsgrensen er satt til høy, vil G1 gå over flere områder.
Siden G1 GC identifiserer regionene med mest søppel og utfører søppelinnsamling på disse regionene først, kalles det "Garbage First".
I tillegg til områdene Eden, Survivors og Old Memory, er det to andre typer i G1GC.
- Humongous (Enorm) - for gjenstander av stor størrelse (mer enn 50% av haugstørrelsen).
- Tilgjengelig - Ubrukt eller uallokert plass.
JVM-argumentet for å bruke G1 søppelsamleren er -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah er en ny GC utgitt som en del av JDK 12. Den viktigste fordelen med Shenandoah fremfor G1 er at det meste av søppeloppsamlingssyklusen gjøres samtidig med applikasjonstråder. G1 kan bare evakuere haugområder når applikasjonen er suspendert, mens Shenandoah flytter objekter samtidig med applikasjonen.
Shenandoah kan komprimere levende objekter, rydde opp i søppel og frigjøre RAM nesten så snart ledig minne er funnet. Siden alt dette skjer på samme tid, uten å suspendere applikasjonen, er Shenandoah mer CPU-intensiv.
ZGC
ZGC er en annen GC utgitt som en del av JDK 11 og forbedret i JDK 12.
Den er beregnet på applikasjoner som krever hastighet og lav latenstid (pauser på mindre enn 10 ms) og/eller bruker en veldig stor haug (flere terabyte).
Hovedmålene til ZGC er lav latenstid, skalerbarhet og brukervennlighet. For å gjøre dette lar det Java-applikasjonen fortsette å kjøre til tross for at søppelinnsamlingsoperasjoner pågår. Som standard frigjør ZGC ubrukt minne og returnerer det til operativsystemet.
Dermed gir ZGC en betydelig forbedring i forhold til andre tradisjonelle GC-er ved å gi ekstremt lave dødtider (vanligvis innen 2ms).
JVM-argumentet for å bruke ZGC-søppelsamleren er -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .