Seriell GC
Garbage Collection förbättrar minneseffektiviteten i Java genom att ta bort objekt som inte refereras från högen och göra plats för nyskapade objekt.
Den virtuella Java-maskinen har åtta typer av sophämtare. Låt oss överväga var och en av dem i detalj.
Serial GC är den enklaste GC-implementeringen. Den är avsedd för små applikationer som körs i enkeltrådiga miljöer. Alla sophämtningshändelser exekveras sekventiellt på samma tråd. Packning utförs efter varje sophämtning.
Att köra insamlaren resulterar i en "världsstopp"-händelse, där hela applikationen avbryts. Eftersom hela applikationen är frusen under sophämtning bör du inte ta till detta i verkligheten om du vill hålla förseningarna så låga som möjligt.
JVM-argumentet för att använda den seriella sopsamlaren är -XX:+UseSerialGC .
Parallell GC
Den parallella sopsamlaren är designad för applikationer med medelstora till stora datamängder som körs på flertrådad eller multiprocessor hårdvara. Detta är standard GC-implementeringen och är även känd som genomströmningssamlaren.
Flera trådar är avsedda för liten sophämtning i den unga generationen. Den enda tråden är upptagen med huvudsopsamlingen i den äldre generationen.
Att köra en parallell GC gör också att världen "stoppar" och applikationen hänger sig. Detta beteende är mer lämpligt för en flertrådig miljö där många uppgifter måste slutföras och långa pauser är acceptabla, till exempel när du kör ett batchjobb.
JVM-argumentet för att använda den parallella sopsamlaren är -XX:+UseParallelGC .
CMS GC
Också känd för oss som lågvila parallellplockare .
Här för en liten sophämtning är flera trådar inblandade, detta sker genom samma algoritm som i parallellsamlaren. Huvudsopsamlingen är flertrådad, precis som den gamla parallella GC, men CMS körs samtidigt med applikationsprocesser för att minimera "world stop"-händelser.
På grund av detta förbrukar CMS-samlaren mer CPU än andra samlare. Om du har möjlighet att allokera mer CPU för att förbättra prestandan är ett CMS att föredra framför en enkel parallellsamlare. CMS GC kompakterar inte.
JVM-argumentet för att använda den parallella mark-sweep-sopsamlaren är -XX:+UseConcMarkSweepGC .
G1 (Skräp först) GC
G1GC var tänkt som en ersättning för CMS och utvecklades för flertrådade applikationer som kännetecknas av stora högstorlekar (större än 4 GB). Det är parallellt och konkurrenskraftigt som ett CMS, men under huven fungerar det väldigt annorlunda än de gamla sophämtarna.
Även om G1 också verkar på generationsbasis, har det inte separata utrymmen för yngre och äldre generationer. Istället är varje generation en uppsättning regioner, vilket möjliggör flexibilitet när det gäller att ändra storleken på den yngre generationen.
G1 delar upp högen i en uppsättning lika stora regioner (beroende på storleken på högen) och skannar dem i flera trådar. Området under genomförandet av programmet kan upprepade gånger bli både gammalt och ungt.
Efter att uppmärkningsfasen är klar vet G1 vilka områden som innehåller mest skräp. Om användaren är intresserad av att minimera pauser kan G1 bara välja ett fåtal områden. Om paustiden inte är viktig för användaren, eller om paustiden är satt till hög, kommer G1 att gå över fler områden.
Eftersom G1 GC identifierar regionerna med mest skräp och utför sophämtning på dessa regioner först, kallas det "Garbage First".
Förutom områdena Eden, Survivors och Old Memory, finns det två andra typer i G1GC.
- Humongous (Enorm) - för föremål av stor storlek (mer än 50% av högstorleken).
- Tillgängligt - Oanvänt eller otilldelat utrymme.
JVM-argumentet för att använda G1-sopsamlaren är -XX:+UseG1GC .
Shenandoah (Shandara)
Shenandoah är en ny GC släppt som en del av JDK 12. Den viktigaste fördelen med Shenandoah framför G1 är att det mesta av sophämtningscykeln görs samtidigt med applikationstrådar. G1 kan bara evakuera högområden när applikationen är inställd, medan Shenandoah flyttar objekt samtidigt som applikationen.
Shenandoah kan komprimera levande föremål, städa upp skräp och frigöra RAM-minne nästan så snart ledigt minne hittas. Eftersom allt detta händer samtidigt, utan att stänga av programmet, är Shenandoah mer CPU-intensiv.
ZGC
ZGC är en annan GC släppt som en del av JDK 11 och förbättrad i JDK 12.
Den är avsedd för applikationer som kräver hastighet och låg latens (pauser på mindre än 10 ms) och/eller använder en mycket stor hög (flera terabyte).
Huvudmålen för ZGC är låg latens, skalbarhet och användarvänlighet. För att göra detta låter den Java-applikationen fortsätta att köras trots att sophämtningsåtgärder pågår. Som standard släpper ZGC oanvänt minne och returnerar det till operativsystemet.
Således ger ZGC en betydande förbättring jämfört med andra traditionella GC:er genom att tillhandahålla extremt låga dödtider (vanligtvis inom 2ms).
JVM-argumentet för att använda ZGC-sopsamlaren är -XX:+UnlockExperimentalVMOptions -XX:+UseZGC .
GO TO FULL VERSION