Sběr odpadu je mnohem lepší a efektivnější, než si možná myslíte. Je rychlejší než jiné standardní knihovní funkce při alokaci paměti a sběr nefunkčních objektů nic nestojí. GC najde všechny nefunkční objekty bez pomoci vývojáře. V některých ohledech je ale sběr odpadu také zákeřný. Většina sběračů způsobuje pauzy související s GC úměrné velikosti jejich hald.
________________________________________________________________________________
1 gigabajt živých objektů = 1 sekunda pauzy
________________________________________________________________________________
Jinými slovy, větší halda znamená delší pauzu. A pokud spustíte 20minutový test a ladíte, dokud všechny pauzy nezmizí, gratulujeme k odložení pauzy na 21. minutu. K pauze stejně dojde a vaše aplikace bude i tak trpět. A garbage collection ani neodstraňuje úniky objektů – vývojář stále musí najít a opravit reference, které tyto uniklé objekty obsahují.
Ale zpět k dobrým zprávám. Java poskytuje určitou kontrolu nad garbage collectorem. Vývojáři a architekti se mohou rozhodovat o úpravě výkonu aplikace v důsledku chování garbage collectoru.
Snažit se řešit garbage collection na úrovni programování aplikací je nebezpečné. K dosažení správných výsledků je zapotřebí hodně cviku a porozumění, což je čas, který by se dal lépe využít k vytváření funkcí s přidanou hodnotou. I když uděláte všechna správná rozhodnutí, ostatní kód, který vaše aplikace využívá, pravděpodobně nebude optimalizován. S tím, jak se pracovní vytížení aplikace v průběhu času mění, bude mít vaše aplikace stále problémy s výkonem související s GC.
V závislosti na charakteristikách vaší aplikace může také výběr nesprávného typu garbage collectoru nebo použití nesprávného nastavení výrazně prodloužit dobu pauzy nebo dokonce způsobit pády z důvodu nedostatku paměti. Se správným pochopením garbage collectoru a dostupných možností můžete činit informovanější rozhodnutí, která mohou zlepšit výkon a spolehlivost vaší aplikace za běhu.
Jsou všechny garbage collectory v Javě stejné?
Garbage collectors se dělí na několik typů. Každý z nich je víceméně souběžný, což znamená, že běží, když je aplikace pozastavena (není souběžný), překrývá provádění aplikace (částečně nebo většinou souběžný) nebo během běhu aplikace (souběžný).
- Souběžný sběrač – provádí sběr odpadků souběžně, zatímco provádění aplikace pokračuje.
- Paralelní kolektor – používá více vláken. Kolektor může být souběžný, ale ne paralelní, a může být souběžný A paralelní. (Poznámka – buďte opatrní při zkoumání starší literatury o garbage collection, protože to, co jsme dříve nazývali paralelní, se nyní nazývá souběžný.)
- Stop-the-world (STW) – je opakem souběžného provozu. Provádí garbage collection, i když je aplikace zcela zastavena.
- Inkrementální – provádí garbage collection jako sérii menších inkrementů s potenciálně dlouhými mezerami mezi nimi. Aplikace je během garbage collection zastavena, ale mezi inkrementy běží.
- Přesouvání – kolektor přesouvá objekty během garbage collection a musí aktualizovat reference na tyto živé objekty.
- Konzervativní – většina nespravovaných běhových prostředí je konzervativní. V tomto modelu si kolektor není jistý, zda je pole referencí či nikoli, takže předpokládá, že ano. To je v kontrastu s přesným kolektorem.
- Přesný – přesný kolektor přesně ví, kde se nachází každá možná reference objektu. Kolektor nemůže být pohyblivým kolektorem, aniž by byl zároveň přesný, protože musíte vědět, které reference opravit, když přesouváte živé objekty.
Sběratel Azul Platform Prime C4
C4 (Continuously Concurrent Compacting Collector) je v Azul Platform Prime výchozí volbou. C4 souběžně kompaktuje jak mladou, tak starou generaci. Na rozdíl od jiných algoritmů není „většinou“ souběžný, ale plně souběžný, takže se nikdy nevrací k metodě stop-the-world kompaktování.
C4 používá bariéru Load Value Barrier (LVB) k ověření správnosti každého odkazu na haldu při načtení. Všechny odkazy na haldu, které ukazují na přemístěné objekty, jsou zachyceny a opraveny v této samoopravitelné bariéře. C4 má zaručený souběžný marker v jednom průchodu. Bez ohledu na to, jak rychle vaše aplikace mění haldu, C4 s tím udrží krok. Kolektor C4 také provádí souběžné zpracování odkazů (včetně slabých, měkkých a finálních odkazů) a přemístění a přemapování probíhají souběžně. C4 také používá „rychlé uvolnění“, aby uvolněná paměť byla rychle k dispozici aplikaci a pro přemístění objektů. To umožňuje komprimaci „předáváním“, která k fungování nevyžaduje prázdnou paměť.
Pozorování ladění GC
Ladění garbage collectoru pro většinu kolektorů je obtížné provést správně, i když rozumíte charakteristikám vaší aplikace. Obrázek níže ukazuje dvě sady ladicích parametrů pro CMS kolektor v HotSpot JVM. I když mohou používat podobné parametry, jsou velmi odlišné a v některých oblastech diametrálně odlišné. Výkon vaší aplikace však lze optimalizovat s oběma sadami v závislosti na jejích konkrétních charakteristikách. U většiny kolektorů neexistuje univerzální řešení. Vývojáři a architekti musí garbage collector pečlivě ladit a přeladit pokaždé, když se změní aplikace, prostředí nebo očekávaná zátěž. Chybné nastavení těchto parametrů může způsobit neočekávané a dlouhé pauzy během špičkového zatížení.
Výkon aplikace na kolektoru Azul Zing C4 je však necitlivý na „obvyklé“ parametry ladění. Protože se v mladší i staré generaci značkuje a zhutňuje současně, jediným důležitým parametrem je velikost haldy.
Když v běhovém prostředí Azul Prime nastavíte velikost haldy, kolektor C4 vypočítá čas GC, který potřebuje k udržení kroku s rychlostí alokace. Není nutné nastavovat poměry ani časy evakuace. Zingův GC C4 se spustí v případě potřeby pomocí vláken, která jsou oddělená od vláken vaší aplikace. To umožňuje zkrátit doby pauzy v nejhorším případě o řády ve srovnání s jinými strategiemi GC.
Po odstranění GC se doba do dosažení safepointu stává dalším dominantním zdrojem zpoždění a ještě nižších latencí lze dosáhnout pomocí jiných ovládacích prvků, obvykle v operačním systému nebo v JVM pomocí úpravy JIT kompilátoru.
