Garbage Collectors har vanligtvis följande mål (lättare sagt än gjort)
Very short ”stop the world pauses” with a target of a few milliseconds
Pause times do not increase with a heap, live-set, eller rot-setstorlek
För att hantera heapstorlekar från några MB upp till många TB
Hög samtidighet – Allt tungt arbete utförs medan Java-trådar fortsätter att köra
Hög genomströmning
Lätt att ställa in
Garbage Collectors
Data i heap delas upp i flera tilldelningsregioner (eller generationer) som hålls åtskilda baserat på objektets ålder (dvs.dvs. antalet överlevda GC-iterationer). Medan vissa insamlare är engenerationella använder andra två generationer: (1) den unga generationen (ytterligare uppdelad i Eden och två överlevande regioner) och (2) den gamla generationen (eller Tenured Generation) Källa: Det är en algoritm som använder en enda tråd för att utföra allt skräpinsamlingsarbete, vilket gör den relativt effektiv eftersom det inte finns något kommunikationsöverskott mellan trådarna. Den lämpar sig bäst för maskiner med en enda processor eftersom den inte kan dra nytta av maskinvara med flera processorer.
Throughput (Parallel) GC – Denna algoritm använder mark-copy i den unga generationen och mark-sweep-compact i den gamla generationen. Både Young och Old collections utlöser stop-the-world-händelser, vilket stoppar alla programtrådar för att utföra skräpplockning. Båda insamlarna kör markerings- och kopierings-/komprimeringsfaserna med hjälp av flera trådar, därav namnet ”Parallel”.
Parallel Garbage Collector lämpar sig för flerkärniga maskiner i de fall där ditt primära mål är att öka genomströmningen. Högre genomströmning uppnås på grund av effektivare användning av systemresurser:
under insamlingen städar alla kärnor soporna parallellt, vilket resulterar i kortare pauser
mellan sopinsamlingscyklerna förbrukar ingen av insamlingsenheterna några resurser
Garbage First (G1) GC – Den här insamlingsenheten är en serverliknande sopinsamlingsenhet som är inriktad på flerprocessormaskiner med stora minnen. Den uppfyller målen för paustid för garbage collection (GC) med hög sannolikhet, samtidigt som den uppnår hög genomströmning.
G1-samlaren har ett annat tillvägagångssätt när det gäller heap-minnesmodellen. Heap är uppdelad i en uppsättning lika stora heap-regioner, var och en ett sammanhängande område av virtuellt minne.
Vissa regionuppsättningar tilldelas samma roller (eden, survivor, old) som i de äldre insamlarna, men det finns ingen fast storlek för dem.
Regionstorleken väljs av JVM:en vid uppstarten. JVM siktar i allmänhet på cirka 2000 regioner som varierar i storlek från 1 till 32 Mb. G1-samlaren har ett annat tillvägagångssätt
För mer information, se Getting Started with the G1 GC
G1 Heap Allocation
Uni generational collectors:
Shenandoah GC – Shenandoah är en sophämtare med låg paustid som minskar paustiderna för GC genom att utföra mer sophämtningsarbete samtidigt med det pågående Javaprogrammet. Shenandoah utför huvuddelen av GC-arbetet samtidigt, inklusive den samtidiga komprimeringen, vilket innebär att paustiderna inte längre är direkt proportionella mot storleken på heapen. Skräpplockning av en 200 GB heap eller en 2 GB heap bör ha ett liknande lågt pausbeteende.
För mer detaljer hänvisas till Implementation Details in Wiki
Z GC – ZGC är en samtidig, enkelgenerations, regionbaserad, NUMA-medveten, komprimerande insamlare. Stop-the-world-faserna är begränsade till rotskanning, så paustiderna för GC ökar inte med storleken på heap eller live set.
För mer information hänvisas till Session on ZGC by Per Liden on YouTube
Finally,
Epsilon GC (experimental)- En GC som hanterar minnesallokering men som inte implementerar någon egentlig mekanism för återvinning av minne. När det tillgängliga Java-heapet är uttömt stängs JVM av. Utformad för intern JDK-testning men kan tänkas vara användbar i två situationer
Mycket kortlivade program
Programmen är noggrant skrivna för att återanvända minnet och aldrig utföra nya allokeringar
